Delagation

[Barry Margolin]

In article <38F61F82.DB8AA479 at daimlerchrysler.com>,
Kevin Darcy  <kcd at daimlerchrysler.com> wrote:
>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".

Most of the work is in creating the CNAME records.  Delegating the reverse
subdomain is a minor addition, and I don't think it has anything to do with
why some ISPs don't do classless delegation.  I believe the main reason is
that some of them simply aren't familiar with it.  Others may have tools
that generate their DNS files, and they've never enhanced them to support
creating CNAME records in reverse domains (that was our situation until
last summer).

>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..

If we get a subnet reverse domain delegated to us, our tool requires it to
be in a reverse domain.  Our DNS database generates PTR records
automatically from a table that's organized by hostnames, and has a
heuristic to figure out which reverse zone the PTR record belongs in.  It
looks for the most specific in-addr.arpa zone, and in the case of classless
delegation it will recognize z/n.y.x.w.in-addr.arpa (where the '/' can be
any non-numeric character) as being the reverse zone for all addresses in
the CIDR block w.x.y.z/n.

In an upcoming redesign I plan on having a separate field in our database
that specifies what CIDR block a zone should contain PTR records for, and
in that implementation we could put them in forward or reverse zones.

Putting them in in-addr.arpa is also somewhat intuitive.  You can use
something like:

dig -x w.x.y.z/n ns

to see the delegation record.

-- 
Barry Margolin, barmar at genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.