Question about RFC-2317
Mark Andrews
Mark_Andrews at isc.org
Fri Jan 5 02:07:41 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?
Yes it is a alias which says the answer you want is not here,
it is over there. Over there can be ANYWHERE. It does not
have to be in 0/25.2.0.192.in-addr.arpa.
The DNS is just a database. It is only by convention that
IN-ADDR.ARPA means something special. IPv6 used both IP6.INT
and IP6.ARPA for reverse lookup. One convention was used
(IP6.INT) then politics intervened and a second convention
was choosen (IP6.ARPA). The DNS servers knew nothing about
the changes in convention. They just served the data that
they had loaded.
> Also, this article
> http://groups.google.com/group/comp.protocols.dns.bind/browse_frm/thread/9cd3
> f887a7ea67e1/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.
The client ask the recursive server for 1.2.0.192.IN-ADDR.ARPA
The recursive server asks the authoriative servers for
2.0.192.IN-ADDR.ARPA for PTR record at 1.2.0.192.IN-ADDR.ARPA.
The authoritative server returns the CNAME
1.2.0.192.IN-ADDR.ARPA CNAME 1.0/25.2.0.192.IN-ADDR.ARPA
and also returns in the same message a referral to
0/25.2.0.192.IN-ADDR.ARPA. The recursive server server
then asks the servers for 0/25.2.0.192.IN-ADDR.ARPA for the
PTR record for 1.0/25.2.0.192.IN-ADDR.ARPA and get back a
answer. It then combines the CNAME and the answer it got
back from the 0/25.2.0.192.IN-ADDR.ARPA servers and send
that back to the client.
Now if the authorative servers for 2.0.192.IN-ADDR.ARPA
also serve 0/25.2.0.192.IN-ADDR.ARPA they send back both
the CNAME and the PTR record or CNAME and NXDOMAIN response
depending apon whether there was a PTR record or not.
This is no different that if there was a CNAME for
www.example.net which pointed to www.example.com.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org
More information about the bind-users
mailing list