BIND's Implementation of Zones/"Subzones"

[Mark Andrews]

> On Aug 22, 8:27 am, Alan Clegg <Alan_Cl... at isc.org> wrote:
> > Eric wrote:
> > > aaa.example.com.    NS  ns2.example.com
> >
> > > If I place that record in /etc/bind/db.example.com on ns1.example.com,
> > > ns1.example.com will not return the NS record for ns2.example.com as a
> > > result when queried.
> >
> > Can you give an example of exactly what you did to show this?
> >
> > Did you try "dig @ns1.example.com +norec aaa.example.com ns"?  If so,
> > what were the results?
> >
> > What NS records do you have in the aaa.example.com zone?  Do they match
> > what you have in the parent?
> >
> > AlanC
> 
> My claim is that the "dig @ns1.example.com +norec aaa.example.com ns"
> query will not return ns2.example.com if I have added the
> ns2.example.com NS record to only the db.example.com file (and not to
> db.aaa.example.com).  I have tested that and found it to be true.

	It's also correct behaviour.
 
> This excerpt from section 4.3.2 of RFC-1034 explains why I think this
> functionality is wrong:
> 
>    2. Search the available zones for the zone which is the nearest
>       ancestor to QNAME.  If such a zone is found, go to step 3,
>       otherwise step 4.
> 
>    3. Start matching down, label by label, in the zone.  The
>       matching process can terminate several ways:
> 
>          a. If the whole of QNAME is matched, we have found the
>             node.
> 
> So, assuming that the QNAME of the NS query is "aaa.example.com",
> isn't example.com its nearest ancestor?

	No.  The nearest ancestor includes a perfect match.

	Run through the algorithm with QTYPE = SOA.  You will see
	that it can only work when nearest ancestor includes a
	perfect match.

> And shouldn't we therefore
> find the ns2.example.com entry in the db.example.com zone file?

	No.  Step 2 says to use "aaa.example.com".
 
> After reviewing Mark's reply, I think the answer is something like
> "well, you shouldn't be placing inconsistent records in the zone files
> to begin with".  

	If you manage both zones then, yes, you failed to keep the
	zones consistent.

	NS RRsets are supposed to start out identical.  Whenever
	the child zone is changed the parent zone is also supposed
	to be changed to reflect the change in the child zone.
	While these changes propogate to the authoritative servers
	for the zones there will be differences visible.

> If BIND is making the assumption (per RFC 1034) that
> all aaa.example.com NS records will be identical between the
> db.example.com and db.aaa.example.com zone files, then it is perfectly
> legitimate to consult one, and only one, of the zone files (BIND
> happens to choose the child).
>
> However, I do think that the RFC is a little unclear as to whether the
> NS recordset needs to be "identical" between parent and child zones.

	You are supposed to *copy* the records into the parent zone.
	Yes they are supposed to be identical.  Failure to keep
	them identical can lead to resolution failures as part of
	the process of keeping them identical is keeping the glue
	records identical as well.

> I do gather (in the context of the example) that:
> 1. All aaa.example.com NS records in db.aaa.example.com should be in
> db.example.com.
> 2. The aaa.example.com NS records should be "consistent" between
> db.aaa.example.com and db.example.com.
> 
> My problem is that "consistent" does not necessarily entail
> "identical".  I can imagine having aaa.example.com NS records in
> db.example.com and NOT in db.aaa.example.com and maintaining
> consistency.  (Consistency in the sense that if a parent specifies an
> additional name server for a subzone, that act does not negate any of
> the child's NS specifications.)  And now for my next trick, I will
> divide by zero.
> 
> Thanks for the replies!
> 
> -Eric
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org