将不同的 NS 记录设置为权威 DNS 上的权威

Question

我将域的 DNS 服务器设置为注册商上的一组权威 DNS 服务器。但是，域的那些 DNS 服务器区域文件具有一组不同的 NS 记录。一些 DNS 服务器正在愉快地将请求传递到区域文件中设置的 NS 服务器；但是，其他一些（例如 Google、Level 3 和 OpenDNS 的公共 DNS 服务器）无法正确解析记录。它们返回正确的 NS 记录，但未返回对子委托 DNS 服务器上的 A 记录的请求。我在下面提供了大量输出；但它的要点是，请求没有被引用到我在 QUICKROUTEDNS.COM 为域设置的 NS 记录，这些 NS 记录是指向亚马逊云 DNS 的。相反，请求停止在 QUICKROUTEDNS.COM。

下面是一个例子：

域名在注册商处的 DNS 记录：

Name Server: NS1.QUICKROUTEDNS.COM
Name Server: NS2.QUICKROUTEDNS.COM
Name Server: NS3.QUICKROUTEDNS.COM

拉取域的 NS 记录（权威 DNS，QUICKROUTEDNS.COM，将这些服务器设置为 NS 记录）：

$ host -t NS domain.com 
domain.com name server ns-1622.awsdns-10.co.uk.
domain.com name server ns-1387.awsdns-45.org.
domain.com name server ns-774.awsdns-32.net.
domain.com name server ns-48.awsdns-06.com.

来自托管域的 Amazon DNS 服务器的 A 记录：

$ host www.domain.com ns-1387.awsdns-45.org
Using domain server:
Name: ns-1387.awsdns-45.org.
Address: 205.251.197.107#53
Aliases:

www.domain.com has address 201.201.201.201

然而，当我从任何给定的名称服务器请求它时：

$ host www.domain.com 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases:

Host www.domain.com not found: 3(NXDOMAIN)

这在几乎每个 DNS 服务器中都是一致的，尽管有少数会按预期报告 A 记录。

这是尝试拉 A 记录时的 dig +trace 输出：

$ dig @8.8.8.8 www.domain.com A +trace                                                                         

; <<>> DiG 9.8.3-P1 <<>> @8.8.8.8 www.domain.com A +trace
; (1 server found)
;; global options: +cmd
.           1341    IN  NS  m.root-servers.net.
.           1341    IN  NS  j.root-servers.net.
.           1341    IN  NS  a.root-servers.net.
.           1341    IN  NS  d.root-servers.net.
.           1341    IN  NS  f.root-servers.net.
.           1341    IN  NS  c.root-servers.net.
.           1341    IN  NS  b.root-servers.net.
.           1341    IN  NS  e.root-servers.net.
.           1341    IN  NS  i.root-servers.net.
.           1341    IN  NS  h.root-servers.net.
.           1341    IN  NS  g.root-servers.net.
.           1341    IN  NS  l.root-servers.net.
.           1341    IN  NS  k.root-servers.net.
;; Received 228 bytes from 8.8.8.8#53(8.8.8.8) in 58 ms

net.            172800  IN  NS  a.gtld-servers.net.
net.            172800  IN  NS  e.gtld-servers.net.
net.            172800  IN  NS  c.gtld-servers.net.
net.            172800  IN  NS  b.gtld-servers.net.
net.            172800  IN  NS  g.gtld-servers.net.
net.            172800  IN  NS  i.gtld-servers.net.
net.            172800  IN  NS  j.gtld-servers.net.
net.            172800  IN  NS  k.gtld-servers.net.
net.            172800  IN  NS  h.gtld-servers.net.
net.            172800  IN  NS  f.gtld-servers.net.
net.            172800  IN  NS  d.gtld-servers.net.
net.            172800  IN  NS  m.gtld-servers.net.
net.            172800  IN  NS  l.gtld-servers.net.
;; Received 503 bytes from 192.36.148.17#53(192.36.148.17) in 586 ms

