Re: BIND's Implementation of Zones/"Subzones" - DNS

This is a discussion on Re: BIND's Implementation of Zones/"Subzones" - DNS ; 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 ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Re: BIND's Implementation of Zones/"Subzones"

  1. Re: BIND's Implementation of Zones/"Subzones"

    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




  2. Re: BIND's Implementation of Zones/"Subzones"

    On Aug 22, 8:27*am, Alan Clegg 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


  3. Re: BIND's Implementation of Zones/"Subzones"

    In article , Eric
    wrote:

    > On Aug 22, 8:27 am, Alan Clegg 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?


    No, its nearest ancestor is aaa.example.com, i.e. the zone with the same
    name as the domain.

    If you fixate on the regular English definition of "ancestor", which
    doesn't include the null case where you're your own ancestor, then how
    would you find ANY of the records attached to the zone name (e.g. the
    SOA record), which are normally only defined in the zone itself? So
    even though I don't think the RFC ever says it explicitly, I think it's
    obvious that the null-ancestor case is included.

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE don't copy me on replies, I'll read them in the group ***


  4. Re: BIND's Implementation of Zones/"Subzones"

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




+ Reply to Thread