Answers for www.dnssec-failed.org with dnssec-validation auto;

Nick Tait nick at tait.net.nz
Wed Apr 17 08:26:43 UTC 2024


On 17/04/2024 11:41, John Thurston wrote:
>
> I'm seeing strange behavior with a BIND 9.18.24 resolver and 
> dnssec-failed.org.
>
> With no dnssec-validation line (or with "dnssec-validation auto") in 
> the .conf, querying for www.dnssec-failed.org returns SERVFAIL, as 
> expected . . until it doesn't. After several seconds of answering 
> SERVFAIL, I start getting NOERROR responses, and IP addresses in the 
> ANSWER. It isn't a predictable number of seconds; sometimes 9, 
> sometimes 20.
>
> Is this supposed to be happening?
>
> When I examine the process with delv and my eyeballs, I can't see why 
> it is succeeding with dig and my validating resolver.
>
> Maybe I'm not looking for the right things with my eyeballs? I'm 
> stumped, and looking for advice for nest-steps in understanding what's 
> going on.
>
>
> The following one-liner:
>
> # rndc flush && while true; do dig -4 www.dnssec-failed.org. A 
> @localhost; sleep 1; done
>
Hi John.

FYI I tried running your command myself and didn't see the same problem.

The first thing you'd want to rule out is the possibility that you have 
more than one resolver running? E.g.

sudo netstat -anp | awk '{ if ($4 ~ /:53$/) print; }' | sort -u

The last column in the output from the command above should show a 
number followed by a slash then a process name, which should be the same 
on every line (e.g. "1804/named"). If it isn't, then see if you can stop 
the other service(s) and then rerun your test?

If you have just a single process listening on port 53, then I'd suggest 
using "tail -f" to watch your BIND logs (or syslog?) while you are 
running your test, to see what is going on from the recursive resolver's 
point of view? Hopefully you'll see something interesting when the 
problem happens?

Nick.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20240417/188b56d8/attachment.htm>


More information about the bind-users mailing list