domain.com.     172800  IN  NS  ns1.quickroutedns.com.
domain.com.     172800  IN  NS  ns2.quickroutedns.com.
domain.com.     172800  IN  NS  ns3.quickroutedns.com.
;; Received 153 bytes from 192.55.83.30#53(192.55.83.30) in 790 ms

domain.com.     3600    IN  SOA cns1.atlantic.net. noc.atlantic.net. 2016033004 28800 7200 604800 3600
;; Received 88 bytes from 69.16.156.227#53(69.16.156.227) in 712 ms

正如我们所见，它只会访问 QUICKROUTEDNS.COM 域名服务器，而不会从 Amazon 域名服务器请求。那么，我如何告诉 DNS 服务器从 Amazon 服务器获取其查询，而不是在 QuickRouteDNS.COM 上停止？

Answer 1

这里确实有两个问题被问到，它们直接相互矛盾：

1. 我如何指示 DNS 服务器继续向 Amazon 查询作为域的权威，而无需更改注册商的 DNS 记录？
2. 我如何告诉 DNS 服务器从 Amazon 服务器获取其查询而不是在 QuickRouteDNS.COM 上停止？

DNS 层次结构中的每个委派都必须比上一个更具体。换句话说，您可以委派子域，但不能重新委派已委派给服务器的完全相同的名称。正确的解决方案是在注册商级别更改配置，这是您试图避免的。

您现在拥有的是一种常见的错误配置，称为跛脚委托（NS 记录不匹配），它给人一种错误的印象，即这种设计是可以实现的。下面是对正在发生的事情的解释，但如果没有很好地掌握 DNS 概念，就很难理解。如果我失去了您，请认为更正注册商数据是解决您的问题的正确方法。

为了说明，这里有两个示例区域片段：

$ORIGIN example.com
@       2941 IN SOA ns1.example.com. someone.example.com. (
            2015071001 ; serial
            7200       ; refresh (2 hours)
            900        ; retry (15 minutes)
            7200000    ; expire (11 weeks 6 days 8 hours)
            3600       ; minimum (1 hour)
            )
@   IN NS ns1
@   IN NS ns2

sub IN NS ns1.contoso.com.
sub IN NS ns2.contoso.com.

在 contoso.com 名称服务器上：

$ORIGIN sub.example.com.
@       2941 IN SOA ns1.sub.example.com. someone.contoso.com. (
                2015071001 ; serial
                7200       ; refresh (2 hours)
                900        ; retry (15 minutes)
                7200000    ; expire (11 weeks 6 days 8 hours)
                3600       ; minimum (1 hour)
                )
@     IN NS bagel.contoso.com.
@     IN NS bacon.contoso.com.

以上两个区域中哪些 NS 记录具有权威性sub.example.com？如果你认为是ns1和ns2.contoso.com，那你就错了。与流行的看法相反，执行委托的名称服务器不被视为对NS用于定义该委托的记录具有权威性。相反，权威定义由委托接收端的区域拥有。

我们已经确定bacon并且bagel是权威的。这里不太明显的是，域名服务器不一定会立即意识到这一点。委派受到善意的关注，并且最初假定接收委派的服务器是权威的。只有当这些NS记录被刷新时，才会发生脑损伤。刷新可以由任意数量的事情触发，从委托NS记录的TTL到期到对这些NS记录的值的显式请求。一旦NS记录被覆盖，新的服务器就会被使用。

总而言之，在初始阶段使用您的注册商定义的名称服务器，然后是使用第二组名称服务器的阶段。在第一个期间，仅存在于第二组服务器上的任何记录都将失败。在第二个期间，仅存在于第一组服务器上的任何记录都将失败。

听起来问题最终会自行解决（只需等待一切刷新），但这永远不会发生。人们将重新启动他们的域名服务器，刷新他们的缓存，或者建立新的域名服务器。在NS记录变得一致之前，您的域将处于不断变化的不一致状态。DNS 专家可以用它做一些有趣的事情，但这种类型的配置的有效用例很少。普通用户应该不惜一切代价避免冲突的名称服务器定义。