RE: forwarding zone to another DNS server problem
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-boun...@lists.isc.org [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Tony Finch Sent: Tuesday, November 04, 2014 5:10 AM To: houguanghua Cc: bind-users@lists.isc.org Subject: RE: forwarding zone to another DNS server problem houguanghua 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.finchhttp://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@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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: forwarding zone to another DNS server problem
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 +, 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-boun...@lists.isc.org > [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Tony Finch > Sent: Tuesday, November 04, 2014 5:10 AM > To: houguanghua > Cc: bind-users@lists.isc.org > Subject: RE: forwarding zone to another DNS server problem > > houguanghua 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.finchhttp://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@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@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Joshua Smith Lead Systems Administrator WVNET (304)293-5192 x247 ___ 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
Replacing certain records in a zone
Hi Guys, I have a requirement to replace certain records in a zone, as e.g: To the public I want www.domain.com and mail.domain.com to resolve to 1.2.3.4 (Do note that I am not the SOA for domain.com) To my development environment I would like www.domain.com to resolve to 5.6.7.8, but I still want to be able to resolve mail.domain.com to 1.2.3.4. I have a DNS server in place at the development environment that I can control. I could have sworn that bind has an option to do this, I just can't recall where/how/what. Thanks, Pieter ___ 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
Re: Replacing certain records in a zone
In message <545a96b6.3020...@insync.za.net>, Pieter De Wit writes: > Hi Guys, > > I have a requirement to replace certain records in a zone, as e.g: > > To the public I want www.domain.com and mail.domain.com to resolve to > 1.2.3.4 (Do note that I am not the SOA for domain.com) > To my development environment I would like www.domain.com to resolve to > 5.6.7.8, but I still want to be able to resolve mail.domain.com to 1.2.3.4. > > I have a DNS server in place at the development environment that I can > control. > > I could have sworn that bind has an option to do this, I just can't > recall where/how/what. Add a "www.domain.com" zone to your local server. > Thanks, > > Pieter > ___ > 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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
Re: Replacing certain records in a zone
Add a "www.domain.com" zone to your local server. OMG - YES! Thanks ! ___ 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
