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
http://www-tus.csx.cam.ac.uk/windows_support/Current/activedirectory/dns/ad_dns_config_info.html
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.