<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 17/04/2024 11:41, John Thurston
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:501a1c1f-7f72-bb90-048a-49a9f68f9ebe@alaska.gov">
<p>I'm seeing strange behavior with a BIND 9.18.24 resolver and
dnssec-failed.org.</p>
<p>With no dnssec-validation line (or with "dnssec-validation
auto") in the .conf, querying for <a
class="moz-txt-link-abbreviated"
href="http://www.dnssec-failed.org" moz-do-not-send="true">www.dnssec-failed.org</a>
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.</p>
<p>Is this supposed to be happening?<br>
</p>
<p>When I examine the process with delv and my eyeballs, I can't
see why it is succeeding with dig and my validating resolver.</p>
<p>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.</p>
<p><br>
</p>
<p>The following one-liner:</p>
<p># rndc flush && while true; do dig -4 <a
class="moz-txt-link-abbreviated"
href="http://www.dnssec-failed.org" moz-do-not-send="true">www.dnssec-failed.org</a>.
A @localhost; sleep 1; done</p>
</blockquote>
<p>Hi John.</p>
<p>FYI I tried running your command myself and didn't see the same
problem.</p>
<p>The first thing you'd want to rule out is the possibility that
you have more than one resolver running? E.g.<br>
</p>
<pre>sudo netstat -anp | awk '{ if ($4 ~ /:53$/) print; }' | sort -u
</pre>
<p>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?</p>
<p>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?<br>
</p>
<p>Nick.<br>
</p>
</body>
</html>