Issue running "dig txt rs.dns-oarc.net" on 9.12

[Matthew Pounsett]

On 26 January 2018 at 16:23, NNEX Support <support at nnex.net> wrote:

> 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).
>
>
[...]


> When I try to run "dig txt rs.dns-oarc.net" I get SERVFAIL. The logs show:
>

[...]


>
> However if I run "dig txt rs.dns-oarc.net +trace" and then "dig txt
> rs.dns-oarc.net" the query completes as expected. It continues to
> complete as expected until I restart named.
>

There's an insecure delegation (NS set, and NSEC proving the nonexistence
of a DS set) from dns-oarc.net to rs.dns-oarc.net.  However, there's
disagreement between the parent and child about what name servers actually
serve rs.dns-oarc.net, 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.

<http://dnsviz.net/d/rs.dns-oarc.net/WbCr7w/dnssec/>

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.

"dig txt rs.dns-oarc.net +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 rs.dns-oarc.net" a second
time a few seconds later without the +trace query would probably give you
the exact same result.

You can track this if you turn on and examine the 'resolver' logging
channel in your recursive name server.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20180127/f72b3f3e/attachment.html>