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 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 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
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
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
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
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 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 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
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 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
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
2011/3/5 Chris Buxton chris.p.bux...@gmail.com: 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 Mar 4, 2011, at 5:42 PM, terry wrote: 2011/3/5 Chris Buxton chris.p.bux...@gmail.com: 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
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
