History of consolidated reverse DNS

For reverse lookup of some IP addresses within the CUDN we are using a scheme, loosely inspired by RFC 2317, but using DNAMEs rather than CNAMEs. The primary motivation is to reduce the number of small reverse zones.

For technical details, see "Pruning the reverse zone tree", which was written primarily for people outside the university. More recently we wrote a draft revision to RFC 2317 although it has been allowed to expire without passing through the standardization process.

When the scarcity of available IP addresses in 131.111/16 became critical in 2002, the Computer Laboratory kindly donated the top half of their allocation 128.232/16 for general use within the University. We used this gradually from the top down, and eventually had 32 reverse zones covering the range 128.232.[224-255].x, which were delegated from the parent reverse zone 232.128.in-addr.arpa.

In 2009, we decided to use a significant proportion of the remaining IP addresses for Wi-Fi / eduroam connections. Rather than increase the number of reverse zones further, we arranged to cover the range 128.232.[128-223].x with DNAMEs in 232.128.in-addr.arpa indirecting to PTR records maintained under in-addr.arpa.cam.ac.uk. This has proved a successful idea. Resolvers that can cope with reverse lookup done in the style of RFC 2317 (which are now widespread) can also deal with indirection done by DNAME, by virtue of the "synthesised CNAMEs" returned by nameservers.

in-addr.arpa.cam.ac.uk was initially part of the cam.ac.uk zone, but in November 2010 it was made into a separate zone of its own (at that time unsigned, but see below). It is available for stealth slaving from the authoritative nameservers, and was added to the sample configuration.

In February and March 2011 we extended the scheme to cover the range 128.232.[224-255].x as well, in a number of steps. After this the 32 individual zones 224.232.128.in-addr.arpa to 255.232.128.in-addr.arpa no longer existed, and were removed from the sample configuration.

In May 2013 the IP addresses used for Wi-Fi / eduroam connections were changed to be CUDN-wide private, but we retained the mechanism for the other addresses in the range 128.232.[128-255].x.

By January 2014 the parent zone 232.128.in-addr.arpa had been signed, together with a chain of trust from the root (see here for more details). It therefore became useful to sign the zone in-addr.arpa.cam.ac.uk as well, and this has now been done, making the results of reverse lookup for IP addresses in the range 128.232.[128-255].x fully validatable.

In September 2015 the high demand for wireless connectivity and the fragmentation of the 172.16/12 address blocks led us to start using 10.128.0.0/9, the top half of the largest RFC 1918 block. (The bottom half of this block is reserved for institution-private addresses.) To avoid the need for 129 additional zones, we are using the consolidated reverse zone technique again. Our version of the 10.in-addr.arpa zone contains 128 DNAME records pointing into the zone in-addr.arpa.private.cam.ac.uk.

There is a separate page with advice for institutions which are using the 10.0.0.0/9 address range.

For slave nameservers using BIND, slaving 232.128.in-addr.arpa (NB from the CL nameservers, not the UCS ones) and in-addr.arpa.cam.ac.uk provides the functionality that reverse lookup of IP addresses in the range 128.232.[128-255].x can then be done without contacting external nameservers.

There are more specific constraints for hosts running Windows DNS Server. In general, we now encourage administrators of such hosts not to slave zones at all, following the recommendations here. However, for those who do wish to continue such slaving, please note the following:

• Windows 2003 and 2003R2 do not support zones containing DNAMEs at all. You should not attempt to slave 232.128.in-addr.arpa, and without that slaving in-addr.arpa.cam.ac.uk is fairly pointless.

• Windows 2008R2 and (to a lesser extent) 2008 do more or less support zones containing DNAMEs. The recommendations for BIND users above may be followed.