☰

如何修复/调试无意义的绑定响应

tag-icon • tag-icon bind
如何修复/调试无意义的绑定响应

突然间，我的绑定服务器被 .ch 名称服务器返回的 NXDOMAIN 所吸引。其他服务器可以很好地解析它们。此服务器可以很好地解析大多数查询，但这个。

我发出了以下命令：

rndc flush
rndc reload
tcpdump -vvvn -i eth0 udp port 53&
dig c.nic.ch

并得到以下结果：

18:02:36.002819 IP (tos 0x0, ttl 64, id 27843, offset 0, flags [none], proto UDP (17), length 56)
    192.168.4.1.39276 > 192.203.230.10.53: [bad udp cksum 0x6bb5 -> 0xf2b0!] 29864 [1au] NS? . ar: . OPT UDPsize=4096 DO (28)
18:02:36.002834 IP (tos 0x0, ttl 64, id 28762, offset 0, flags [none], proto UDP (17), length 65)
    192.168.4.1.53256 > 192.203.230.10.53: [bad udp cksum 0x6bbe -> 0x73b1!] 19961 [1au] A? c.nic.ch. ar: . OPT UDPsize=4096 DO (37)
18:02:36.004518 IP (tos 0x0, ttl 57, id 5454, offset 0, flags [DF], proto UDP (17), length 878)
    192.203.230.10.53 > 192.168.4.1.53256: [udp sum ok] 19961- q: A? c.nic.ch. 0/10/17 ns: ch. [2d] NS a.nic.ch., ch. [2d] NS b.nic.ch., ch. [2d] NS c.nic.ch., ch. [2d] NS d.nic.ch., ch. [2d] NS e.nic.ch., ch. [2d] NS f.nic.ch., ch. [2d] NS g.nic.ch., ch. [2d] NS h.nic.ch., ch. [1d] DS, ch. [1d] RRSIG ar: a.nic.ch. [2d] A 130.59.31.41, a.nic.ch. [2d] AAAA 2001:620:0:ff::56, b.nic.ch. [2d] A 130.59.31.43, b.nic.ch. [2d] AAAA 2001:620:0:ff::58, c.nic.ch. [2d] A 147.28.0.39, c.nic.ch. [2d] AAAA 2001:418:1::39, d.nic.ch. [2d] A 200.160.0.5, d.nic.ch. [2d] AAAA 2001:12ff:0:a20::5, e.nic.ch. [2d] A 194.0.17.1, e.nic.ch. [2d] AAAA 2001:678:3::1, f.nic.ch. [2d] A 194.146.106.10, f.nic.ch. [2d] AAAA 2001:67c:1010:2::53, g.nic.ch. [2d] A 194.0.1.40, g.nic.ch. [2d] AAAA 2001:678:4::28, h.nic.ch. [2d] A 85.119.5.230, h.nic.ch. [2d] AAAA 2a03:bd80:36::1:203:230, . OPT UDPsize=1472 DO (850)

其中 192.168.4.1 是我的绑定服务器，192.203.230.10 是 e.root-servers.net。这bad udp cksum是因为它是在硬件中完成的。

因此，对 19961 的回应有 0 个答案 / 10 个 NS / 17 个附加答案。

下一个：

18:02:36.005091 IP (tos 0x0, ttl 64, id 52528, offset 0, flags [none], proto UDP (17), length 65)
    192.168.4.1.49672 > 194.0.1.40.53: [bad udp cksum 0x8810 -> 0x9473!] 7909 [1au] A? c.nic.ch. ar: . OPT UDPsize=4096 DO (37)

18:02:36.030838 IP (tos 0x0, ttl 56, id 31615, offset 0, flags [DF], proto UDP (17), length 179)
    194.0.1.40.53 > 192.168.4.1.49672: [udp sum ok] 7909*- q: A? c.nic.ch. 2/0/1 c.nic.ch. [2d] A 147.28.0.39, c.nic.ch. [2d] RRSIG ar: . OPT UDPsize=4096 DO (151)

其中 194.0.1.40 是 g.nic.ch。因此，7909 的权威 (*) 响应有 2 个答案 / 0 个 NS / 1 个附加答案。我会说 147.28.0.39 是 c.nic.ch 的查询地址。然而，dig 输出是：

; <<>> DiG 9.9.5-9+deb8u17-Debian <<>> c.nic.ch
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 49174
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;c.nic.ch.          IN  A

;; Query time: 29 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Jun 25 18:02:36 CEST 2019
;; MSG SIZE  rcvd: 37

从今天早上开始就一直这样。这怎么可能呢？我该怎么做才能解决这个问题？

答案1

为了调试该行为，我将整个 /etc/bind 目录复制到一台空闲的机器上，然后在那里设置 OPTIONS="-g -d 4" 以进行屏幕转储。发出查询后，我得到了：

29-Jun-2019 18:52:40.429 client 127.0.0.1#40362: UDP request
29-Jun-2019 18:52:40.429 client 127.0.0.1#40362: view internal: request is not signed
29-Jun-2019 18:52:40.429 client 127.0.0.1#40362: view internal: recursion available
29-Jun-2019 18:52:40.429 client 127.0.0.1#40362: view internal: query
29-Jun-2019 18:52:40.429 client 127.0.0.1#40362 (a.nic.ch): view internal: query: a.nic.ch IN A + (127.0.0.1)
29-Jun-2019 18:52:40.429 client 127.0.0.1#40362 (a.nic.ch): view internal: query (cache) 'a.nic.ch/A/IN' approved
29-Jun-2019 18:52:40.429 client 127.0.0.1#40362 (a.nic.ch): view internal: replace
29-Jun-2019 18:52:40.429 clientmgr @0x7f968ae22010: get client
29-Jun-2019 18:52:40.429 clientmgr @0x7f968ae22010: create new
29-Jun-2019 18:52:40.429 clientmgr @0x7f968ae22010: clientmctx
29-Jun-2019 18:52:40.429 client @0x7f967800fd50: create
29-Jun-2019 18:52:40.430 fetch: a.nic.ch/A
29-Jun-2019 18:52:40.430 client @0x7f967800fd50: udprecv
29-Jun-2019 18:52:40.430 fetch: ./NS
29-Jun-2019 18:52:40.552 enforced delegation-only for 'ch' (a.nic.ch/A/IN) from 194.0.17.1#53
29-Jun-2019 18:52:40.552 client 127.0.0.1#40362 (a.nic.ch): view internal: send
29-Jun-2019 18:52:40.552 client 127.0.0.1#40362 (a.nic.ch): view internal: sendto
29-Jun-2019 18:52:40.552 client 127.0.0.1#40362 (a.nic.ch): view internal: senddone
29-Jun-2019 18:52:40.552 client 127.0.0.1#40362 (a.nic.ch): view internal: next
29-Jun-2019 18:52:40.552 client 127.0.0.1#40362 (a.nic.ch): view internal: endrequest
29-Jun-2019 18:52:40.552 fetch completed at ../../../lib/dns/resolver.c:8455 for a.nic.ch/A in 0.122265: success/success [domain:ch,referral:1,restart:1,qrysent:1,timeout:0,lame:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:0]

那enforced delegation-only是罪魁祸首。这是一项源于滥用通配符记录的功能，泽布拉克解决方案是禁用该功能，或者排除“ch”。

相关内容