Zone Delegation
J, C
twinked at seajay.com
Thu Feb 5 14:57:28 UTC 2004
Yes...i must agree with you Dave...
C
-----Original Message-----
From: bind-users-bounce at isc.org [mailto:bind-users-bounce at isc.org] On
Behalf Of David Botham
Sent: Wednesday, February 04, 2004 5:24 PM
To: bind-users at isc.org
Subject: Re: Zone Delegation
[clip...]
Once again, Kevin steps out of the box and offers up some of the most=20
useful comments on the subject to date... :)
Dave...
> One might also consider a stub zone, i.e.
>=20
> zone "168.192.in-addr.arpa" {
> type stub;
> file "168.192.in-addr.arpa";
> masters {
> 172.16.0.5;
> 172.16.0.6;
> };
> forwarders { };
> };
>=20
> which, on the negative side, relies on legitimate NS records being=20
presen=3D
> t in the zone, but on the positive side, is likely to perform better=20
than=3D
> forwarding, especially in failure scenarios.
>=20
> The "forwarders { }" is to cancel forwarding for any subzones.
>=20
> Another option is to be a slave (assuming the masters allow zone=20
transfer=3D
> s):
>=20
> zone "168.192.in-addr.arpa" {
> type slave;
> file "168.192.in-addr.arpa";
> masters {
> 172.16.0.5;
> 172.16.0.6;
> };
> forwarders { };
> };
>=20
> For subzones, this too will require legitimate NS records. But you=20
can't=3D20
> beat the performance of an authoritative zone. The price to be
paid,=3D20
> however, is the serial-checking and zone-transfer overhead.
>=20
> =3D20
> - Kevin
>=20
>=20
>=20
More information about the bind-users
mailing list