BIND's Implementation of Zones/"Subzones"

[Eric]

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.

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?  And shouldn't we therefore
find the ns2.example.com entry in the db.example.com zone file?

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 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.
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