Question about RFC-2317

Clenna Lumina savagebeaste at yahoo.com
Fri Jan 5 01:08:14 UTC 2007


Mark Andrews wrote:
>> Edward Lewis wrote:
>>> At 9:19 -0800 1/4/07, Clenna Lumina wrote:
>>>> But why?
>>>
>>> Because DNS can only delegate every 8 bits, IP can delegate on any
>>> bit length.
>>>
>>> Let's say you are an ISP and have a /22 allocated to you by an RIR.
>>> A /22 consists of 4 /24's.  10.12.52.0 to 10.12.55.255 is the range
>>> (equivalent to 10.12.52/22).
>>>
>>> Your first customer gets 256 addresses - 10.12.52.0/24 - and wants
>>> to do DNS. The second customer gets 128 addresses - 10.12.53.0/25 -
>>> ditto The third customer gets 128 addresses  - 10.12.53.128/25 -
>>> ditto
>>>
>>> The first customer wants to use ns1.example. and ns2.example.
>>> The second customer wants to use ns1.foo.bar. and ns2.foo.bar.
>>> The third customer wants to use dns0.xn--55qx5d.cn. and
>>> dns1.xn--55qx5d.cn.
>>>
>>> How do you break up the second /24?
>>>
>>> You have "ns0.mycompany.net." and "ns1.mycompany.net."  What does
>>> the zone look like?  Well, you have four...
>>>
>>> 52.12.10.in-addr.arpa --> for this you run nothing, you have the RIR
>>> delegate the zone to the first customer, meaning that
>>> 12.10.in-addr.arpa. has this:
>>>
>>> $ORIGIN 12.10.in-addr.arpa.
>>> 52      NS ns1.example.
>>>         NS ns2.example.
>>> 53      NS ns0.mycompany.net.
>>>         NS ns1.mycompany.net.
>>> 54      NS ns0.mycompany.net.
>>>         NS ns1.mycompany.net.
>>> 55      NS ns0.mycompany.net.
>>>         NS ns1.mycompany.net.
>>>
>>> For your second and third customers, you would have to use RFC 2317
>>> to split the range to two different server sets.
>>>
>>> $ORIGIN 53.12.10.in-addr.arpa.
>>> @       SOA
>>>         NS ns0.mycompany.net.
>>>         NS ns1.mycompany.net.
>>>
>>> $GENERATE    0-127 $ CNAME $.customer2.53.12.10.in-addr.arpa.
>>> $GENERATE  128-255 $ CNAME $.customer3.53.12.10.in-addr.arpa.
>>>
>>> customer2.53.12.10.in-addr.arpa. NS ns1.foo.bar.
>>> customer2.53.12.10.in-addr.arpa. NS ns2.foo.bar.
>>> customer3.53.12.10.in-addr.arpa. NS dns0.xn--55qx5d.cn.
>>> customer3.53.12.10.in-addr.arpa. NS dns1.xn--55qx5d.cn.
>>>
>>> ----end of the zone file----
>>>
>>> When a query for "100.53.12.10.in-addr.arpa PTR comes to your
>>> server, you will answer with
>>>
>>> 100.53.12.10.in-addr.arpa CNAME 100.customer2.53.12.10.in-addr.arpa.
>>> and
>>> customer2.53.12.10.in-addr.arpa. NS ns1.foo.bar.
>>> customer2.53.12.10.in-addr.arpa. NS ns2.foo.bar.
>>>
>>> At this point, the customer can put whatever entries they want in
>>> the reverse map, they are independent of you for this.
>>>
>>> If you didn't do this, then you'd have to blow an entire /24 on each
>>> customer that wanted to do DNS or you would have to manage the DNS
>>> for them.
>>
>> I still don't see why that is.
>>
>> Take again the example from RFC-2317, parent zone:
>>
>> -----------------------------------------------------------------------
>>    $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.
>> -----------------------------------------------------------------------
>>
>> What I want to know is why it can't just be written as:
>> -----------------------------------------------------------------------
>>    $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.
>>    ;
>>    ;  <<128-191>> /26
>>    128/26          NS      ns.B.domain.
>>    128/26          NS      some.other.name.server.too.
>>    ;
>>    ;  <<192-255>> /26
>>    192/26          NS      ns.C.domain.
>>    192/26          NS      some.other.third.name.server.
>>    ;
>> -----------------------------------------------------------------------
>>
>> I mean from how I understand how deligation otherwise works, when a
>> request comes down the line for, say, 192.0.2.34, wouldn't it just
>> see the NS record for 0/25 (which is authoritive for IPs 0-127) and
>> move on there to complete the query?
>>
>> In normal cases this is how it seems to work. Why would this be any
>> different? If the PTRs are on another server, it seems somewhat
>> redundant and uneeded to CNAME thme in the parent zone, when they
>> are in another zone which is athorative.
>
> Because the clients look up 1.2.0.192.IN-ADDR.ARPA not
> 1.0/25.2.0.192.IN-ADDR.ARPA when that want to find the name
> of the machine at 192.0.2.1.  Without the CNAME they would
> get a NXDOMAIN response as there are no records at
> 1.2.0.192.IN-ADDR.ARPA.

Then how does the request make it's way to "ns.A.domain", for example ? 
If what you say is true, then wouldn't the "0/25" in "0/25            NS 
ns.A.domain." be pointless. Also, how would it any different that "1 
CNAME   1.0/25.2.0.192.in-addr.arpa.", which uses the same syntax?

The NS record is what opens the door to the PTR records on "ns.A.domain" 
(in that example), doesn't it? I mean how else does it *GET* there if 
not for that NS record? The CNAME doesn't provide such a route, it's 
just an alias, is it not?

Also, this article
http://groups.google.com/group/comp.protocols.dns.bind/browse_frm/thread/9cd3f887a7ea67e1/d580f929b63f1d45?lnk=st&q=&rnum=1&hl=en#d580f929b63f1d45

mentions that is *is* in fact possible. So All I'm asking is a clear 
explantion what what I may be missing. I REALLY want to understand this.

Thanks. 




More information about the bind-users mailing list