Pruning the reverse DNS zone tree

The original motivation for the sort of scheme being described here was the fact that the number of reverse zones that need to be maintained for an organisation such as ours is far greater than the number of forward zones. For example, associated with the forward zone there are 49 reverse zones for IPv4 addresses. (Just one of these is for a /16 range; the rest are for /24's.) This is only somewhat atypical: for an academic institution of comparable size with which we have mutual slaving arrangements, we slave 2 forward zones and 17 reverse zones.

Of course, most of these reverse zones are small, but any of them is potentially updated whenever is, and they all require arrangements to be made for external slaving. A proposal that could have more than doubled the number of reverse zones associated with concentrated the mind no end!

Stage 1: putting the PTR records in the forward zone

RFC 2317 describes how to use CNAMEs so that the PTR records themselves do not have to be in the natural * zone. Section 5.2 points out that they can be in any zone at all, and in particular that they can be in the forward zone that contains the inverse mapping.

Use of this technique is not restricted to the case of providing reverse lookup for subnets of less than 256 IPv4 addresses, the focus of RFC 2317. It can be applied for any reverse lookup, and the names pointed to can be chosen so that many reverse zones can have indirections into the same forward zone.

For example, instead of having

; in zone  A

; in zone
254  PTR

one can have

; in zone  A   PTR

; in zone
254  CNAME

The advantages are that the reverse zones become more or less static, while the two mutually inverse mappings can be updated in the same transaction on the forward zone. (The latter point should not be exaggerated: the records will be still be cached separately and time out independently on nameservers not slaving the forward zone.)

Stage 2: using DNAMEs instead of CNAMEs

Suppose that the zone now contains just

@  SOA    ...
@  NS     ...

Then it can be simplified further to

@  SOA    ...
@  NS     ...

Note that having a DNAME at the apex of a zone is legal, as DNAMEs only redirect names which are strictly descendants.

The space saving would be more substantial for a reverse zone covering a /16 range rather than a /24 range, and becomes absolutely mandatory if one is going to apply the same technique to reverse lookup of IPv6 addresses. For example one might have

; in zone
@  SOA    ...
@  NS     ...

but could hardly populate the zone with 280 CNAMEs instead!

Stage 3: promoting the DNAME to the parent zone

Now one can proceed to eliminate the reverse zone altogether. Instead of containing a delegation

213.153  NS     ...         ; several of these

it could contain the DNAME directly

213.153  DNAME

Of course, this requires agreement between the managers of the respective zones, and it may be a long time before the existing registrars provide this option.

Pruning branches as well as leaves

The above description assumes that the reverse zone being eliminated is a leaf; that is, that it does not contain any further delegations. If it does, one could proceed up to some point between stages 1 and 2 without problems. For example:

; in zone
@   SOA   ...
@   NS    ...
16  NS    ...     ; delegation for
17  NS    ...     ; delegation for
18  NS    ...     ; delegation for
24  NS    ...     ; delegation for
$GENERATE 25-255 $ DNAME $

But eliminating the reverse zone completely requires the managers of the child zone(s) to adopt a scheme in the style of Stage 1, putting their PTR records in an existing zone. Even then, although this:

; zone contains
111  DNAME

; zone contains  DNAME

; zone contains
fear  A
30.16.some.thing  PTR

should work, it does involve a chain of DNAMEs (or CNAMEs) to do the reverse lookup. The matter, to coin a phrase, is for further study.

What we have done so far

Most of the above was written in early 2009. As proof of concept, we first applied the this scheme to the reverse lookup for two small IPv4 subnets


taking things as far as stage 2 (DNAME at the reverse zone apex). More recently we have restored these reverse zones to a more usual state.

In April 2009, we applied the scheme to reverse lookup for these IPv4 ranges:


taking this to stage 3 by promoting the DNAMEs into the parent zone (This zone is managed by the Computer Laboratory hostmasters, and we thank them for their co-operation.) Many of these IP addresses have subsequently been used for eduroam connections, and almost no trouble has been caused by the use of DNAMEs in their reverse lookup.

Originally, the records were part of the zone, but more recently we have made it a delegated subzone. No final conclusion on the relative merits of the two arrangemnts has been reached.

In March 2011, we extended this to also cover the range


(previously organised as 32 reverse zones) in which there are addresses allocated to many organisations within the university.

This has turned up a problem, however, because one organisation emits e-mail directly from an address in this range, rather than via our central mail switches. It turns out that there are occasional SMTP receivers (including those for that (a) require a reverse lookup on the caller's IP address to succeed, and (b) have defective resolvers that fail the reverse lookup if a DNAME is present.


We would be interested in hearing from anyone who has used similar schemes, or detects problems with what we are doing.

-- Chris Thompson, February 2009 and April 2011

Addendum: In 2015 Tony Finch wrote a draft revision to RFC 2317 which includes this DNAME scheme, although the draft was allowed to expire without passing through the IETF standardization process.