Как исправить / отладить бессмысленные ответы привязки

Внезапно мой сервер связываний был захвачен возвратом NXDOMAIN для серверов имен .ch. Другие серверы разрешают их нормально. Этот сервер разрешает большинство запросов нормально, но это.

Я выпустил следующие команды:

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 - г.нич.ч. Таким образом, авторитетный (*) ответ для 7909 имеет 2 ответа / 0 NS / 1 дополнительно. Я бы сказал, что 147.28.0.39 - это запрашиваемый адрес c.nic.ch. Тем не менее, копать вывод:

; <<>> 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

Так происходит с утра. Как это вообще возможно? Что я должен сделать, чтобы это исправить?

Чтобы отладить такое поведение, я скопировал весь каталог / 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".