New CIDR reverse delegation scheme (was: `Re: reverse dns problems')

[Kevin Darcy]

Will Yardley wrote:

> Michael Kjorling wrote:
>
> > Well, RFC 2317 is about the best solution I've been able to come up
> > with as well that does reverse delegation on networks less than a /24
> > in a relatively nice way without breaking anything. Create a new zone
> > (it doesn't even have to be under in-addr.arpa, if some drainbead ISP
> > wants to put it somewhere else :)) and use CNAMEs to point into that
> > zone, then delegate the new zone while keeping authority for the /24
> > one.
> >
> > Properly implemented (using $GENERATE and a good zone-naming scheme)
> > it isn't any more complex than standard classful reverse delegations
> > (given that the ISP has a block bigger than the /24 assigned). The
> > trick is to have the ISP and end-user agree on the zone name; apart
> > from that I can see no obvious problems.
>
> It's a bit messy though - having a CNAME and then a PTR - it would be a lot
> nicer and cleaner if the reverse record would point to a PTR.  It seems as if
> (without breaking anything) bind could include a way to internally allow a <
> /24 zone to be created, and allow $GENERATE to be used for NS records
> somehow.  That way, the NS records would point to the correct record but the
> internal resolver would treat the zone file as if it were individual zone
> files as far as resolution is concerned (ie it wouldn't think it was
> authoritative for the whole class C.  That way it should be backwards
> compatible but would still be easier to maintain and less of a hack.  I'm
> sure there's an obvious reason that's not possible, but i can't think of it.

One way or another, for every address, you need a PTR record (the "leaf" node),
and _something_ to point to that PTR record, since the leaf node and the /24
reverse zone are controlled by different organizations. What does it matter
whether that "something" is an NS record or a CNAME?

Note that RFC 2317 does not *require* the creation of a new zone to contain the
PTR records. With mutual agreement, the upstream provider can point those CNAMEs
to names in any zone that the customer controls, including possibly their
regular "forward" zones, e.g. example.com, or some descendant zone thereof.
There's no rule that says all PTR names must be in the in-addr.arpa namespace.
In fact, there isn't even a rule that says PTR records must only be used for
reverse DNS...

IMO, ISPs should eventually provide cypto-authenticated Dynamic Update to their
/24 reverse zones so that customers can securely update their own PTR records
without requiring any RFC 2317 hacks or delegating each address as a separate
zone. BIND's ACL mechanism is a bit clumsy for this presently (you could use the
"self" update-policy element, generating a separate key for every record), but
hopefully it can be improved.


- Kevin