<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 26 January 2018 at 16:23, NNEX Support <span dir="ltr"><<a href="mailto:support@nnex.net" target="_blank">support@nnex.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I'm sure I'm doing something wrong, but for the life of me I can't figure out what. I'm running named 9.12 in a simple recursive setup (built from source on CentOS 7).<br>
<br></blockquote><div> </div>[...]<br><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
When I try to run "dig txt <a href="http://rs.dns-oarc.net" rel="noreferrer" target="_blank">rs.dns-oarc.net</a>" I get SERVFAIL. The logs show:<br></blockquote><div><br></div><div>[...]</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
However if I run "dig txt <a href="http://rs.dns-oarc.net" rel="noreferrer" target="_blank">rs.dns-oarc.net</a> +trace" and then "dig txt <a href="http://rs.dns-oarc.net" rel="noreferrer" target="_blank">rs.dns-oarc.net</a>" the query completes as expected. It continues to complete as expected until I restart named.<br></blockquote><div><br></div><div>There's an insecure delegation (NS set, and NSEC proving the nonexistence of a DS set) from <a href="http://dns-oarc.net">dns-oarc.net</a> to <a href="http://rs.dns-oarc.net">rs.dns-oarc.net</a>.  However, there's disagreement between the parent and child about what name servers actually serve <a href="http://rs.dns-oarc.net">rs.dns-oarc.net</a>, and at least some of them are refusing to answer TCP.  It's likely your recursive server is, for whatever reason, being drawn to the ones failing to respond, and not getting good data elsewhere fast enough to answer your query.</div><div><br></div><div><<a href="http://dnsviz.net/d/rs.dns-oarc.net/WbCr7w/dnssec/">http://dnsviz.net/d/rs.dns-oarc.net/WbCr7w/dnssec/</a>></div><div><br></div><div>A bad interaction of timeouts would explain why you get SERVFAIL on the first query, and answers on subsequent queries.  Your first one fails to get a response in time and the recursive server responds with SERVFAIL, but the back-end queries continue and eventually the local cache is populated.  When you come back and ask again, the answers are there waiting for you, requiring no upstream queries.</div><div><br></div><div>"dig txt <a href="http://rs.dns-oarc.net">rs.dns-oarc.net</a> +trace" goes to your local recursive DNS server to get the NS set for the root zone, and then proceeds to query authoritative servers directly for everything else.  It's probably not having any effect on what you're seeing.  Simply doing "dig txt <a href="http://rs.dns-oarc.net">rs.dns-oarc.net</a>" a second time a few seconds later without the +trace query would probably give you the exact same result.</div><div><br></div><div>You can track this if you turn on and examine the 'resolver' logging channel in your recursive name server.  </div></div><br></div></div>