stub zones
Kevin Darcy
kcd at chrysler.com
Mon Jun 2 22:07:06 UTC 2014
The typical use case for a stub zone is where the delegation chain is
broken, or incorrect, but you don't want to incur the overhead of
slaving the zone (or some other sort of bureaucratic snafu like the
owner/admin of the zone not letting you do zone transfers).
As a general rule, stub zones are usually a lesser evil than forwarding:
A) because there may be no nameservers available for the domain, which
honor recursion, or
B) in cases where there is a multi-level hierarchy, some of the
published nameservers for descendant zones may be closer, more reliable,
etc. than those responsible for the apex of the hierarchy, and the
algorithm built into named will help to optimize such traffic dynamically
I'm not sure I understand the view complexity you reference. Could you
clarify? Note that client source address isn't the *only* way to select
views -- many folks with complicated view configurations use TSIG keys
as a view-selection mechanism.
- Kevin
On 6/2/2014 5:37 PM, Nex6|Bill wrote:
> I guess, i am having issues with this(maybe i am not fully getting
> it), and yea I know large environments sometimes have multiple sets of
> name servers. sometimes department level (i have this issue in my shop
> its a damn mess)
>
> if all the zones are delegated properly the local resolver will query
> its NS, and that NS will know where it should go next, whether its a
> internet side query or navigating the mess of local NS servers that
> some folks have. in the case of DNS views, where the local resolver
> may NOT be able to get to the correct view a forwarder would be better
> so you can point to the internal view NS. This keeps NS servers that
> are authoritative and responsible for handing out resource records
> they hand them out. and unless, your dealing with a load balancer
> (which is its own exception) which needs short TTLs, a caching
> forwarder is far better in most cases..
>
> I guess, I am still not sure of the point of a stub zone, where you
> point to a different NS? than the authoritative NS for that zone?
> unless your changing the records
> which is all bad....
>
>
>
> On Monday, June 2, 2014 2:18 PM, John Miller <johnmill at brandeis.edu>
> wrote:
>
>
>
> Not quite, Bill. You point the zone at a different name server, but
> _your_own_nameserver_ still does the iterative queries to make things
> happen. It just queries a different set of nameservers than would
> happen through normal delegation.
>
> The only recursive query going on is from the client to your
> nameserver.
>
> Since you asked the question, what would you propose as an
> alternative
> for folks running multiple sets of nameservers with different info
> on them?
>
> John
>
>
> On 06/02/2014 04:52 PM, Nex6|Bill wrote:
> > so, stub zones allow you to point a zone to a different name
> server, and
> > that name-server; to recurse to get the records for that zone.
> why? why
> > not let DNS work the way it is suppose to and let your name
> servers work
> > for you to the authoritative name-server to get the records? unless,
> > your changing the zone records, which is why most people I know
> use it
> > for, which is evil :)
> >
> > its almost the same, as creating a local zone for something your not
> > authoritative for and then having to maintain those records. but, i
> > guess their may be cases where it may be useful.... i guess....
> >
> >
> > On Monday, June 2, 2014 1:33 PM, John Miller
> <johnmill at brandeis.edu <mailto:johnmill at brandeis.edu>> wrote:
> >
> >
> >
> > Evil? Seems a bit strong. Unusual? Use with caution? OK.
> >
> > Stub zones mean that you're using a different set of
> authoritative
> > nameservers for a particular domain. You're not storing all
> of that
> > domain's records, except through the usual caching process.
> If it's
> > a domain you control, where's the harm?
> >
> > Also, let's say that you're nominally a caching-only nameserver.
> > You're responsible for making iterative queries, and you do
> not want
> > the RD bit set. AFAIK, stub zones are the way to accomplish
> that.
> > Forward zones just pass recursive queries on to someplace else.
> >
> > John
> >
> >
> >
> >
> > On Mon, Jun 2, 2014 at 4:02 PM, Nex6|Bill <n6ghost at yahoo.com
> <mailto:n6ghost at yahoo.com>
> > <mailto:n6ghost at yahoo.com <mailto:n6ghost at yahoo.com>>> wrote:
> >
> > recently, a question came up about "stub" zones came up
> and what
> > they are and are they part of the DNS standards or are they a
> > good idea. i said, they are evil and should not be used
> if you
> > can avoid it. they way I understand them is the are when you
> > create local zones for zones you are NOT authoritative
> for. and;
> > the records in the stub zone do not update when the
> > authoritative NS does.
> >
> > correct? thoughts?
> >
> > -Nex6
> >
> >
> >
> > _______________________________________________
> > Please visit
> https://lists.isc.org/mailman/listinfo/bind-users
> > to unsubscribe from this list
> >
> > bind-users mailing list
> > bind-users at lists.isc.org <mailto:bind-users at lists.isc.org>
> <mailto:bind-users at lists.isc.org <mailto:bind-users at lists.isc.org>>
> > https://lists.isc.org/mailman/listinfo/bind-users
> >
> >
> >
> >
> > --
> > John Miller
> > Systems Engineer
> > Brandeis University
> > johnmill at brandeis.edu <mailto:johnmill at brandeis.edu>
> <mailto:johnmill at brandeis.edu <mailto:johnmill at brandeis.edu>>
>
> >
> >
>
>
>
>
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20140602/fe2b9f4a/attachment.html>
More information about the bind-users
mailing list