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