dig @server foobar +trace +recurse

Darcy Kevin (FCA) kevin.darcy at fcagroup.com
Thu Jul 9 15:34:53 UTC 2015

I concur – if the requirement is to access a “special” version of the zone, which has different data than the version which is found by following the regular delegation hierarchy, then “stub” or “static-stub” is the way to go. That really is the whole _raison_d’etre_ for stub/static-stub – to override the resolver’s notion of where to pull the authoritative data. Sometimes stub/static-stub is necessary to work around delegations which are “broken” in some way (e.g. delegated nameservers aren’t reachable from some parts of a private network, or there’s a query-permissions problem). But that should be considered a temporary solution, until the underlying problem can be fixed.

Forwarding is only to get around connectivity restrictions (e.g. internal resolvers not being able to talk directly to Internet nameservers) or in attempts (usually futile) to optimize query performance.

                                                                                                                                                                                                                                                                - Kevin

From: bind-users-bounces at lists.isc.org [mailto:bind-users-bounces at lists.isc.org] On Behalf Of John Miller
Sent: Thursday, July 09, 2015 10:52 AM
To: Anne Bennett
Cc: Bind Users Mailing List
Subject: Re: dig @server foobar +trace +recurse

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!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20150709/cefffa79/attachment-0001.html>

More information about the bind-users mailing list