NS record for subzone definition

hugo hugoo hugobxl at hotmail.com
Tue Mar 13 16:33:13 UTC 2012

Thanks for this interesting feedback.
Now I have the problem to detect this kind of bad configuration.
If I have:
Zone toto.be:
        NS  ns1.xxx.be
        + some records
Zone titi.toto.be:
         NS   ns1.xxx.be
          + some records.
What will be the command to detect that zone toto.be has no NS for titi.toto.be ??


> Date: Tue, 13 Mar 2012 15:03:38 +0000
> From: cet1 at cam.ac.uk
> To: hugobxl at hotmail.com
> CC: ben.croswell at gmail.com; bind-users at lists.isc.org
> Subject: Re: NS record for subzone definition
> On Mar 13 2012, hugo hugoo wrote:
> >Thanks for this clear feedback.
> >
> >I understand the problem if the subdomain is not on the same name servers
> >as the domain. The NS record is needed to could find the subdomain on the
> >other name server.
> > 
> >You said that the NS is not mandatory (it will work fine in the short term)
> >in case of the same name server for the domai nand the subdomain. But how
> >does it work then if no NS is found?
> When asked about "tutu.titi.toto.be", the "be" nameservers give a referral
> to the nameservers for "toto.be". When *they* are asked, if they are already
> authoritative for the zone "titi.toto.be", they can answer the question
> without giving another referral.
> But as has been pointed out, such a configuration is horribly fragile. The
> set of nameservers (official *and* unofficial) for the zones have to be
> the same, and it won't work anyway if the zones are signed, and so on.
> One question to ask is: if the set of nameservers for "toto.be" and
> "titi.toto.be" are now and for evermore going to be the same, why would
> you want to make them separate zones at all? A single zone can have
> domain names nested as deep as you like[*] without you needing to make
> a zone cut.
> [*] subject to the overall limit of 253 characters on the fully
> qualified name
> -- 
> Chris Thompson
> Email: cet1 at cam.ac.uk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20120313/4c920a82/attachment.html>

More information about the bind-users mailing list