6.5 Delegating Reverse-Mapping for Networks Smaller than a /24

6.5.1 Problem

You want to delegate responsibility for reverse-mapping a network's IP addresses to a set of name servers, but the network or subnet is smaller than a /24.

6.5.2 Solution

Add CNAME records to the domain names that would normally own PTR records, making those domain names aliases to domain names in other zones. Those zones can be either new zones or existing zones. If they are new zones, delegate the zones to the appropriate name servers. If they are existing zones, make sure they're already delegated to the proper name servers.

Here's an example. Say you manage 0.168.192.in-addr.arpa, the reverse-mapping zone for the network 192.168.0/24. You have divided it into two subnets, though: 192.168.0.0/25 and 192.168.0.128/25. You'd like to delegate responsibility for maintaining each subnet's reverse-mapping information to a different set of name servers, but you've only got a single reverse-mapping zone, 0.168.192.in-addr.arpa.

So you add CNAME records to the zone data file for 0.168.192.in-addr.arpa. In addition, the administrator of the first subnet, 192.168.0.0/25, wants a new subdomain, 0-127.0.168.192.in-addr.arpa, delegated to his name servers. The administrator of the 192.168.0.128/25 subnet has an existing zone, bar.example, and he'd like to manage just that zone.

For the first subnet, you add CNAME records like these:

1.0.168.192.in-addr.arpa.    IN    CNAME    1.0-127.0.168.192.in-addr.arpa.
2.0.168.l92.in-addr.arpa.    IN    CNAME    2.0-127.0.168.192.in-addr.arpa.

For the second subnet, you add CNAME records like these:

129.0.168.192.in-addr.arpa.    IN    CNAME    129.0.168.192.bar.example.
130.0.168.192.in-addr.arpa.    IN    CNAME    130.0.168.192.bar.example.

Since the 0-127.0.168.192.in-addr.arpa subdomain is new, you'll also need to add delegation to the 0.168.192.in-addr.arpa zone data file:

0-127.0.168.192.in-addr.arpa.    IN    NS    ns1.foo.example.
0-127.0.168.192.in-addr.arpa.    IN    NS    ns2.foo.example.

On ns1.foo.example and ns2.foo.example, the administrator would add zone statements like this one:

zone "0-127.0.168.192.in-addr.arpa" {
    type master;
    file "db.192.168.0.0-127";
};

And within the zone data file for 0-127.0.168.192.in-addr.arpa, he'd add PTR records like these:

1.0-127.0.168.192.in-addr.arpa.    IN    PTR    ns1.foo.example.
2.0-127.0.168.192.in-addr.arpa.    IN    PTR    mail.foo.example.

The administrator of the second subnet can add PTR records like these to the zone data file for bar.example:

129.0.168.192.bar.example.    IN    PTR    monkey.bar.example.
130.0.168.192.bar.example.    IN    PTR    martini.bar.example.

6.5.3 Discussion

This scheme is fairly simple, although its simplicity is obscured by all the nasty syntax. Basically, where you'd normally add PTR records in the 0.168.192.in-addr.arpa zone, you add CNAME records that create aliases to domain names in other zones. Then, at the domain names those aliases point to, you attach PTR records. A name server looking up a PTR record for 2.0.168.192.in-addr.arpa, for example, will find that that domain name is an alias for 2.0-127.0.168.192.in-addr.arpa, and on a successive lookup will find the PTR record attached to 2.0-127.0.168.192.in-addr.arpa.

If you need to create lots of very similar CNAME records, avail yourself of the $GENERATE control statement, introduced back in Section 2.21. For example, you could create CNAME records for all of the 192.168.0.0/25 network with just this control statement:

$GENERATE 1-127 $ CNAME $.0-127.0.168.192.in-addr.arpa.

The naming scheme I used for the new zone, 0-127.0.168.192.in-addr.arpa, reflects both the values of the first three octets of the reverse-mapped addresses (192.168.0) and the range of values in the fourth octet (0 to 127). This scheme is just a useful convention, though; there's nothing magic about it. If you prefer a different scheme, you're welcome to use it.

6.5.4 See Also

Section 2.21, for the syntax of the $GENERATE control statement; RFC 2317, the official description of the technique; and "Subnetting on a Non-Octet Boundary" in Chapter 9 of DNS and BIND.