某些具有较低 TTL 的记录的间歇性 NXDOMAIN 响应

某些具有较低 TTL 的记录的间歇性 NXDOMAIN 响应

我们的安装(版本 9.8.4)遇到了一个特殊问题bind

在此场景中,bind配置为小型网络的缓存名称服务器。对于大多数查询,一切正常。

然而,我们注意到,对于一些配置了非常低 TTL 的主机的查询,即使主机名存在,我们有时会收到 NXDOMAIN 响应。

举个例子,www.cdn77.comdig—这是在名称服务器本身上运行时的输出:

$ dig www.cdn77.com

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> www.cdn77.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34440
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 6, ADDITIONAL: 12

;; QUESTION SECTION:
;www.cdn77.com.         IN  A

;; ANSWER SECTION:
www.cdn77.com.      196 IN  CNAME   1669655317.rsc.cdn77.org.
1669655317.rsc.cdn77.org. 0 IN  A   185.59.220.12

;; AUTHORITY SECTION:
org.            170517  IN  NS  a2.org.afilias-nst.info.
org.            170517  IN  NS  c0.org.afilias-nst.info.
org.            170517  IN  NS  b0.org.afilias-nst.org.
org.            170517  IN  NS  d0.org.afilias-nst.org.
org.            170517  IN  NS  a0.org.afilias-nst.info.
org.            170517  IN  NS  b2.org.afilias-nst.org.

;; ADDITIONAL SECTION:
a0.org.afilias-nst.info. 170517 IN  A   199.19.56.1
a0.org.afilias-nst.info. 170517 IN  AAAA    2001:500:e::1
a2.org.afilias-nst.info. 170517 IN  A   199.249.112.1
a2.org.afilias-nst.info. 170517 IN  AAAA    2001:500:40::1
b0.org.afilias-nst.org. 170517  IN  A   199.19.54.1
b0.org.afilias-nst.org. 170517  IN  AAAA    2001:500:c::1
b2.org.afilias-nst.org. 170517  IN  A   199.249.120.1
b2.org.afilias-nst.org. 170517  IN  AAAA    2001:500:48::1
c0.org.afilias-nst.info. 170517 IN  A   199.19.53.1
c0.org.afilias-nst.info. 170517 IN  AAAA    2001:500:b::1
d0.org.afilias-nst.org. 170517  IN  A   199.19.57.1
d0.org.afilias-nst.org. 170517  IN  AAAA    2001:500:f::1

;; Query time: 42 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Dec  2 14:27:03 2015
;; MSG SIZE  rcvd: 487

以下是返回 NXDOMAIN 响应的示例:

$ dig www.cdn77.com

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> www.cdn77.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 28771
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;www.cdn77.com.         IN  A

;; ANSWER SECTION:
www.cdn77.com.      327 IN  CNAME   1669655317.rsc.cdn77.org.

;; AUTHORITY SECTION:
cdn77.org.      59  IN  SOA ns1.cdn77.org. admin.cdn77.com. 1449062655 10800 180 604800 60

;; Query time: 34 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Dec  2 14:24:52 2015
;; MSG SIZE  rcvd: 115

我们使用 Google 的公共名称服务器作为转发器,但它们似乎从未使用 NXDOMAIN 做出响应:

$ dig www.cdn77.com @8.8.8.8

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> www.cdn77.com @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35091
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.cdn77.com.         IN  A

;; ANSWER SECTION:
www.cdn77.com.      851 IN  CNAME   1669655317.rsc.cdn77.org.
1669655317.rsc.cdn77.org. 0 IN  A   185.59.220.11

;; Query time: 40 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Dec  2 14:29:16 2015
;; MSG SIZE  rcvd: 85

顺便说一下,权威的答案是这样的:

$ dig 1669655317.rsc.cdn77.org @ns1.cdn77.org

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> 1669655317.rsc.cdn77.org @ns1.cdn77.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11529
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;1669655317.rsc.cdn77.org.  IN  A

;; ANSWER SECTION:
1669655317.rsc.cdn77.org. 1 IN  A   185.59.220.12

