Bind failures following update/reboot w/ 9.18.1

Philip Prindeville philipp_subx at redfish-solutions.com
Wed Dec 28 01:14:13 UTC 2022


Saw this at startup:

18:09:14.595420 IP (tos 0x0, ttl 57, id 35985, offset 0, flags [none], proto UDP (17), length 1167)
    192.58.128.30.53 > 24.116.100.90.53955: [udp sum ok] 64207*- q: DNSKEY? . 4/0/1 . DNSKEY, . DNSKEY, . DNSKEY, . RRSIG ar: . OPT UDPsize=1472 DO (1139)
18:09:14.597537 IP (tos 0x0, ttl 58, id 41236, offset 0, flags [none], proto UDP (17), length 1125)
    192.58.128.30.53 > 24.116.100.90.55298: [udp sum ok] 41666*- q: NS? . 14/0/27 . NS e.root-servers.net., . NS h.root-servers.net., . NS l.root-servers.net., . NS i.root-servers.net., . NS a.root-servers.net., . NS d.root-servers.net., . NS c.root-servers.net., . NS b.root-servers.net., . NS j.root-servers.net., . NS k.root-servers.net., . NS g.root-servers.net., . NS m.root-servers.net., . NS f.root-servers.net., . RRSIG ar: e.root-servers.net. A 192.203.230.10, e.root-servers.net. AAAA 2001:500:a8::e, h.root-servers.net. A 198.97.190.53, h.root-servers.net. AAAA 2001:500:1::53, l.root-servers.net. A 199.7.83.42, l.root-servers.net. AAAA 2001:500:9f::42, i.root-servers.net. A 192.36.148.17, i.root-servers.net. AAAA 2001:7fe::53, a.root-servers.net. A 198.41.0.4, a.root-servers.net. AAAA 2001:503:ba3e::2:30, d.root-servers.net. A 199.7.91.13, d.root-servers.net. AAAA 2001:500:2d::d, c.root-servers.net. A 192.33.4.12, c.root-servers.net. AAAA 2001:500:2::c, b.root-servers.net. A 199.9.14.201, b.root-servers.net. AAAA 2001:500:200::b, j.root-servers.net. A 192.58.128.30, j.root-servers.net. AAAA 2001:503:c27::2:30, k.root-servers.net. A 193.0.14.129, k.root-servers.net. AAAA 2001:7fd::1, g.root-servers.net. A 192.112.36.4, g.root-servers.net. AAAA 2001:500:12::d0d, m.root-servers.net. A 202.12.27.33, m.root-servers.net. AAAA 2001:dc3::35, f.root-servers.net. A 192.5.5.241, f.root-servers.net. AAAA 2001:500:2f::f, . OPT UDPsize=4096 DO (1097)
18:09:14.711891 IP (tos 0x0, ttl 64, id 36874, offset 0, flags [none], proto UDP (17), length 74)
    24.116.100.90.37623 > 192.112.36.4.53: [bad udp cksum 0x618a -> 0x4ab9!] 32625 [1au] A? _.net. ar: . OPT UDPsize=1232 DO [COOKIE 550d5a0c53614d12] (46)
