Delagation

Kevin Darcy kcd at daimlerchrysler.com
Thu Apr 13 19:26:58 UTC 2000


I've often wondered why people prefer to delegate these "classlessly
delegated" PTR-containing zones from the in-addr.arpa tree at all. The zone is
just a container: it can be *anything* that's under the control of the entity
wishing to maintain the entries. By hanging the container zone off of
in-addr.arpa, you're basically doubling the workload of the provider -- not only
do they have to generate ($GENERATE?) the CNAMEs, but they also have to delegate
the container zone. This is an inequitable division of work, and I think it
underlies one of the reasons why many ISP's simply refuse to do "classless
delegation".

I think it would be more equitable for the parent to just generate the CNAMEs and
for the requestor to delegate the container zones from one of their *forward*
zones, e.g. rev.example.com could be dedicated to containing PTR's which are
"classlessly delegated". There is no rule, after all, that says PTRs can only
exist in the in-addr.arpa hierarchy. If you have a lot of "classless
delegations", then you might want to subdelegate the container zones, e.g. one
subzone for each external subnet, such as extranet1.rev.example.com,
extranet2.rev.example.com, etc..

In addition to distributing the workload more evenly, I think this would remove
some of the confusion about how to do "classless delegation", which mostly seems
to be caused by the fact that the FQDN's of the PTR's themselves look too much
like the FQDN's of the CNAMEs which point to them.  When one FQDN is e.g.
4.3.2.1.in-addr.arpa and other is e.g. 4.extranet1.rev.example.com, then I think
it's much easier to tell them apart...


- Kevin

Mark.Andrews at nominum.com wrote:

> >
> > > > I was suppose to have had a /27 subdelagated to my nameservers to do
> > > > reverse. I was told to put 192-224.48.245.209.in-addr.arpa in my
> > > > named.conf for the zone. This doesn't jive with the rfc. Has anyone seen
> > > > it work like this? Thanks for the time.
> > > >
> > > > andy
> > >
> > >     See RFC 2317 Classless IN-ADDR.ARPA delegation.
> >
> > I did as implied above. I really asking I suppose if that really was the
> > only way. thanks.
> >
> >
> > andy
>
>         There are only two ways to do it.
>
>         1. delegete every individual reverse record in the range.
>         2. use CNAMES to point into some other zone.
>
>         There are a number of different conventions for how to name the
>         other zone.
>
>         e.g.
>             within in-addr.arpa:
>                 first.x.y.z.in-addr.arpa         (1)
>                 first/bits.x.y.z.in-addr.arpa    (2)
>                 first-last.x.y.z.in-addr.arpa
>                 first-mask.x.y.z.in-addr.arpa
>
>             outside of in-addr.arpa:
>                 in-addr.arpa.forward.zone
>                 in-addr.forward.zone
>                 arpa.forward.zone
>                 forward.zone
>
>         (1) CNAMES for all but first address in range.
>         (2) problematic with certain resolvers
>
>         Mark
> --
> Mark Andrews, Nominum Inc. / Internet Software Consortium
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews at nominum.com






More information about the bind-users mailing list