NS records in parent

Barry Margolin barmar at bbnplanet.com
Wed Aug 25 14:36:02 UTC 1999


In article <199908242123.HAA05311 at bsdi.dv.isc.org>,
 <Mark_Andrews at isc.org> wrote:
>
>> 
>> David Mitchell <davem at fdgroup.co.uk> wrote in message
>> news:<199908241540.QAA21951 at tiree.fdgroup.co.uk>...
>> > If the server for a parent zone is also slave for a child zone,
>> > is it still necessary for the parent server to explicity list the
>> > name servers of the child zone in the zone file of the parent?
>> 
>> It's actually not necessary, assuming that the server that's slave for the
>> child zone is the primary master for the parent zone.  The NS records from
>> the child zone will be automatically "promoted" into delegation information
>> in the parent zone.
>> 
>> Still, it's good practice to duplicate the NS RRs in the parent zone,
>> especially if there's any chance of reconfiguring the name server so that
>> it's no longer a slave for the child zone, or of moving the primary master
>> for the parent zone to another name server.
>> 
>
>	Also BIND 9 will *not* automatically promote NS records in AXFR /
>	IXFR responses.
>
>	You should add them in BOTH places and maintain them in BOTH places.

Also also: Consider what happens to the slave servers of the parent zone if
the nameservers for the child zone are changed.  If they're only changed in
the child zone file, the master server of the parent zone will learn this
when it transfers the child zone.  However, the serial number of the parent
zone will not increment when this happens, so the slave servers of the
parent zone will not transfer that zone.  As a result, they'll continue to
give out the old NS records until some change is made explicitly to the
parent zone, which will force them to do a new transfer.

-- 
Barry Margolin, barmar at bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.


More information about the bind-users mailing list