Avoid RFC 2317 style delegation of "in-addr.arpa."

You've come to this page because you've asked a question similar to the following:

I have a block of IP version 4 addresses assigned to me by my ISP, the reverse lookup domain of which I want to serve up from my content DNS servers so that I have control over the address to name mappings for them. Unfortunately, the netmask of the block is not on an octet boundary (i.e. it is "classless"). How should I and my ISP handle this ?

This is the Frequently Given Answer to that question.

RFC 2317 describes one way of handling this, by adding extra intermediate levels to the namespace hierarchy, in your ISP's part of the "in-addr.arpa." subtree. It is a complex and clever scheme involving "CNAME" records and domain names (not only whose exact format is left unspecified, but also for which RFC 2371 even encourages ISPs to invent their own private syntax) such as "1-" and "192/".

It is also completely unnecessary and breaks several features of many DNS softwares.

RFC 2317 style delegation breaks the convenience features of many DNS client and DNS server softwares, because it changes the name of the reverse lookup domain that is used to look up address→name mappings, replacing the standard one that is specified in RFC 1035 § 3.5. For example:

Classless delegation within "in-addr.arpa." can be handled very simply without any of the complex gyrations and contortions described in RFC 2317. It can be handled in exactly the same conventional manner as delegations in forward lookup domains, and using the standard reverse lookup domain names that are specified in RFC 1035 § 3.5.

Rather than muck about with aliases as RFC 2317 would have it do, all that your ISP needs to do is to delegate the reverse lookup domain name of each of the IP addresses to your content DNS server, individually. All that you need to do is have your content DNS server publish the reverse lookup information (and some appropriate DNS server and glue records).

If it sounds simple, that's because it is. Here are two concrete examples demonstrating how it works in practice: Example 1 Example 2.

The fundamental mistake made by the authors of RFC 2317 is that it didn't occur to them that a delegation from a superdomain's content DNS servers does not have to point to the apices of the "zones" in the subdomain's content DNS servers. Or, put another way, it is not necessary for the apex of a "zone" to be a domain that the rest of the world considers to be within the content DNS server's bailiwick.

From this mistaken initial premise springs RFC 2317's whole scheme. RFC 2317 attempts to address what it perceives as difficulties in your - the subdomain's - content DNS servers (or, at least, difficulties that would be there if you used ISC's BIND). The reasoning is that since with ISC's BIND having the "zone" apices at the delegation points makes it difficult to administer the database, one has to use aliases to create a single delegation point, thereby allowing a single "zone" to be used in the content DNS servers for the subdomain.

But this reasoning is flawed. Not all DNS server softwares share BIND's problem of storing different "zones" in different database files, for a start, so even if the initial premise were true, it would only be a problem for people using ISC's BIND, and not a problem for people using other DNS server softwares. However, the initial premise is mistaken. There's no technical reason that prevents a superdomain's content DNS servers from serving up referrals that point into what the subdomain's content DNS servers consider to be the middle of a "zone".

The scheme described in RFC 2317 is an overcomplex and byzantine solution to a problem that can be solved in a far simpler manner and without breaking many DNS softwares in the process. Avoid using it if at all possible.

© Copyright 2001–2003,2009 Jonathan de Boyne Pollard. "Moral" rights asserted.
Permission is hereby granted to copy and to distribute this web page in its original, unmodified form as long as its last modification datestamp is preserved.