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

[Matthew Pounsett]

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

> Good thought but no luck, it doesn’t matter how many times I run “dig txt
> rs.dns-oarc.net” or how long I wait it continues to SERVFAIL until I run
> "dig txt rs.dns-oarc.net +trace" Interestingly I've found that running
> "dig txt dns-oarc.net +trace" isn't enough to fix it, I actually have to
> run "dig txt rs.dns-oarc.net +trace" before things start working.
>

The reason digging against dns-oarc.net doesn't fix rs.dns-oarc.net is
because they're different zones.

I'm not sure why a +trace would have anything to do with what your resolver
does, since dig only talks to it to get the root NS set.  Again, I suggest
you check the 'resolver' logging channel on your recursive resolver.


> I agree, from my limited understanding this seems to describe what is
> happening well. The thing I'm wondering is why? I'm running older visions
> of named (9.9.4, yum provided RPM on CentOS 6) that seem immune to this
> issue. I've been digging through release notes and can't find any setting
> that has changed between the versions that might explain it (I know 9.9.4
> to 9.12 is a big jump, so I'm sure I'm missing something)
>
> The only thing I can think of that has changed in that time, which has
ever caused me query issues, is the addition of DNS cookies in the default
query.  Some broken authoritative servers will incorrectly respond with
things like FORMERR when they see an EDNS option they don't recognize.  I
doubt DNS-OARC is running such a name server, but I haven't looked to see.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20180127/cd7fdf55/attachment-0001.html>