Re: Bind failures following update/reboot w/ 9.18.1
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. 2001:500:a8::e, h.root-servers.net. A 198.97.190.53, h.root-servers.net. 2001:500:1::53, l.root-servers.net. A 199.7.83.42, l.root-servers.net. 2001:500:9f::42, i.root-servers.net. A 192.36.148.17, i.root-servers.net. 2001:7fe::53, a.root-servers.net. A 198.41.0.4, a.root-servers.net. 2001:503:ba3e::2:30, d.root-servers.net. A 199.7.91.13, d.root-servers.net. 2001:500:2d::d, c.root-servers.net. A 192.33.4.12, c.root-servers.net. 2001:500:2::c, b.root-servers.net. A 199 .9.14.201, b.root-servers.net. 2001:500:200::b, j.root-servers.net. A 192.58.128.30, j.root-servers.net. 2001:503:c27::2:30, k.root-servers.net. A 193.0.14.129, k.root-servers.net. 2001:7fd::1, g.root-servers.net. A 192.112.36.4, g.root-servers.net. 2001:500:12::d0d, m.root-servers.net. A 202.12.27.33, m.root-servers.net. 2001:dc3::35, f.root-servers.net. A 192.5.5.241, f.root-servers.net. 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. 2001:501:b1f9: :30, l.gtld-servers.net. 2001:500:d937::30, k.gtld-servers.net. 2001:503:d2d::30, j.gtld-servers.net. 2001:502:7094::30, i.gtld-servers.net. 2001:503:39c1::30, h.gtld-servers.net. 2001:502:8cc::30, g.gtld-servers.net. 2001:503:eea3::30, f.gtld-servers.net. 2001:503:d414::30, e.gtld-servers.net. 2001:502:1ca1::30, d.gtld-servers.net. 2001:500:856e::30, c.gtld-servers.net. 2001:503:83eb::30, b.gtld-servers.net. 2001:503:231d::2:30, a.gtld-servers.net. 2001:503:a83e::2:30, . OPT UDPsize=1232 DO [COOKIE 550d5a0c53614d12 010063ab973b23407748d90aba57] (1193) > On May 13, 2022, at 10:34 AM, Greg Choules > 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 > 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
Re: Troubleshooting scripted named startup
Hi,running latest upstream version first might save you some time, it’s this:named can create unrecoverable managed-keys.jnl file (#2895) · Issues · ISC Open Source Projects / BIND · GitLabgitlab.isc.orgOndrej--Ondřej Surý — ISC (He/Him)My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.On 28. 12. 2022, at 1:51, Philip Prindeville wrote:Hi,I notice that went Bind 9.18.7 comes up on OpenWRT, and I'm running it as a local resolver, resolution initially doesn't work and I get a lot of noise in /var/log/messages like:Dec 27 17:27:12 OpenWrt named[13171]: validating org/DS: no valid signature foundDec 27 17:27:12 OpenWrt named[13171]: no valid RRSIG resolving 'org/DS/IN': 193.0.14.129#53Dec 27 17:27:12 OpenWrt named[13171]: validating org/DS: no valid signature foundDec 27 17:27:12 OpenWrt named[13171]: no valid RRSIG resolving 'org/DS/IN': 198.97.190.53#53Dec 27 17:27:12 OpenWrt named[13171]: validating org/DS: no valid signature foundDec 27 17:27:12 OpenWrt named[13171]: no valid RRSIG resolving 'org/DS/IN': 202.12.27.33#53Dec 27 17:27:12 OpenWrt named[13171]: broken trust chain resolving '_.linksys.pool.ntp.org/A/IN': 185.209.85.151#53Dec 27 17:27:12 OpenWrt named[13171]: validating 0.linksys.pool.ntp.org/A: bad cache hit (org/DS)Dec 27 17:27:12 OpenWrt named[13171]: broken trust chain resolving '0.linksys.pool.ntp.org/A/IN': 45.127.112.23#53Dec 27 17:27:13 OpenWrt named[13171]: validating tabletcaptiveportal.com/A: bad cache hit (com/DS)Dec 27 17:27:13 OpenWrt named[13171]: broken trust chain resolving 'tabletcaptiveportal.com/A/IN': 205.251.195.137#53Dec 27 17:27:13 OpenWrt named[13171]: validating syringanetworks.net/SOA: bad cache hit (net/DS)Dec 27 17:27:13 OpenWrt named[13171]: broken trust chain resolving '_.voip.syringanetworks.net/A/IN': 66.232.66.3#53Dec 27 17:27:13 OpenWrt named[13171]: validating syringanetworks.net/SOA: bad cache hit (net/DS)Dec 27 17:27:13 OpenWrt named[13171]: broken trust chain resolving '_._udp.voip.syringanetworks.net/A/IN': 66.232.66.3#53Dec 27 17:27:13 OpenWrt named[13171]: validating syringanetworks.net/SOA: bad cache hit (net/DS)Dec 27 17:27:13 OpenWrt named[13171]: broken trust chain resolving '_sip._udp.voip.syringanetworks.net/SRV/IN': 66.232.66.3#53Until I run a script that contains:#!/bin/shrm -f /tmp/managed-keys.bind* /tmp/*.jnlrndc managed-keys refreshrndc managed-keys sync/etc/init.d/named restartAnd the "restart" command basically kills the old instance of the server, then restarts it. Then the errors go away and everything works.What does this point to as being wrong in the startup scripts so I can fix it?Thanks,-Philip-- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this listISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.bind-users mailing listbind-users@lists.isc.orghttps://lists.isc.org/mailman/listinfo/bind-users-- 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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Records "not" too long fails with "ran out of space"
Configuring my RPZ installation, the zone fails to load because some register are "too long". The error in the logs is something like: """ dns_master_load: ../primarios/db.rpz.local:137146: ran out of space """ I did some tests and the zone load fails if records are longer than 243 characters. According to RFCs, I understand that it should work for records up to 256 characters, with a maximum of 63-64 characters per label. As I said, my zone fails to load if any domain in the RPZ is bigger than 243 characters. Currently, my RPZ zone structure is something like: """ Z..X.com CNAME . """ This is bind 9.16. I needed to delete some "long" records and I wonder why is my bind rejecting them. -- Jesús Cea Avión _/_/ _/_/_/_/_/_/ j...@jcea.es - https://www.jcea.es/_/_/_/_/ _/_/_/_/ _/_/ Twitter: @jcea_/_/_/_/ _/_/_/_/_/ jabber / xmpp:j...@jabber.org _/_/ _/_/_/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/_/_/ _/_/_/_/ _/_/ "My name is Dump, Core Dump" _/_/_/_/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -- 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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Records "not" too long fails with "ran out of space"
First of all, it’s harder to help you if you don’t share the real domains, but let’s suppose at least the rpz.local is real. The maximum length is **255** including the label length for each label. I have no idea where you got 256. Each label have maximum length of 63 bytes (not 63-64). Now, your 243 is actually 244 (first label also have to have length) + 4 (rpz) + 6 (local) + 1 (root) is exactly 255. Ondrej -- Ondřej Surý — ISC (He/Him) My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 27. 12. 2022, at 16:50, Jesus Cea wrote: > > Configuring my RPZ installation, the zone fails to load because some > register are "too long". The error in the logs is something like: > > """ > dns_master_load: ../primarios/db.rpz.local:137146: ran out of space > """ > > I did some tests and the zone load fails if records are longer than 243 > characters. According to RFCs, I understand that it should work for records > up to 256 characters, with a maximum of 63-64 characters per label. > > As I said, my zone fails to load if any domain in the RPZ is bigger than 243 > characters. Currently, my RPZ zone structure is something like: > > """ > Z..X.com CNAME . > """ > > This is bind 9.16. > > I needed to delete some "long" records and I wonder why is my bind rejecting > them. > > -- > Jesús Cea Avión _/_/ _/_/_/_/_/_/ > j...@jcea.es - https://www.jcea.es/_/_/_/_/ _/_/_/_/ _/_/ > Twitter: @jcea_/_/_/_/ _/_/_/_/_/ > jabber / xmpp:j...@jabber.org _/_/ _/_/_/_/ _/_/ _/_/ > "Things are not so easy" _/_/ _/_/_/_/ _/_/_/_/ _/_/ > "My name is Dump, Core Dump" _/_/_/_/_/_/ _/_/ _/_/ > "El amor es poner tu felicidad en la felicidad de otro" - Leibniz > -- > 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@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- 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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Troubleshooting scripted named startup
Hi, I notice that went Bind 9.18.7 comes up on OpenWRT, and I'm running it as a local resolver, resolution initially doesn't work and I get a lot of noise in /var/log/messages like: Dec 27 17:27:12 OpenWrt named[13171]: validating org/DS: no valid signature found Dec 27 17:27:12 OpenWrt named[13171]: no valid RRSIG resolving 'org/DS/IN': 193.0.14.129#53 Dec 27 17:27:12 OpenWrt named[13171]: validating org/DS: no valid signature found Dec 27 17:27:12 OpenWrt named[13171]: no valid RRSIG resolving 'org/DS/IN': 198.97.190.53#53 Dec 27 17:27:12 OpenWrt named[13171]: validating org/DS: no valid signature found Dec 27 17:27:12 OpenWrt named[13171]: no valid RRSIG resolving 'org/DS/IN': 202.12.27.33#53 Dec 27 17:27:12 OpenWrt named[13171]: broken trust chain resolving '_.linksys.pool.ntp.org/A/IN': 185.209.85.151#53 Dec 27 17:27:12 OpenWrt named[13171]: validating 0.linksys.pool.ntp.org/A: bad cache hit (org/DS) Dec 27 17:27:12 OpenWrt named[13171]: broken trust chain resolving '0.linksys.pool.ntp.org/A/IN': 45.127.112.23#53 Dec 27 17:27:13 OpenWrt named[13171]: validating tabletcaptiveportal.com/A: bad cache hit (com/DS) Dec 27 17:27:13 OpenWrt named[13171]: broken trust chain resolving 'tabletcaptiveportal.com/A/IN': 205.251.195.137#53 Dec 27 17:27:13 OpenWrt named[13171]: validating syringanetworks.net/SOA: bad cache hit (net/DS) Dec 27 17:27:13 OpenWrt named[13171]: broken trust chain resolving '_.voip.syringanetworks.net/A/IN': 66.232.66.3#53 Dec 27 17:27:13 OpenWrt named[13171]: validating syringanetworks.net/SOA: bad cache hit (net/DS) Dec 27 17:27:13 OpenWrt named[13171]: broken trust chain resolving '_._udp.voip.syringanetworks.net/A/IN': 66.232.66.3#53 Dec 27 17:27:13 OpenWrt named[13171]: validating syringanetworks.net/SOA: bad cache hit (net/DS) Dec 27 17:27:13 OpenWrt named[13171]: broken trust chain resolving '_sip._udp.voip.syringanetworks.net/SRV/IN': 66.232.66.3#53 Until I run a script that contains: #!/bin/sh rm -f /tmp/managed-keys.bind* /tmp/*.jnl rndc managed-keys refresh rndc managed-keys sync /etc/init.d/named restart And the "restart" command basically kills the old instance of the server, then restarts it. Then the errors go away and everything works. What does this point to as being wrong in the startup scripts so I can fix it? 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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind failures following update/reboot w/ 9.18.1
> On May 14, 2022, at 12:35 AM, Matus UHLAR - fantomas > wrote: > > On 13.05.22 10:06, Philip Prindeville 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 > > doesn't your ISP block or intercept DNS queries? My MSP does many stupid things (like not allowing business customers to own their own modems, or residential customers to own static IP address blocks), but that's not one of them... -Philip > > -- > Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ > Warning: I wish NOT to receive e-mail advertising to this address. > Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. > - Holmes, what kind of school did you study to be a detective? > - Elementary, Watkins. -- Daffy Duck & Porky Pig > -- > 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@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- 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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
