1Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") 2Copyright (C) 2000-2002 Internet Software Consortium. 3See COPYRIGHT in the source root or http://isc.org/copyright.html for terms. 4 5DNSSEC Release Notes 6 7This document summarizes the state of the DNSSEC implementation in 8this release of BIND9. 9 10 11OpenSSL Library Required 12 13To support DNSSEC, BIND 9 must be linked with version 0.9.6e or newer of 14the OpenSSL library. As of BIND 9.2, the library is no longer 15included in the distribution - it must be provided by the operating 16system or installed separately. 17 18To build BIND 9 with OpenSSL, use "configure --with-openssl". If 19the OpenSSL library is installed in a nonstandard location, you can 20specify a path as in "configure --with-openssl=/var". 21 22 23Key Generation and Signing 24 25The tools for generating DNSSEC keys and signatures are now in the 26bin/dnssec directory. Documentation for these programs can be found 27in doc/arm/Bv9ARM.4.html and the man pages. 28 29The random data used in generating DNSSEC keys and signatures comes 30from either /dev/random (if the OS supports it) or keyboard input. 31Alternatively, a device or file containing entropy/random data can be 32specified. 33 34 35Serving Secure Zones 36 37When acting as an authoritative name server, BIND9 includes KEY, SIG 38and NXT records in responses as specified in RFC2535 when the request 39has the DO flag set in the query. 40 41 42Secure Resolution 43 44Basic support for validation of DNSSEC signatures in responses has 45been implemented but should still be considered experimental. 46 47When acting as a caching name server, BIND9 is capable of performing 48basic DNSSEC validation of positive as well as nonexistence responses. 49This functionality is enabled by including a "trusted-keys" clause 50in the configuration file, containing the top-level zone key of the 51the DNSSEC tree. 52 53Validation of wildcard responses is not currently supported. In 54particular, a "name does not exist" response will validate 55successfully even if it does not contain the NXT records to prove the 56nonexistence of a matching wildcard. 57 58Proof of insecure status for insecure zones delegated from secure 59zones works when the zones are completely insecure. Privately 60secured zones delegated from secure zones will not work in all cases, 61such as when the privately secured zone is served by the same server 62as an ancestor (but not parent) zone. 63 64Handling of the CD bit in queries is now fully implemented. Validation 65is not attempted for recursive queries if CD is set. 66 67 68Secure Dynamic Update 69 70Dynamic update of secure zones has been implemented, but may not be 71complete. Affected NXT and SIG records are updated by the server when 72an update occurs. Advanced access control is possible using the 73"update-policy" statement in the zone definition. 74 75 76Secure Zone Transfers 77 78BIND 9 does not implement the zone transfer security mechanisms of 79RFC2535 section 5.6, and we have no plans to implement them in the 80future as we consider them inferior to the use of TSIG or SIG(0) to 81ensure the integrity of zone transfers. 82 83 84Id: dnssec,v 1.19 2004/03/05 05:04:53 marka Exp 85