2010-04-26 - News - Chris Thompson
There is a new sample configuration for nameservers on the CUDN at
http://jackdaw.cam.ac.uk/ipreg/nsconfig/sample.named.conf
The following changes have been made:
Some references relating to DNSSEC validation have been added. For more details, though, consult as before
http://jackdaw.cam.ac.uk/ipreg/nsconfig/dnssec-validation.html
A recommended setting for "max-journal-size" is included. Without this, the journal files for incrementally updated zones will grow indefinitely, and for signed zones in particular they can become extremely large.
The most significant change concerns the zone private.cam.ac.uk
.
Previously, there was no delegation for this zone in cam.ac.uk
.
However, we have found that with the most recent versions of BIND,
defining private.cam.ac.uk
as either "type stub" or "type forward"
in combination with using DNSSEC validation, led to validation failures
due to BIND's inability to prove private.cam.ac.uk
unsigned while
cam.ac.uk
is signed.
On consideration, we have decided to create a delegation for
private.cam.ac.uk
after all. (The only effect for users outside
the CUDN should be that they will consistently get a REFUSED response
for names in that zone, instead of sometimes getting NXDOMAIN instead.)
This will also allow us to increase the number of official nameservers
for private.cam.ac.uk
(within the CUDN, obviously), and perhaps to
sign it without having to advertise a trust anchor for it by special
means.
Nameservers on the CUDN should therefore either slave private.cam.ac.uk
,
or not define it at all in their configuration. (Using "type stub" or
"type forward" will continue to work for non-validating servers, but
should be phased out.)
However, our corresponding reverse zones 16.172.in-addr.arpa
through 30.172.in-addr.arpa
cannot be delegated from the parent
zone "172.in-addr.arpa". Luckily there are delegations there to
the IANA "black hole" (AS112) servers, and this suffices to make
the zones provably unsigned. Any of "type slave", "type stub"
or "type forward" can be used for these zones (with or without
validation) and one of them must be used or reverse lookups
will fail.