For some reason, DNS scares a lot of people — and the most frightening of all is probably zone delegation in the in-addr.arpa space on non-octet boundaries. That’s probably why most small organizations leave this entirely to an ISP, and then deal with some web-based tool for making changes to the zone, rather than operating their own master nameserver for these zones and leaving the ISP to provide secondary service.

RFC2317 outlines the technique thoroughly, based on a trick described by Glen Herrmannsfeldt on comp.protocols.tcp-ip.domain. Below is a brief description of how this works. Read the RFC for the complete details.

First, let’s start with a brief review of how IP address space is represented in DNS. DNS spaces are shown as diagrams of inverted trees. The path of nodes, from least-specific at the top to the most-specific at the bottom describes the complete name. IP address space is under a path starting with “.” -> “arpa” -> “in-addr”, followed by each octet of the IP address. Delegation is done with NS resource records at any node, e.g.:

$ORIGIN 168.192.in-addr.arpa
10              NS      dns1.mydomain.com.
                NS      dns2.mydomain.com.

The owner of the 168.192.in-addr.arpa zone delegates control of 10.168.192.in-addr.arpa to the listed nameservers. So what happens if you want to delegate 192.168.10.128/28 ?? The problem is that we do not have a delegation point for anything smaller than an octet. The trick is to create them! How? Using CNAME resource records! The /28 is a small block of 16 addresses, and in this case it includes the IP addresses 192.168.10.128 through 192.168.10.143. We create a special zone — 128-143.10.168.192.in-addr.arpa — to hold these addresses. We delegate this as follows:

$ORIGIN 10.168.192.in-addr.arpa
128-143      NS      dns1.mydomain.com.
             NS      dns2.mydomain.com.

Now we create CNAME records for the individual addresses to point to that domain.

$ORIGIN 10.168.192.in-addr.arpa
128            CNAME   128.128-143.10.168.192.in-addr.arpa.
129            CNAME   129.128-143.10.168.192.in-addr.arpa.
...
143            CNAME   143.128-143.10.168.192.in-addr.arpa.

With BIND, these CNAME resource records can be generated with a single statement like:


$GENERATE 128-143 $ CNAME $.128-143.10.168.192.in-addr.arpa.

Now all that’s left is to create the zonefile on the master nameserver. It will look something like:

$TTL 1d
@       IN   SOA  dns1.mydomain.com  hostmaster.mydomain.com. {
                       2008020101 ; Serial
                       4h         ; Refresh
                       1h         ; Retry
                       1w         ; Expire
                       1h  }      ; Negative TTL

      IN   NS     dns1.mydomain.com.
      IN   NS     some.secondary.

129   IN   PTR    host1.mydomain.com.
130   IN   PTR    host2.mydomain.com.

Note, that RFC2317 includes an example using a slash. In our case, this would look like 128/28.10.168.192.in-addr.arpa. This will work fine, but some implementations may object to the slash as an illegal character in a hostname. The hyphenated approach is also common and avoids this possibility entirely.

You can always try this out using RFC1918 private address space and delegating to yourself. In most cases though, your ISP will do the heavy lifting and you will just add a zone based on their delegation. But it never hurts to know how to do this because you may have to explain this to someone at an ISP that is only trained to use a web-based tool to do simple changes, e.g. add/remove address and pointer records.

Advertisements