resolver change between 9.20.16 and 9.20.17

[Mark Andrews]

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 <bind-users at lists.isc.org> 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: marka at isc.org