dig @server foobar +trace +recurse

[John Miller]

>
> 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.
>
>
I just love those "frenzied reading of manpages" moments -- they're
definitely not the easiest thing to skim when you're in the heat of the
moment.  Depending on the program, they sometimes require a state of Zen
calmness to get what you need.  You got to learn the hard way!


> 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 use stub zones for this purpose - a forwarding zone is what you want if
you're forwarding to another _recursive_ nameserver (say for caching
purposes), but if you're just telling your recursors which authoritative
NSs to use, then stub zones are what you want.  In terms of the actual DNS
queries that go over the wire, it's whether the RD bit is/isn't set.

Good luck!

John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20150709/1ae46022/attachment.html>