Question about RFC-2317
Clenna Lumina
savagebeaste at yahoo.com
Thu Jan 4 20:42:06 UTC 2007
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.
More information about the bind-users
mailing list