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-32.0.0.127.in-addr.arpa." and "192/5.2.1.10.in-addr.arpa.".
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:
If one employs RFC 2317 style delegation, one cannot test one's content DNS servers directly using dig with the -x option. One is instead required to determine by hand what reverse lookup domain name to use (which will, of course, vary according to the specific private syntax that is being employed), and explicitly provide that to dig.
If one employs RFC 2317 style delegation, the feature of djbdns that allows one to specify both address→name and name→address mappings with a single database record, and thus automatically keep them the inverses of each other, is rendered useless. The record will create the address→name mapping using the standard RFC 1035 reverse lookup domain name. But because of the RFC 2317 style delegation, this datum will never actually be used. One is instead required to determine by hand what reverse lookup domain name to use, and explicitly create a second database record.
If one employs RFC 2317 style delegation, the feature of Microsoft's DNS server that allows one to create both address→name and name→address mappings at the same time is rendered useless. The address→name mapping is created using the standard RFC 1035 reverse lookup domain name. But because of the RFC 2317 style delegation, this datum will never actually be used. One is instead required to determine by hand what reverse lookup domain name to use, and explicitly create a second database record.
If one employs RFC 2317 style delegation, the feature of Microsoft's DNS server that ensures that the related address→name mapping is deleted when a name→address mapping is deleted is rendered non-functional. The server attempts to delete the address→name mapping that uses the standard RFC 1035 reverse lookup domain name. But because of the RFC 2317 style delegation, this is not the right thing to be deleting. One is instead required to determine by hand what reverse lookup domain name to use, and explicitly delete the relevant database record.
If one employs RFC 2317 style delegation, the features of Microsoft's DHCP clients and DHCP servers, whereby the address→name mappings for machines' IP addresses are automatically created and destroyed (via dynamic DNS) as the IP addresses are assigned to and removed from the machines, are rendered non-functional. The address→name mapping is registered (by the Microsoft DHCP client or DHCP server) using the standard RFC 1035 reverse lookup domain name. But because of the RFC 2317 style delegation, this datum will never actually be used. There is no workaround for this problem. Address→name lookups will simply not be updated dynamically and automatically as IP addresses are assigned to and removed from machines.
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.