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-boun...@lists.isc.org
[mailto:bind-users-boun...@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!
John
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
