RE: Slaves and views
>> With a static-stub zone (new in BIND 9.8), your server would not prime its >> cache with the bad NS >> rrset from the authoritative server. It would simply start all query >> resolution for the domain in >> question (possibly bigger than the zone) at that server, thus bypassing the >> bad NS rrset. >Then, what is the different between "static-stub" and "a forwarding zone"? My understanding .. I am sure there are others here who can speak more authoritatively or with more correct terminology, but: A forwarder simply forwards all queries to the indicated servers, and expects an answer back. A stub will tell the resolver "for any zones matching this one, use these nameservers". The resolver will use them like normal NS records, not expecting them to give an answer necessarily (could simply give back a referral). Basically, it's short cutting the delegation process, but that's it, the server still has to do all the work. Cheers, Todd. - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Slaves and views
> > Chris, > > > > What's the difference between a stub zone and a static-stub zone? > > I have been thinking they are the same. > > With a stub zone, your server would ask the server with bad NS records for the NS record set, and > would then try to resolve all queries against the zone using that NS rrset. > > With a static-stub zone (new in BIND 9.8), your server would not prime its cache with the bad NS > rrset from the authoritative server. It would simply start all query resolution for the domain in > question (possibly bigger than the zone) at that server, thus bypassing the bad NS rrset. Then, what is the different between "static-stub" and "a forwarding zone" ? Kind regards, Marc ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Slaves and views
On Fri, Mar 04, 2011 at 11:40:54PM -0800, Chris Buxton wrote: ... > A static-stub zone involves an iterative query, the potential for a referral, > and then potentially recursion to follow the referral. > > Conditional forwarding (a zone of type forward) involves a recursive query. > If the answer is not forthcoming and 'forward only;' is set, the result is a > SERVFAIL back to the client. There is no possibility that the DNS server so > configured will follow referrals. > ... Excellent, thanks. I had not gotten this from the earlier description. -- /*\ ** ** Joe Yao j...@tux.org - Joseph S. D. Yao ** \*/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Slaves and views
On Fri, Mar 04, 2011 at 06:55:07PM -0800, Chris Buxton wrote: ... > > With a static-stub zone (new in BIND 9.8), your server would not prime its > cache with the bad NS rrset from the authoritative server. It would simply > start all query resolution for the domain in question (possibly bigger than > the zone) at that server, thus bypassing the bad NS rrset. > ... With this description, I have to ask, how does it then differ from a forward-only domain? -- /*\ ** ** Joe Yao j...@tux.org - Joseph S. D. Yao ** \*/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Slaves and views
On Mar 4, 2011, at 11:34 PM, Joseph S D Yao wrote: > On Fri, Mar 04, 2011 at 06:55:07PM -0800, Chris Buxton wrote: > ... >> >> With a static-stub zone (new in BIND 9.8), your server would not prime its >> cache with the bad NS rrset from the authoritative server. It would simply >> start all query resolution for the domain in question (possibly bigger than >> the zone) at that server, thus bypassing the bad NS rrset. >> > ... > > > With this description, I have to ask, how does it then differ from a > forward-only domain? A static-stub zone involves an iterative query, the potential for a referral, and then potentially recursion to follow the referral. Conditional forwarding (a zone of type forward) involves a recursive query. If the answer is not forthcoming and 'forward only;' is set, the result is a SERVFAIL back to the client. There is no possibility that the DNS server so configured will follow referrals. Chris Buxton BlueCat Networks ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Slaves and views
On Mar 4, 2011, at 5:42 PM, terry wrote: > 2011/3/5 Chris Buxton : >> >> On Mar 4, 2011, at 8:46 AM, John Wobus wrote: >> >>> Hi, >>> >>> Can a zone file a slave in one view and the same zone file >>> be served by another view? >> >> You can do this for static master zones, but it's not a good idea for slaves. >> >> Depending on the use case for your internal view, you may be able to solve >> this better using forwarding, stub zones, or (BIND 9.8 only) static-stub >> zones. > > > Chris, > > What's the difference between a stub zone and a static-stub zone? > I have been thinking they are the same. With a stub zone, your server would ask the server with bad NS records for the NS record set, and would then try to resolve all queries against the zone using that NS rrset. With a static-stub zone (new in BIND 9.8), your server would not prime its cache with the bad NS rrset from the authoritative server. It would simply start all query resolution for the domain in question (possibly bigger than the zone) at that server, thus bypassing the bad NS rrset. Regards, Chris Buxton BlueCat Networks ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Slaves and views
2011/3/5 Chris Buxton : > > On Mar 4, 2011, at 8:46 AM, John Wobus wrote: > >> Hi, >> >> Can a zone file a slave in one view and the same zone file >> be served by another view? > > You can do this for static master zones, but it's not a good idea for slaves. > > Depending on the use case for your internal view, you may be able to solve > this better using forwarding, stub zones, or (BIND 9.8 only) static-stub > zones. Chris, What's the difference between a stub zone and a static-stub zone? I have been thinking they are the same. Thanks. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Slaves and views
On Sat, Mar 05, 2011 at 09:36:56AM +1100, Mark Andrews wrote: ... > masters { 127.0.0.1 key external.key; }; ... Hmmm! You can do that, can't you? I tend to try to keep one key to one IP address in a view - people get confused even so. As I said, this still does two zone transfers, because sourcing the zone and serving it are not separate abstractions. -- /*\ ** ** Joe Yao j...@tux.org - Joseph S. D. Yao ** \*/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Slaves and views
On Fri, Mar 04, 2011 at 11:46:05AM -0500, John Wobus wrote: ... > Can a zone file a slave in one view and the same zone file > be served by another view? ... I assume you mean something like this: view "here" { match-clients { "here"; }; zone "example.us" { type slave; file "data/zone.example.us"; masters { 20.20.20.20; 30.30.30.30; }; }; }; view "rest" { match-clients { any; }; zone "example.us" { type master; file "data/zone.example.us"; } }; I've tried this - unsuccessfully. The basic problem is, if you declare both "slaves", then the second view tries to update it around the same time as the first, and the file gets munged. If you declare one "slave" and the other "master", how does the "slave" view let the "master" view know when the zone is updated? Nothing like serving stale data! view "here" { match-clients { "here"; }; zone "example.us" { type slave; file "data/here/zone.example.us"; masters { 20.20.20.20; 30.30.30.30; }; }; }; view "rest" { match-clients { any; }; zone "example.us" { type slave; file "data/rest/zone.example.us"; masters { 20.20.20.20; 30.30.30.30; }; } }; The above does two zone transfers, which is a waste [but not a big one, one hopes!]. But I couldn't figure out any syntax - without using the extra IP addresses that you also wish to avoid - for doing this. Using extra IP addresses, of course, each view listens on a different IP address, the second view slaves its copy from the slaved copy on the first, and the first view NOTIFYes the second when it transfers the master copy "out there" to its slaved copy. Still two zone transfers, but one is internal. To do what you want, one would have to separately abstract the zone transfer mechanism and the serving mechanism. Which would not be a bad idea at all: // NOTE: the following is ramblings of my feverish mind and not anything // supported by any existing parser or other software view "here" { match-clients { "here"; }; allow-query { "here"; }; }; view "rest" { match-clients { any; }; }; zone "static.us" { // sourced once // served by all views type master; file "data/zone.static.us"; } zone "example.us" // sourced once // served by all views type slave; file "slaved/zone.example.us"; masters { 20.20.20.20; 30.30.30.30; }; // if it were served differently in another view // or sourced differently in a third view // we would have that info in a 'view' statement. } zone "split.us" { // sourced and served differently in two views view "here" { match-clients { !ext-tsig-key; int-tsig-key; "here"; }; allow-transfer { int-tsig-key; }; type slave; file "slaved/here/zone.example.us"; masters { 10.10.10.10; 10.20.30.40; }; } view "rest" { match-clients { !int-tsig-key; ext-tsig-key; any; }; allow-transfer { ext-tsig-key; }; type slave; file "slaved/rest/zone.example.us"; masters { 20.20.20.20; 30.30.30.30; }; } } zone "internal.us" { // sourced and served only in one view view "here" { type master; file "data/internal.us"; } } -- /*\ ** ** Joe Yao j...@tux.org - Joseph S. D. Yao ** \*/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Slaves and views
In message <79391b3d-6106-420b-9056-717a5e5fa...@cornell.edu>, John Wobus write s: > Hi, > > Can a zone file a slave in one view and the same zone file > be served by another view? > > I'm going to split our authoritative servers into internal > and external views. My question concerns zones that we > secondary for other organizations, slaved to masters at > their sites. > > I know I could configure each of their zones with separate files > in each the two views, listen/use an additional address that > accesses our local view, and tell these peer organizations to > notify and allow transfers from this additional address. > I'm not (yet) worried about dynamic updates, if there are > any. > > Is there a way I can handle their zones without making > these other sites configure another address, and I still > run just one bind instance? > > Other ideas are: running a separate bind instance for > these zones, or making one view a slave to the other. > Possibly forwarding of some kind, another thing I haven't > done much. > > John Wobus > Cornell Any file named writes, slave, dynamic master, should not be shared. That said you don't need to change how zone are transfered between you and the master. You can just transfer them internally from one view to the other. key "external.key" { }; acl internal-clients { ... 127.0.0.1; }; view "internal" { match-clients { !key external.key; internal-clients; }; zone "example" { type slave; file "slave/internal/example"; masters { 127.0.0.1 key external.key; }; }; }; view "external" { match-clients { key external.key; any; }; zone "example" { type slave; file "slave/external/example"; masters { }; allow-transfer { external.key; }; also-notify { 127.0.0.1; }; }; }; > ___ > 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 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Slaves and views
On 04.03.11 11:46, John Wobus wrote: > Can a zone file a slave in one view and the same zone file > be served by another view? in fact, yes. but it apparently won't work as you'd expect. > I'm going to split our authoritative servers into internal > and external views. My question concerns zones that we > secondary for other organizations, slaved to masters at > their sites. why? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. If Barbie is so popular, why do you have to buy her friends? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Slaves and views
On Mar 4, 2011, at 8:46 AM, John Wobus wrote: > Hi, > > Can a zone file a slave in one view and the same zone file > be served by another view? You can do this for static master zones, but it's not a good idea for slaves. Depending on the use case for your internal view, you may be able to solve this better using forwarding, stub zones, or (BIND 9.8 only) static-stub zones. This would require that your internal view only get recursive queries, however. Chris Buxton BlueCat Networks ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Slaves and views
On Fri, 2011-03-04 at 11:46 -0500, John Wobus wrote: > Hi, > > Can a zone file a slave in one view and the same zone file > be served by another view? It is a bad idea, although I know (from experience) it will work for static zones. One problem is you need to remember to reload the zone in both views if you make any changes to it. Again, it is a bad idea and I think ISC recommends against it. > I'm not (yet) worried about dynamic updates, if there are > any. That will not work. You will need separate files for each view. Steve. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Slaves and views
On 3/4/2011 11:46 AM, John Wobus wrote: > I'm going to split our authoritative servers into internal > and external views. Is there anything I can do to try to talk you out of doing this? AlanC signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Slaves and views
Haven't done it but don't see why not. Since every entry in named.conf specifies the zone file you can definitely have multiple zones all pointing to the same zone file. (We do that for many ancillary zones that we want to point to our primary domain so have an aliases file that uses the @ designation instead of hard coded domain names.) -Original Message- From: bind-users-bounces+jlightner=water@lists.isc.org [mailto:bind-users-bounces+jlightner=water@lists.isc.org] On Behalf Of John Wobus Sent: Friday, March 04, 2011 11:46 AM To: bind-users Subject: Slaves and views Hi, Can a zone file a slave in one view and the same zone file be served by another view? I'm going to split our authoritative servers into internal and external views. My question concerns zones that we secondary for other organizations, slaved to masters at their sites. I know I could configure each of their zones with separate files in each the two views, listen/use an additional address that accesses our local view, and tell these peer organizations to notify and allow transfers from this additional address. I'm not (yet) worried about dynamic updates, if there are any. Is there a way I can handle their zones without making these other sites configure another address, and I still run just one bind instance? Other ideas are: running a separate bind instance for these zones, or making one view a slave to the other. Possibly forwarding of some kind, another thing I haven't done much. John Wobus Cornell ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users Proud partner. Susan G. Komen for the Cure. Please consider our environment before printing this e-mail or attachments. -- CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you. -- ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users