0

All of a sudden my bind server was captivated by returning NXDOMAIN for .ch name servers. Other servers resolve them fine. This server resolves most queries fine, but this.

I issued the following commands:

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

and got the following:

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)

Where 192.168.4.1 is my bind server, 192.203.230.10 is e.root-servers.net. The bad udp cksum is because it's done in hardware.

So response for 19961 has 0 answer / 10 NS / 17 additional.

Next:

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)

Where 194.0.1.40 is g.nic.ch. So authoritative (*) response for 7909 has 2 answer / 0 NS / 1 additional. I would say 147.28.0.39 is the queried address of c.nic.ch. Yet, dig output is:

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

It is going on that way since this morning. How can that even be possible? What should I do to fix it?

1 Answer 1

0

To debug that behavior I copied the whole /etc/bind directory to an idle machine and there I set OPTIONS="-g -d 4" to have an on-screen dump. After issuing a query I got:

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]

That enforced delegation-only is the culprit. It is a feature originated by the abuse of wildcard records, recounted by Zebulak. The solution is to either disable the feature, or exclude "ch".

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .