Question about RFC-2317

[Clenna Lumina]

Mark Andrews wrote:
>> I was reading about RFC-2317
>> (http://www.ietf.org/rfc/rfc2317.txt, found via google... is
>> there a newer one?)
>>
>> While I feel I have grasped a lot about DNS/Bind the past
>> couple months (enough to setup zones for my LAN and started
>> to manage a couple external domains I've since had deligated
>> to me), I can't see understand one part in this RFC document.
>>
>> On page 2 (and 3) it shwos a nice example of how to partition
>> a class C address space into chunks (in that case, starting
>> from 192.0.2.0, /25, /26, and /26
>>
>> I understand that CNAMing in the parent zone is needed,
>> acccording to this RFC.
>>
>> What I can't seem to figure out for the life of me is *why*
>> this is needed?
>
> To map from the well known name where the PTR is expected
> to be to the name in the other zone where the PTR record
> actually will be.


But why? If it's being deligated down to another NS, isn't that where it
would get the PTR records as the query transverses the tree?

In the example from this RFC, wouldn't a query that's asking to look up
an IP in the 0/25 range come to the NS for "2.0.192.in-addr.arpa.", see
"0/25            NS      ns.A.domain.", and just continue over to
ns.A.domain and let it serve up the PTR record?

That is exactly what happens in forward deligations...
lookup foo.com:
   root    (lookup a NS for .com)
   .com    (lookup a NS for foo.com)
   foo.com (lookup a NS, A or CNAME)

Why would reverse be any different? Before I learned of classless
deligation, it seemed to work the same way... ".in-addr.arpa" seemed to
work like any other domain in this regard.

lookup 1.2.3.4
   root  (lookup a NS for 1.in-addr.arpa)
   1     (lookup a NS for 2.1.in-addr.arpa)
   1.2   (lookup a NS for 3.2.1.in-addr.arpa)
   1.2.3 (lookup a NS, PTR, or CNAME)
(or going from 2.1.in-addr.arpa straight to 1.2.3's NS, depending on the
class.)

Assuming I'm remembering correct, wouldn't the classless part just be an
extra jump at the end?

   1.2.3    (lookup a NS for 0/25.3.2.1.in-addr.arpa)
   1.2.3/25 (lookup a NS, PTR, or CNAME)

Or am I missing something, because this is how I'v always understood how
things work, based on the many things I've read?


This is what I really want to understand.

> Most of the DNS based RFC's require that you have read
> and understood the base documents for the DNS
>
> RFC 1033, RFC 1034 and RFC 1035.
>
> Mark

Thanks for the references.


>> (Example parent zone from RFC-2317)
>> ---------------------------------------
>>    $ORIGIN 2.0.192.in-addr.arpa.
>>    @       IN      SOA     my-ns.my.domain.
>> hostmaster.my.domain. (...)
>>    ;...
>>    ;  <<0-127>> /25
>>    0/25            NS      ns.A.domain.
>>    0/25            NS      some.other.name.server.
>>    ;
>>    1               CNAME   1.0/25.2.0.192.in-addr.arpa.
>>    2               CNAME   2.0/25.2.0.192.in-addr.arpa.
>>    3               CNAME   3.0/25.2.0.192.in-addr.arpa.
>>    ;
>>    ;  <<128-191>> /26
>>    128/26          NS      ns.B.domain.
>>    128/26          NS      some.other.name.server.too.
>>    ;
>>    129             CNAME   129.128/26.2.0.192.in-addr.arpa.
>>    130             CNAME   130.128/26.2.0.192.in-addr.arpa.
>>    131             CNAME   131.128/26.2.0.192.in-addr.arpa.
>>    ;
>>    ;  <<192-255>> /26
>>    192/26          NS      ns.C.domain.
>>    192/26          NS      some.other.third.name.server.
>>    ;
>>    193             CNAME   193.192/26.2.0.192.in-addr.arpa.
>>    194             CNAME   194.192/26.2.0.192.in-addr.arpa.
>>    195             CNAME   195.192/26.2.0.192.in-addr.arpa.
>> ---------------------------------------
>>
>> It doesn't seem to make sense with the NS entries pointing to
>> the name servers that those chunks (/lengths) are being
>> deligated to. Wouldn't each respective NS server(s) handle it
>> instead. The CNAME is just an alias, right, so is it needed
>> here? As a fall back messure? Unless I've missed something,
>> the RFC doesn't seem to expalin that.
>> Thanks.