dig @server foobar +trace +recurse

[Anne Bennett]

> For my part, I'd be curious to know what sort of problem
> you're trying to solve with dig.

Oh, I solved it.  I was getting different data for my parent
zone depending where I queried from, but the differences
didn't match what I expected based on an internal/external view
classification of the client resolver.  I eventually realized
that for the data I was examining, my resolvers (which have
access to the outside world) could randomly select an external
authoritative nameserver for my parent zone (external view),
or an internal one (internal view), hence the difference.
And of course there was caching involved as well, so data seemed
to toggle randomly back and forth on my various resolvers.

It's by tracing the queries down from the root zone several
times with "dig +trace" that it finally hit me what was going
on, and in retrospect it's obvious.  At first I had been looking
for some kind of race condition with delegation data from the
grandparent zone getting cached, and then being overridden by
my parent zone's own NS records.  At that point, I was trying
to use @server to try to affect that server's cache by forcing
it to pull certain data into its cache.  But it turns out that
it isn't a child overriding its parents delegations that was
the "problem"; it's the fact that as an internal client, I am
able to access external views as well.  And in the process
of investigating all this, I realized that of course if I
use +trace, all queries after the first one will *not* use
the @server.  Duh.  I just thought I might save someone else
the muddy thinking by offering a clarification for the manpage.

As for the problem itself, I'll probably fix it by setting up
a forwarding zone for my parent zone on my resolvers, to make
sure that I always get the internal view for their data.

> We might be able to shed a little more light on what the
> best command would be for you.

It all worked fine when I stopped barking up the wrong tree.  ;-)

> The +recurse gets overridden when you use +trace:
> 
> +[no]recurse
>            ... Recursion is automatically disabled when the
>            +nssearch or +trace query options are used.
> 
> so you're getting iterative queries whether you want them or not: +trace
> means you're treating yourself as a recursive nameserver,

Yes; an overly quick reading of the docs on my part.  I was trying
to "treat myself as a recursive nameserver", so I stuck in +recurse,
which was the wrong thing to do - fortunately it didn't work.  ;-)

> If you send a single query to a remote nameserver, you're only going to get
> a single response--that's how DNS works.  So if you're looking to see the
> chain of lookups that a remote recursive nameserver takes to reach its
> final response, you can run dig +trace from the remote nameserver, or you
> could run a series of dig @server +norecurse <hostname> queries to get what
> you're looking for.

Right; I wanted the former, and that's what, despite myself,
I got.  That's what comes from not looking seriously at DNS
stuff for months at a time and then trying to reload a lot of
context all at once!

> I admit ignorance on the +showsearch option: I'm not seeing the query flags
> change, nor am I seeing any different output when I run:
> 
> dig @8.8.8.8 trombone.org +showsearch
[...]
> versus
> dig @8.8.8.8 trombone.org
[...]
> Does anyone have insight on +showsearch,

I'm sure someone does, but it's not me - I've bumped into enough
walls for one day!  :-)


Anne.
-- 
Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8
anne at encs.concordia.ca                                    +1 514 848-2424 x2285