Copyright (C) 2000, 2001 Internet Software Consortium.
See COPYRIGHT in the source root or http://isc.org/copyright.html for terms.
DNSSEC Release Notes
This document summarizes the state of the DNSSEC implementation in
this release of BIND9.
Key Generation and Signing
The tools for generating DNSSEC keys and signatures are now in the
bin/dnssec directory. Documentation for these programs can be found
in doc/arm/Bv9ARM.4.html and the man pages.
The random data used in generating DNSSEC keys and signatures comes from
either /dev/random (if the OS supports it) or keyboard input. Alternatively,
a device or file containing entropy/random data can be specified.
Serving Secure Zones
When acting as an authoritative name server, BIND9 includes KEY, SIG
and NXT records in responses as specified in RFC2535.
Response generation for wildcard records in secure zones is not fully
supported. Responses indicating the nonexistence of a name include a
NXT record proving the nonexistence of the name itself, but do not
include any NXT records to prove the nonexistence of a matching
wildcard record. Positive responses resulting from wildcard expansion
do not include the NXT records to prove the nonexistence of a
non-wildcard match or a more specific wildcard match.
Secure Resolution
Basic support for validation of DNSSEC signatures in responses has
been implemented but should still be considered experimental.
When acting as a caching name server, BIND9 is capable of performing
basic DNSSEC validation of positive as well as nonexistence responses.
This functionality is enabled by including a "trusted-keys" clause
in the configuration file, containing the top-level zone key of the
the DNSSEC tree.
Validation of wildcard responses is not currently supported. In
particular, a "name does not exist" response will validate
successfully even if it does not contain the NXT records to prove the
nonexistence of a matching wildcard.
Proof of insecure status for insecure zones delegated from secure
zones works when the zones are completely insecure. Privately
secured zones delegated from secure zones will not work in all cases,
such as when the privately secured zone is served by the same server
as an ancestor (but not parent) zone.
Handling of the CD bit in queries is now fully implemented. Validation
is not attempted for recursive queries if CD is set.
Secure Dynamic Update
Dynamic update of secure zones has been implemented, but may not be
complete. Affected NXT and SIG records are updated by the server when
an update occurs. Advanced access control is possible using the
"update-policy" statement in the zone definition.
Performance of Cryptographic Operations
The cryptographic primitives used by the BIND 9 DNSSEC implementation
are based on the OpenSSL library. A version of that library is
integrated into the distribution, but for portability reasons this
version does not make use of any platform-specific assembly language
routines.
On many platforms, particularly i386 and SPARC, a significant
improvement in signing and verification speed can be achieved linking
BIND 9 with a separate OpenSSL library that uses hand-optimized
assembly language routines. To do this, you need to install OpenSSL
version 0.9.5a or newer separately from the BIND 9 tree prior to
building BIND 9, using the default openssl configuration settings
which will cause it to be built with assembly language routines. Then
specifying the "--with-openssl" option to the BIND 9 configure script
to make BIND 9 link against the system openssl library rather than its
own. For example, if openssl was installed under /usr/local, use
"configure --with-openssl=/usr/local".
$Id: dnssec,v 1.9.4.1 2001/01/09 22:43:10 bwelling Exp $