forwarding zone to another DNS server problem

[Joshua Smith]

Kevin,
Thanks for this post.  Its the most succinct description of stub zones
I've ever read.  I've often tried to wrap my head around when to use a
stub and when to use a conditional forwarder and I *think* your
description has cleared that up for me.


On Wed, Nov 05, 2014 at 03:21:00PM +0000, Darcy Kevin (FCA) wrote:
> My attempt to explain "stub"...
> 
> It's like conditional forwarding, without the recursion. You tell named where the top of the namespace tree is hosted, and it issues *iterative* (= non-recursive) queries for names in that part of the tree. (Unless, of course, you have a definition further down in that namespace that overrides the behavior).
> 
> As someone else pointed out, this raises the requirement that you have *direct* connectivity to the published authoritative nameservers for the top level of the zone, and any other descendant zones (unless, again, you override those parts of the namespace tree with some other definition). In a DMZ environment, you may not have open and clear communication to *everything* that you need, and therefore "stub" might not be a good fit in that case. You might be forced, as a last resort, to use forwarding, in such a scenario.
> 
> Beyond that understanding, there are differences in how named *gets* the apex-NS information for a "stub" zone. The "classic" stub model is to use a similar replication method as slaving, i.e. driven by the REFRESH/RETRY/EXPIRE settings in the SOA of the zone. This will generate periodic refresh traffic in the form of SOA and/or NS queries. With the newer "static-stub" model (which, full disclosure, I've never actually *used*), apparently you just plug the addresses of the auth servers directly into the config, and no "refreshing" is necessary. There are pros and cons, that come to mind, for each of those flavors of "stub".
> 
> 												- Kevin
> 
> -----Original Message-----
> From: bind-users-bounces at lists.isc.org [mailto:bind-users-bounces at lists.isc.org] On Behalf Of Tony Finch
> Sent: Tuesday, November 04, 2014 5:10 AM
> To: houguanghua
> Cc: bind-users at lists.isc.org
> Subject: RE: forwarding zone to another DNS server problem
> 
> houguanghua <houguanghua at hotmail.com> wrote:
> 
> >  I 'm not familiar with'stub'.  The description of 'stub' is hard to 
> > understand.
> 
> Yes it's a bit weird. Think of it like the root hints but for other zones:
> i.e. a hint zone configuration in a recursive server tells named that instead of using a referral from the parent zone to find the name servers for this zone, use these configured name servers. However the name servers at the zone's apex can override your configuration.
> 
> If you use static-stub instead, your configured name servers override all name servers for the zone that your name server might receive.
> 
> The difference with forwarding zones occurs if there is a delegation point below the zone you have configured. With a fowarding zone, named expects the target name server to do recursion, so the target server will deal with following the referral and resolving the final answer. With a stub zone, named expects to get authoritative answers and referrals to child zones, and it will do its own recursion to resolve the final answer.
> 
> Tony.
> --
> f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/ Viking, North North Utsire: Cyclonic, becoming northeasterly 6 to gale 8, occasionally severe gale 9. Moderate or rough, becoming rough or very rough.
> Rain or showers. Good, occasionally poor.
> _______________________________________________
> 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
> _______________________________________________
> 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

-- 
Joshua Smith
Lead Systems Administrator WVNET
(304)293-5192 x247