dig +trace question

[Ronald F. Guilmette]

In message <b2097c36-f90e-53ba-daa7-669593eec77d at ripe.net>, 
Anand Buddhdev <anandb at ripe.net> wrote:

>On 21/06/2019 04:55, Ronald F. Guilmette wrote:
>
>> What is it about unbound/local-unbound that makes it not plug and play well
>> with dig +trace?  What is it that Google's public name servers are doing
>> that a local running instance of unbound and/or local-unbound isn't doing?
>
>This is a very subtle bug.
>
>Unbound does NOT allow non-recursive queries by default. If you want to
>allow non-recursive queries, you have to configure this with the
>"allow_snoop" ACL.
>
>Now, dig with +trace used to send all its queries without setting the RD
>flag. Most recursive resolvers don't mind, and will still answer.
>However, unbound doesn't like this. When you run dig with +trace, and
>you don't provide it a root name server to start with, then it asks the
>local resolver for ./NS, without the RD flag, and unbound won't answer.
>
>Funnily enough, this issue was noticed by Tore Anderson, who correctly
>said that dig, even with +trace, should do its initial ./NS query WITH
>the RD flag set. He reported it to ISC in issue #1028, and it has been
>fixed with BIND version 9.14.3. So if you are able to try this newest
>version with your setup, I hypothesise that it will work.

Thanks for all of the detailed info!  It most probably would have taken
me a long long time (and a lot of work) to figure all this out on my
own.

I'll switch to using the 9.14.3 or 9.15.0 dig command as soon as possible.
Until then I have a nice temprary workaround, which is to just append
@a.root-servers.net to my dig +trace commands.


Regards,
rfg


P.S.  Stylistically, I like the dig +trace command output MUCH better
than the equivalent "drill -T" output.  Plus I've just been informed
that "drill -T" doesn't even actually work in conjunction with the -x
option. :-(