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