This particular set of nameservers appears to have uncovered an issue in one of the CVE fixes. I’ve opened an issue.
https://gitlab.isc.org/isc-projects/bind9/-/issues/5695 teckbote.de. 300 IN NS ns1.nepustil.net. teckbote.de. 300 IN NS ns.nepustil.com. nepustil.net. 86400 IN NS ns1.ispeg.eu. nepustil.net. 86400 IN NS ns.nepustil.de. nepustil.net. 86400 IN NS ns.nepustil.eu. nepustil.com. 86400 IN NS ns1.nepustil.net. nepustil.com. 86400 IN NS ns.nepustil.de. nepustil.eu. 83832 IN NS ns1.nepustil.net. nepustil.eu. 83832 IN NS ns.nepustil.de. nepustil.de. 83550 IN NS ns1.nepustil.net. nepustil.de. 83550 IN NS ns.nepustil.com. nepustil.de. 83550 IN NS ns1.ispeg.eu. ispeg.eu. 83787 IN NS ns.LF.net. ispeg.eu. 83787 IN NS ns.nepustil.de. ispeg.eu. 83787 IN NS ns1.ispeg.eu. ns1.ispeg.eu. 86400 IN A 178.132.64.130 ns1.ispeg.eu. 86400 IN AAAA 2a03:2380:2:4::1 So to lookup any of teckbote.de, nepustil.net, nepustil.com, nepustil.de the resolver is dependent on ns1.ispeg.eu running as all the other listed nameservers can only be discovered if ns1.ispeg.eu is running. Looking up ns1.ispeg.eu depends on ns1.ispeg.eu running or the nameservers for lf.net running. lf.net. 3600 IN NS dns2.lf.net. lf.net. 3600 IN NS dns1.lf.net. lf.net. 3600 IN NS dns3.lf.net. dns1.LF.net. 172800 IN A 212.9.160.10 dns2.LF.net. 172800 IN A 62.50.111.2 dns3.LF.net. 172800 IN A 213.178.170.2 > On 19 Dec 2025, at 02:55, Andreas S. Kerber via bind-users > <[email protected]> wrote: > > Hi, > > just upgraded some resolver instances from 9.20.16 to 9.20.17 and I'm > noticing issues resolving some domain names. > > Using: 9.20.16 > # dig -t ns teckbote.de | grep status: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9717 > > Using: 9.20.17 > # dig -t ns teckbote.de | grep status: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 62960 > > > This issue seems to be (once again) the result of a bad setup at a particular > domain (they don't seem to have any glue records at all. DUH...). > > I just wonder if there is a expected behaviour change between 9.20.16 and > 9.20.17 and whether anybody else can resolve the name above using 9.20.17? > > Important Note: resolving works fine when using "dig +trace" (I guess with > +trace the glue for the NS is fetched as part of the trace operation and > therefore does not expose this resolving problem) > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from > this list. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list.
