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 cam.ac.uk
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 cam.ac.uk 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
cam.ac.uk 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 *.in-addr.arpa 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 cam.ac.uk gw-808.net A 192.153.213.254 ; in zone 213.153.192.in-addr.arpa 254 PTR gw-808.net.cam.ac.uk.
one can have
; in zone cam.ac.uk gw-808.net A 192.153.213.254 254.213.153.192.in-addr.arpa PTR gw-808.net.cam.ac.uk. ; in zone 213.153.192.in-addr.arpa 254 CNAME 254.213.153.192.in-addr.arpa.cam.ac.uk.
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 213.153.192.in-addr.arpa now contains just
@ SOA ... @ NS ... $GENERATE 0-255 $ CNAME $.213.153.192.in-addr.arpa.cam.ac.uk.
Then it can be simplified further to
@ SOA ... @ NS ... @ DNAME 213.153.192.in-addr.arpa.cam.ac.uk.
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 0.0.2.0.0.3.6.0.1.0.0.2.ip6.arpa @ SOA ... @ NS ... @ DNAME 0.0.2.0.0.3.6.0.1.0.0.2.ip6.arpa.cam.ac.uk.
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 192.in-addr.arpa containing a delegation
213.153 NS ... ; several of these
it could contain the DNAME directly
213.153 DNAME 213.153.192.in-addr.arpa.cam.ac.uk.
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 111.131.in-addr.arpa @ SOA ... @ NS ... $GENERATE 0-15 $ DNAME $.111.131.in-addr.arpa.cam.ac.uk. 16 NS ... ; delegation for 16.111.131.in-addr.arpa 17 NS ... ; delegation for 17.111.131.in-addr.arpa 18 NS ... ; delegation for 18.111.131.in-addr.arpa $GENERATE 19-23 $ DNAME $.111.131.in-addr.arpa.cam.ac.uk. 24 NS ... ; delegation for 24.111.131.in-addr.arpa $GENERATE 25-255 $ DNAME $.111.131.in-addr.arpa.cam.ac.uk.
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 131.in-addr.arpa contains 111 DNAME 111.131.in-addr.arpa.cam.ac.uk. ; zone cam.ac.uk contains 16.111.131.in-addr.arpa DNAME 16.some.thing.damtp.cam.ac.uk. ; zone damtp.cam.ac.uk contains fear A 131.111.16.30 30.16.some.thing PTR fear.damtp.cam.ac.uk.
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
- 192.153.213.0/24
- 192.84.5.0/24
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:
- 128.232.128.0/18
- 128.232.192.0/19
taking this to stage 3 by promoting the DNAMEs into the
parent zone 232.128.in-addr.arpa. (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 in-addr.arpa.cam.ac.uk records were part of
the cam.ac.uk 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
- 128.232.224.0/19
(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 comcast.net) 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.
Feedback
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.