Zone Delegation

[Kevin Darcy]

H=E5kan Lindholm wrote:

>bind-users-bounce at isc.org wrote on Wednesday, February 04, 2004 10:14 =3D
>PM:
>
> =20
>
>>Accept all requests
>>   =20
>>
>
>Default behaviour, right?
>
>
> =20
>
>>If the lookup is for a domain it is master for, lookup and return to
>>client.
>>   =20
>>
>
>Default.
>
>
> =20
>
>>If the lookup is for abc.com, ask this other server over our
>>Intranet and return to client.
>>   =20
>>
>
>Use zone type "forward", like this:
>
>zone "168.192.in-addr.arpa" {
>	type forward;
>	forwarders {
>		172.16.0.5;
>		172.16.0.6;
>	};
>};
> =20
>
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