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 <n6gh...@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 <johnm...@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 <johnm...@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 <n6gh...@yahoo.com > > <mailto:n6gh...@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@lists.isc.org <mailto:bind-users@lists.isc.org> > > https://lists.isc.org/mailman/listinfo/bind-users > > > > > > > > > > -- > > John Miller > > Systems Engineer > > Brandeis University > > johnm...@brandeis.edu <mailto:johnm...@brandeis.edu> > > > > > > > > -- John Miller Systems Engineer Brandeis University johnm...@brandeis.edu (781) 736-4619
_______________________________________________ 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