我们的安装(版本 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
目前正在恢复NXDOMAIN
8.8.8.8
(即匹配权威答案)
短期解决方案是删除有问题的转发器,然后重新启动 Bind 或清除负面缓存。
请参阅 Alex Dupuy 的回答,了解根本原因的清晰解释
答案3
很抱歉给您带来不便,这个错误只给我们的少数客户造成了问题,Alex Dupuy 已经对这个问题进行了很好的解释。我们已添加 IPv6 EDNS 支持,并在我们的 DNS 服务器上启用了 IPv6 任播,现在这个问题已经解决。