Delagation

[Kevin Darcy]

Barry Margolin wrote:

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

Agreed, that's almost certainly the main reason. But the workload I think is another
reason. A lot of smaller ISP's probably only have 1 person who really knows DNS very
well, and they're probably already busy enough setting up forward zones.

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

Those tools probably weren't designed to delegate in-addr.arpa zones beyond the
3rd-octet level either, so again we're talking about more work, i.e. to update the
tools.

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

But isn't it more convenient for the CNAME itself to convey information about who
actually maintains the address range? E.g. if a CNAME points to a 4.rev.example.com
PTR then it's probably a good bet that example.com is associated with the address.
You don't have to do a separate lookup to find that out.


- Kevin