johnmill at brandeis.edu
Mon Jun 2 22:38:45 UTC 2014
So... without stub zones, you know the drill: your local resolver follows
delegation, starting from the root nameservers. Delegation happens, and
life is good. If you're running views, then things work fine as well: your
view just needs to be configured to allow queries from your local resolvers.
Let's say you're testing out a new set of authoritative DNS servers for
your domain. These are authoritative-only nameservers (not necessarily
BIND, either: plenty of other software and cloud services out there). You
want your local resolvers to not follow the usual delegation process: you
want them to begin delegation with your authoritative NSs.
>From my experience, the biggest difference between stub zones and forward
zones is that with stub zones, the RD bit is unset--it's up to the local
resolver to follow delegation, starting with the nameservers configured in
the stub zone, rather than starting with the root NS.
With forwarders, the RD bit is unchanged--you can easily end up sending
recursive queries to a server that isn't set up to handle them. You might
also end up not getting a full answer to your query: the forwarder
destination isn't doing recursion, so your answer will only be one level
On Mon, Jun 2, 2014 at 5:37 PM, Nex6|Bill <n6ghost at yahoo.com> 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>
> 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?
> 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>
> > 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>> 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>
> > https://lists.isc.org/mailman/listinfo/bind-users
> > --
> > John Miller
> > Systems Engineer
> > Brandeis University
> > johnmill at brandeis.edu <mailto:johnmill at brandeis.edu>
johnmill at brandeis.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the bind-users