stub zones

[John Miller]

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
deep.

John


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>
> 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>
> 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>> 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>
>
> >
> >
>
>
>


-- 
John Miller
Systems Engineer
Brandeis University
johnmill at brandeis.edu
(781) 736-4619
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20140602/676ed84d/attachment.html>