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

Michael Kjorling michael at kjorling.com
Sun Aug 5 23:03:58 UTC 2001


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

The RFC (2317) mentions startaddr/masklength.xxx.xxx.xxx.in-addr.arpa
as an example naming scheme and recommends using another character
(e.g. a hyphen), and most people seems to settle with
startaddr-masklength.xxx.xxx.xxx.in-addr.arpa or (in some cases)
startaddr-endaddr.xxx.xxx.xxx.in-addr.arpa. Anything that doesn't
conflict with the standard in-addr.arpa scheme can be used.

Do you have any better suggestions that doesn't break reverse lookups
for the rest of the /24? Having to install CNAMEs for all IPs you
don't control and delegate them _back_ to the ISP certainly won't
work; how is the ISP supposed to properly delegate them? Asking for a
PTR but getting a CNAME pointing to one or more NS RRs which in turn
delegate authority towards a bunch of PTRs seems terribly far-fetched
and like it requires a lot of extra processing to me. Plus, it creates
a burden on BOTH the ISP and the end-user. That doesn't sound like a
good thing.


Michael Kjörling


On Aug 5 2001 14:47 -0700, Will Yardley wrote:

> It seems like CIDR is enough of a reality now that there should be a more
> elegant solution than the CNAME hack [RFC 2317 //Michael Kjorling]; why isn't it possible to incorporate
> some way to create at least a slightly less complex hack into bind 9?
>
> Not that i'm volunteering to code it or anything :>
>
> w

- -- 
Michael Kjörling - michael at kjorling.com - PGP: 8A70E33E
Manager Wolf.COM -- Programmer -- Network Administrator
"We must be the change we wish to see" (Mahatma Gandhi)

^..^     Support the wolves in Norway -- go to     ^..^
 \/   http://home.no.net/ulvelist/protest_int.htm   \/

***** Please only send me emails which concern me *****

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE7bdDiKqN7/Ypw4z4RAuPBAJ9YuHwS52B/ud5nuZow6v0bGvuqiACbBSH2
JYj/9+NLz8GNHQYa4OqEPPA=
=aGAY
-----END PGP SIGNATURE-----




More information about the bind-users mailing list