Question about RFC-2317
Clenna Lumina
savagebeaste at yahoo.com
Fri Jan 5 00:12:21 UTC 2007
--- Ben Bridges <ben at springnet.net> wrote:
> That's *not* the way delegation works, even in "normal"
> cases (meaning
> non-IN-ADDR.ARPA zones). What you are saying would be
> roughly equivalent to
> having the following zone defined on my-ns.my.domain:
>
> $ORIGIN foo.bar.
> @ IN SOA my-ns.my.domain.
> hostmaster.my.domain. (...)
> ;...
> ; <<a/g>> a/g
> a/g NS ns.A.domain.
> a/g NS some.other.name.server.
>
> and expecting my-ns.my.domain to automatically delegate a
> request for
> something like avalon.foo.bar to ns.A.domain or
> some.other.name.server
> (because avalon starts with one of the letters 'a' through
> 'g'. Now if a
> request for TestRecord.a/g.foo.bar came to my-ns.my.domain,
> then it *would*
> delegate that request to ns.A.domain or
> some.other.name.server.
>
> Returning to (part of) your example:
>
> > $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.
>
> that will delegate 0/25.2.0.192.in-addr.arpa to ns.A.domain
> and
> some.other.name.server. But the delegation is just textual
> in nature, not
> interpretive. There is nothing intrinsic in the delegation
> that tells
> my-ns.my.domain the addresses 192.0.2.0 through 192.0.2.127
> belong in
> 0/25.2.0.192.in-addr.arpa.
Thi is precisely what doesn't make sense. 192.0.2.0/25 IS
indeed a range of 192.0.2.0-127, which is what
0/25 NS ns.A.domain.
is saying, isn't it? In other words, isn't this saying, go to
"ns.A.domain" for address 192.0.2.0-127 ?? Otherwise, what is
the point of even writing 0/25 (which is in the context of
"2.0.192.in-addr.arpa.", so that NS, 0/25 expands to
"0/25.2.0.192.in-addr.arpa.", which should cover that range
of addresses. Other wise I just do see the point of writing
that.)
> > -----Original Message-----
> > From: bind-users-bounce at isc.org
> > [mailto:bind-users-bounce at isc.org] On Behalf Of Clenna
> Lumina
> > Sent: Thursday, January 04, 2007 2:42 PM
> > To: comp-protocols-dns-bind at isc.org
> > Subject: Re: Question about RFC-2317
> >
> > 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.
> >
>
--------------------------------------------------------------
>
=== message truncated ===
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
More information about the bind-users
mailing list