;; Query time: 20 msec
;; SERVER: 37.235.105.100#53(37.235.105.100)
;; WHEN: Wed Dec  2 14:32:57 2015
;; MSG SIZE  rcvd: 58

有趣的是,尽管该记录的权威 TTL 为 1,但 Google 的公共名称服务器始终会将其减小为零(请参阅本文了解有关此行为的有趣内容)。但我不认为这与问题有任何关系,因为我们的成功响应bind也显示 TTL 为零。

我已提高bind日志记录级别,但发现很难识别可能与问题相关的任何条目。即使已querylog激活,可见的也只是查询本身和resolver: debug 1: createfetch: 1669655317.rsc.cdn77.org A行。

任何关于如何更好地诊断(甚至解决)这个问题的指示都将不胜感激。

答案1

问题在于 cdn77.org 的权威域名服务器无法正确处理弹性云服务器EDNS 客户端子网) 选项,当它们包含 IPv6 客户端子网时,尽管它们可以很好地处理 IPv4 客户端子网。

如果你建造利用 EDNS 客户端子网支持进行挖掘,您可以在命令行上检查这一点;或者您可以使用在线KeyCDN DNS 查找工具要检查这一点(选择详细信息复选框并取消选择递归复选框,并在将其作为自定义 DNS 时省略 ns1 之前的 @):

$ dig 1669655317.rsc.cdn77.org @ns1.cdn77.org +subnet=2001:db8::1
; <<>> DiG 9.10.1 <<>> +additional 1669655317.rsc.cdn77.org @ns1.cdn77.org +subnet=2001:db8::1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 44989
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1680
; CLIENT-SUBNET: 2001:db8::1/128/0
;; QUESTION SECTION:
;1669655317.rsc.cdn77.org.  IN  A

;; AUTHORITY SECTION:
cdn77.org.      60  IN  SOA ns1.cdn77.org. admin.cdn77.com. 1449094813 10800 180 604800 60

;; Query time: 2 msec
;; SERVER: 37.235.105.100#53(37.235.105.100)
;; WHEN: Wed Dec 02 22:21:41 UTC 2015
;; MSG SIZE  rcvd: 132

使用 IPv4 客户端地址的相同查询也可以正常工作:

$ dig 1669655317.rsc.cdn77.org @ns1.cdn77.org +subnet=192.0.2.1
; <<>> DiG 9.10.1 <<>> +additional 1669655317.rsc.cdn77.org @ns1.cdn77.org +subnet=192.0.2.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19104
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1680
; CLIENT-SUBNET: 192.0.2.1/32/32
;; QUESTION SECTION:
;1669655317.rsc.cdn77.org.  IN  A

;; ANSWER SECTION:
1669655317.rsc.cdn77.org. 1 IN  A   185.93.3.27

;; Query time: 2 msec
;; SERVER: 37.235.105.100#53(37.235.105.100)
;; WHEN: Wed Dec 02 22:42:13 UTC 2015
;; MSG SIZE  rcvd: 81

当您将查询发送到 Google Public DNS 的 IPv6 地址时,您的客户端 IP 子网当然是 IPv6 子网,并且当权威服务器回答 NXDOMAIN 时,IPv6 客户端的(缓存?)答案也是 NXDOMAIN。如果您将查询发送到 Google Public DNS 的 IPv4 地址,您的客户端子网是 IPv4 子网,并且您会得到正确的(可能是缓存的)答案。

答案2

上游转发器似乎有不一致的数据 -尽管原因尚不清楚- 循环中的一个转发器正在返回,NXDOMAIN并且正在本地缓存:

尽管运行正常,但Google 的公共 DNS IPv62001:4860:4860::8888目前正在恢复NXDOMAIN8.8.8.8(即匹配权威答案)

短期解决方案是删除有问题的转发器,然后重新启动 Bind 或清除负面缓存。


请参阅 Alex Dupuy 的回答,了解根本原因的清晰解释

答案3

很抱歉给您带来不便,这个错误只给我们的少数客户造成了问题,Alex Dupuy 已经对这个问题进行了很好的解释。我们已添加 IPv6 EDNS 支持,并在我们的 DNS 服务器上启用了 IPv6 任播,现在这个问题已经解决。

相关内容