Rationale for the recent changes to recommended AD configurations

2010-02-03 - News - Chris Thompson

You will probably have seen Andy Judd's message to ucam-itsupport last Friday announcing new recommendations for Active Directory and Windows DNS Server configurations within the CUDN, described more fully at


These were the result of discussions between our PC Support group and our Hostmaster group. This message gives part of the background to our thinking, and some points may be relevant to institutions not using Windows DNS Server at all.

It will be no surprise that the advice not to ("stealth") slave zones from the CUDN central (authoritative) nameservers was motivated by the deficiencies of the various versions of Windows DNS Server when slaving signed zones (not to mention other defects in its treatment of unknown DNS record types and SOA serial number handling). Not slaving zones such as cam.ac.uk does have the disadvantage that resolving of names and addresses of hosts local to the institution may fail if it is cut off from the rest of the CUDN, but we think this should be tolerated because of the other advantages.

The advice to forward requests not resolved locally to the CUDN central (recursive) nameservers may seem contrary to advice given in https://jackdaw.cam.ac.uk/ipreg/nsconfig/sample.named.conf and in previous messages to this list. In the case of Windows DNS Server configurations the primary intent was to make sure that queries for names in private.cam.ac.uk and corresponding reverse lookups worked correctly. (Configured laboriously via GUI, many zones were omitted from Windows DNS Server setups in the past.) However, there is the more general point that the central servers provide DNSSEC validation for the increasing proportion of names for which it is available, and forwarding requests to them takes advantage of that if validation is not being performed locally. We should admit, though, that the communication path between the institution and the CUDN central nameservers is not yet secured cryptographically. (If there is a fully functional validating recursive nameserver local to the institution, that could of course be used instead of the CUDN central nameservers.)

Another issue is the likelihood that we will be changing the set of reverse zones available for slaving during the next year. In particular we are likely to want to extend the scheme described at http://people.pwf.cam.ac.uk/cet1/prune-reverse-zones which we are already using for reverse lookup of the 128.232.[128-223].x range to cover 128.232.[224-255].x as well, eliminating the 32 individual zones used for the latter range at present.