dig +trace question

[Ronald F. Guilmette]

In message <4E8F2E2C-7571-44DD-B012-57543DEBD4C3 at ncartron.org>,
Nico Cartron <nicolas at ncartron.org> wrote:

>Are you sure it's not your setup?
>I have plenty of dig running on FreeBSD (with bind-utils 9.14) and also
>Debian and they work just fine.

You know what?  I think we may both be right.

Checking now, I think I see the problem.  There is some sort of a problematic
interaction happening -only- between "dig +trace" and either unbound or
local-unbound.

On my old Ubuntu 16.04 system, /etc/resolv.conf contains only:

     nameserver 8.8.8.8
     nameserver 8.8.4.4

(Those are the public Google name servers, of course.)

On that system "dig +trace" works, no problem.

On my two newer systems, Ubuntu 18.04 and FreeBSD 12.0 instead of me relying
on Google's public name servers, the /etc/resolv.conf  files on these two
newer systems both contain only:

    nameserver 127.0.0.1

On one, I'm running a local instance of unbound, and on the other I am
running a local instance of local-unbound.  On these two systems "dig +trace"
DOES NOT just work.  In fact it fails essentally immediately in both cases,
regardless of whether you're trying to do the +trace on a normal sort of FQDN
-or- for some .in-addr.arpa name, where you give the argument as "-x A.B.C.D".

HOWEVER I found a trivial way to make the +trace work even on these systems.
Apparently, you just have to goose it a bit, and just get it sort-of kick
started.  And you can do that just by simply giving it a clear idea of
where it should begin the whole process.  You can do that by simply appending
"@a.root-servers.net" to the end of the command line.  If you do that, then
the trace works as expexcted.  (NOTE:  It is not necessary to use the "A"
root server in particular.  Any one of the root servers seems to do just
as well.)

So now, this all begs the Rodney King question:  Can't we all just get along?

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?


Regards,
rfg