18:09:14.789396 IP (tos 0x0, ttl 246, id 28852, offset 0, flags [DF], proto UDP (17), length 1221)
    192.112.36.4.53 > 24.116.100.90.37623: [udp sum ok] 32625- q: A? _.net. 0/15/27 ns: net. NS h.gtld-servers.net., net. NS d.gtld-servers.net., net. NS i.gtld-servers.net., net. NS a.gtld-servers.net., net. NS m.gtld-servers.net., net. NS l.gtld-servers.net., net. NS j.gtld-servers.net., net. NS g.gtld-servers.net., net. NS e.gtld-servers.net., net. NS f.gtld-servers.net., net. NS c.gtld-servers.net., net. NS b.gtld-servers.net., net. NS k.gtld-servers.net., net. DS, net. RRSIG ar: m.gtld-servers.net. A 192.55.83.30, l.gtld-servers.net. A 192.41.162.30, k.gtld-servers.net. A 192.52.178.30, j.gtld-servers.net. A 192.48.79.30, i.gtld-servers.net. A 192.43.172.30, h.gtld-servers.net. A 192.54.112.30, g.gtld-servers.net. A 192.42.93.30, f.gtld-servers.net. A 192.35.51.30, e.gtld-servers.net. A 192.12.94.30, d.gtld-servers.net. A 192.31.80.30, c.gtld-servers.net. A 192.26.92.30, b.gtld-servers.net. A 192.33.14.30, a.gtld-servers.net. A 192.5.6.30, m.gtld-servers.net. AAAA 2001:501:b1f9::30, l.gtld-servers.net. AAAA 2001:500:d937::30, k.gtld-servers.net. AAAA 2001:503:d2d::30, j.gtld-servers.net. AAAA 2001:502:7094::30, i.gtld-servers.net. AAAA 2001:503:39c1::30, h.gtld-servers.net. AAAA 2001:502:8cc::30, g.gtld-servers.net. AAAA 2001:503:eea3::30, f.gtld-servers.net. AAAA 2001:503:d414::30, e.gtld-servers.net. AAAA 2001:502:1ca1::30, d.gtld-servers.net. AAAA 2001:500:856e::30, c.gtld-servers.net. AAAA 2001:503:83eb::30, b.gtld-servers.net. AAAA 2001:503:231d::2:30, a.gtld-servers.net. AAAA 2001:503:a83e::2:30, . OPT UDPsize=1232 DO [COOKIE 550d5a0c53614d12 0100000063ab973b23407748d90aba57] (1193)




> On May 13, 2022, at 10:34 AM, Greg Choules <gregchoules+bindusers at googlemail.com> wrote:
> 
> Hi Philip.
> Can you run packet captures? I'm running 9.18.0 (close enough?) in Docker and just traced what happens going from "dnssec-validation no;" to "dnssec-validation auto;" It makes a DNSKEY query for "." to one of the roots. The response size was over 900 bytes, so depending on what UDP payload size is advertised there might need to be some retrying over TCP. But you'll only know whether that is happening from a pcap.
> So I'd say.. check EDNS payload size, check what your firewall(s) is/are prepared to let through, check whether DNS/TCP is allowed at all, check if something is doing IP fragmentation (though I wouldn't expect this to come into play with a packet ~1k).
> 
> I hope some of that is useful.
> Cheers, Greg
> 
> On Fri, 13 May 2022 at 17:07, Philip Prindeville <philipp_subx at redfish-solutions.com> wrote:
> After rebooting my OpenWRT router with Bind 9.18.1 yesterday, I started seeing a lot of:
> 
> 
> May 12 19:24:06 OpenWrt named[11061]: validating ./NS: no valid signature found
> May 12 19:24:06 OpenWrt named[11061]: validating net/DS: no valid signature found
> May 12 19:24:06 OpenWrt named[11061]: no valid RRSIG resolving './NS/IN': 192.203.230.10#53
> May 12 19:24:06 OpenWrt named[11061]: no valid RRSIG resolving 'net/DS/IN': 8.8.4.4#53
> May 12 19:24:06 OpenWrt named[11061]: validating com/DS: no valid signature found
> May 12 19:24:06 OpenWrt named[11061]: no valid RRSIG resolving 'com/DS/IN': 8.8.4.4#53
> May 12 19:24:06 OpenWrt named[11061]: validating net/DS: no valid signature found
> May 12 19:24:06 OpenWrt named[11061]: no valid RRSIG resolving 'net/DS/IN': 66.232.64.10#53
> May 12 19:24:06 OpenWrt named[11061]: validating com/DS: no valid signature found
> May 12 19:24:06 OpenWrt named[11061]: no valid RRSIG resolving 'com/DS/IN': 66.232.64.10#53
> 
> 
> In my options, I had:
> 
> dnssec-validation auto;
> 
> But had to turn this off.  It had been working.  This is a production firewall/router.
> 
> What troubleshooting should I do to fix this?
> 
> I had tried:
> 
> rndc managed-keys refresh
> rndc managed-keys sync
> 
> But don't understand why that would have been necessary unless the root keys got updated recently.
> 
> Scrolling to the very top of the logs I see:
> 
> May 12 19:24:04 OpenWrt named[11061]: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out
> 
> Thanks,
> 
> -Philip
> 
> 
> -- 
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users



More information about the bind-users mailing list