Taking a DNS name and resolving it to the address of a machine is easy to understand and easy to implement if you’re an administrator. Doing a reverse lookup from an address back to a name, however, is more difficult due to the way addresses are divided up. I won’t attempt to describe the details here (I recommend Liu and Albitz’s DNS and BIND for the gory details), but in short, the way this works is by breaking an IP address into its four octets and handling them from there like regular hierarchical names in the special in-addr.arpa zone: PTR foo.example.com.

This is problematic for two main reasons:

  • You have to change two zones every time you change a DNS name.
  • If you have fewer than 256 addresses, your ISP can’t delegate the appropriate subset of the in-addr.arpa zone to you so you can maintain it yourself. This usually forces you to log into a web page provided by your ISP every time you change a DNS name.

RFC 2317 notes that you can work around this by filling up your subset of the in-addr.arpa zone with CNAME records instead of the usual PTR records like this:

$ORIGIN 2.0.192.in-addr.arpa.

1   CNAME 1.ip4.example.com.
2   CNAME 2.ip4.example.com.
253 CNAME 253.ip4.example.com.
254 CNAME 254.ip4.example.com.

After you set this up you can control your forward and reverse DNS records from the same place without needing to change the reverse zone you just set up:

$ORIGIN example.com.

foo A
bar A
baz A
bop A

1.ip4   PTR foo
2.ip4   PTR bar
253.ip4 PTR baz
254.ip4 PTR bop

Of course, if you rely on your ISP to create reverse DNS names for you they have to be willing to create non-PTR records before you can take advantage of this.

If you’re lucky enough to have an entire /24 block of addresses all to yourself you can simplify the reverse DNS zone by simply mapping the entire set of addresses with a single DNAME instead of a long list of CNAMEs:

$ORIGIN 2.0.192.in-addr.arpa.

@ DNAME ip4.example.com.

This has the same net effect as the list of CNAMEs, but it shortens things significantly.