BIND's Implementation of Zones/"Subzones"

[Kevin Darcy]

You're reading too much into "nearest ancestor". If the QNAME matches a 
zone for which the server is authoritative, it'll answer from the apex 
of that zone, not some other "ancestor" zone. If there were a word in 
the English language that concisely expresses "yourself, if applicable, 
or if not applicable, the nearest ancestor to yourself", then I'm sure 
the RFC would have used it. But any such wording would have been 
cumbersome for casual readers to comprehend. Mathematical notation can 
make that a lot clearer, but folks don't want to see a lot of 
mathematical goop in their RFCs.

The data ranking rules in RFC 2181 (see Section 5.4.1) are quite 
explicit, and data directly from an authoritative zone ranks above glue 
information that would only be given in (non-authoritative) referral 
responses.

Why would BIND respond with _lower-ranking_ data when it has 
higher-ranking data available? Think in practical terms.

                                                                         
                                 - Kevin

Eric wrote:
> 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
>
>
>
>