Zone Delegation

[David Botham]

[clip...]
Once again, Kevin steps out of the box and offers up some of the most 
useful comments on the subject to date... :)

Dave...
> One might also consider a stub zone, i.e.
> 
> zone "168.192.in-addr.arpa" {
>     type stub;
>     file "168.192.in-addr.arpa";
>     masters {
>             172.16.0.5;
>             172.16.0.6;
>     };
>     forwarders { };
> };
> 
> which, on the negative side, relies on legitimate NS records being 
presen=
> t in the zone, but on the positive side, is likely to perform better 
than=
>  forwarding, especially in failure scenarios.
> 
> The "forwarders { }" is to cancel forwarding for any subzones.
> 
> Another option is to be a slave (assuming the masters allow zone 
transfer=
> s):
> 
> zone "168.192.in-addr.arpa" {
>     type slave;
>     file "168.192.in-addr.arpa";
>     masters {
>             172.16.0.5;
>             172.16.0.6;
>     };
>     forwarders { };
> };
> 
> For subzones, this too will require legitimate NS records. But you 
can't=20
> beat the performance of an authoritative zone. The price to be paid,=20
> however, is the serial-checking and zone-transfer overhead.
> 
> =20
>                            - Kevin
> 
> 
>