对于TTL较低的特定logging，间歇NXDOMAIN响应

我们遇到了bind安装（版本9.8.4）的一个特殊问题。

在这种情况下， bind被configuration为一个小型networking的caching名称服务器。对于大多数查询，一切工作正常。

但是，我们注意到，对于configuration了非常低的TTL的一些主机的查询，即使主机名存在，我们有时也会得到NXDOMAIN响应。

作为一个例子，请访问 www.cdn77.com – 在名称服务器本身上运行dig的输出：

 $ 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

有趣的是，尽pipelogging的授权TTL是一个，Google的公共名称服务器总是将其减less到零（请参阅本文以获得有关此行为的有趣阅读）。我认为这与问题没有任何关系，因为我们bind的成功响应也显示TTL为零。

我已经增加了bind的日志logging级别，但是发现很难找出任何可能与问题有关的条目。即使使用querylog激活，所有可见的是查询本身和resolver: debug 1: createfetch: 1669655317.rsc.cdn77.org A行。

任何指向如何更好地诊断（甚至解决）这个问题的指针将不胜感激。

问题是cdn77.org的授权域名服务器在包含IPv6客户端子网时无法正确处理ECS （ EDNS客户端 – 子网）选项，尽pipe它们处理IPv4客户端子网就好了。

如果您使用EDNS客户端子网支持来构builddig ，则可以在命令行上进行检查; 或者您可以使用在线KeyCDN DNS查找工具来检查这一点（select详细信息checkbox并取消selectrecursioncheckbox，并在您将其作为自定义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客户端的（caching？）答案也是NXDOMAIN。如果您将查询发送到Google Public DNS的IPv4地址，则您的客户端子网是IPv4子网，并且会得到正确的（可能是caching的）答案。

上游转发器似乎有不一致的数据 – ~~尽pipe其原因尚不清楚~~ – 循环中的一个转发器正在返回本地caching的NXDOMAIN ：

Google的公共DNS IPv6 2001:4860:4860::8888目前正在返回NXDOMAIN ，尽pipe8.8.8.8正常工作（即匹配权威答案）

短期的解决scheme是删除有问题的转发器，然后重新启动绑定或清除否定caching。

请参阅Alex Dupuy的答案，以清楚解释根本原因

不便之处，这个bug已经给我们的一些客户带来了问题，Alex Dupuy提供了很好的解释。我们添加了IPv6 EDNS支持，并在我们的DNS服务器上启用了IPv6选播，现在这个问题已经消失了。