主页 / server / 问题 / 740250
Accepted
dorian
Asked: 2015-12-03 05:39:55 +0800 CST

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

  • 772

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

在这种情况下，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行。

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

domain-name-system

3 个回答

  1. 上游转发器似乎有不一致的数据 -尽管其原因尚不清楚- 您的循环中的一个转发器正在返回NXDOMAIN，该转发器正在本地缓存：

    谷歌的公共 DNS IPv62001:4860:4860::8888目前正在返回NXDOMAIN，尽管8.8.8.8工作正常（即，匹配权威答案）

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

    有关根本原因的明确解释，请参阅 Alex Dupuy 的回答

    • 3
  2. Best Answer

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

    如果您使用 EDNS 客户端子网支持构建 dig，您可以在命令行上进行检查；或者您可以使用在线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 公共 DNS 的 IPv6 地址时，您的客户端 IP 子网当然是 IPv6 子网，当权威服务器回答 NXDOMAIN 时，IPv6 客户端的（缓存？）答案也是 NXDOMAIN。如果您将查询发送到 Google 公共 DNS 的 IPv4 地址，则您的客户端子网是 IPv4 子网，并且您会得到正确的（可能是缓存的）答案。

    • 3

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

    • 1

相关问题