head	1.3;
access;
symbols
	RELENG_8_4:1.3.0.2
	RELENG_9_1_0_RELEASE:1.2.2.1
	RELENG_9_1:1.2.2.1.0.2
	RELENG_9_1_BP:1.2.2.1
	RELENG_8_3_0_RELEASE:1.1.1.2.10.1
	RELENG_8_3:1.1.1.2.10.1.0.2
	RELENG_8_3_BP:1.1.1.2.10.1
	RELENG_9_0_0_RELEASE:1.2
	RELENG_9_0:1.2.0.4
	RELENG_9_0_BP:1.2
	RELENG_9:1.2.0.2
	RELENG_9_BP:1.2
	RELENG_7_4_0_RELEASE:1.1.1.2
	RELENG_8_2_0_RELEASE:1.1.1.2
	RELENG_7_4:1.1.1.2.0.20
	RELENG_7_4_BP:1.1.1.2
	RELENG_8_2:1.1.1.2.0.18
	RELENG_8_2_BP:1.1.1.2
	RELENG_8_1_0_RELEASE:1.1.1.2
	RELENG_8_1:1.1.1.2.0.16
	RELENG_8_1_BP:1.1.1.2
	RELENG_7_3_0_RELEASE:1.1.1.2
	RELENG_7_3:1.1.1.2.0.14
	RELENG_7_3_BP:1.1.1.2
	RELENG_8_0_0_RELEASE:1.1.1.2
	RELENG_8_0:1.1.1.2.0.12
	RELENG_8_0_BP:1.1.1.2
	RELENG_8:1.1.1.2.0.10
	RELENG_8_BP:1.1.1.2
	RELENG_7_2_0_RELEASE:1.1.1.2
	RELENG_7_2:1.1.1.2.0.8
	RELENG_7_2_BP:1.1.1.2
	RELENG_7_1_0_RELEASE:1.1.1.2
	RELENG_6_4_0_RELEASE:1.1.1.1.4.1
	RELENG_7_1:1.1.1.2.0.6
	RELENG_7_1_BP:1.1.1.2
	RELENG_6_4:1.1.1.1.4.1.0.2
	RELENG_6_4_BP:1.1.1.1.4.1
	RELENG_7_0_0_RELEASE:1.1.1.2
	RELENG_6_3_0_RELEASE:1.1.1.1
	RELENG_7_0:1.1.1.2.0.4
	RELENG_7_0_BP:1.1.1.2
	BIND_9_4_2:1.1.1.2
	RELENG_6_3:1.1.1.1.0.12
	RELENG_6_3_BP:1.1.1.1
	RELENG_7:1.1.1.2.0.2
	RELENG_7_BP:1.1.1.2
	BIND_9_4_1_P1:1.1.1.2
	BIND_9_4_1:1.1.1.2
	BIND_9_3_4:1.1.1.1
	RELENG_6_2_0_RELEASE:1.1.1.1
	BIND_9_3_3:1.1.1.1
	RELENG_6_2:1.1.1.1.0.10
	RELENG_6_2_BP:1.1.1.1
	RELENG_5_5_0_RELEASE:1.1.1.1.2.1
	RELENG_5_5:1.1.1.1.2.1.0.6
	RELENG_5_5_BP:1.1.1.1.2.1
	RELENG_6_1_0_RELEASE:1.1.1.1
	RELENG_6_1:1.1.1.1.0.8
	RELENG_6_1_BP:1.1.1.1
	BIND_9_3_2:1.1.1.1
	RELENG_6_0_0_RELEASE:1.1.1.1
	RELENG_6_0:1.1.1.1.0.6
	RELENG_6_0_BP:1.1.1.1
	RELENG_6:1.1.1.1.0.4
	RELENG_6_BP:1.1.1.1
	RELENG_5_4_0_RELEASE:1.1.1.1.2.1
	RELENG_5_4:1.1.1.1.2.1.0.4
	RELENG_5_4_BP:1.1.1.1.2.1
	BIND_9_3_1:1.1.1.1
	RELENG_5_3_0_RELEASE:1.1.1.1.2.1
	RELENG_5_3:1.1.1.1.2.1.0.2
	RELENG_5_3_BP:1.1.1.1.2.1
	RELENG_5:1.1.1.1.0.2
	BIND_9_3_0:1.1.1.1
	BIND_9_3_0_RC4:1.1.1.1
	ISC:1.1.1;
locks; strict;
comment	@# @;


1.3
date	2012.04.05.04.29.35;	author dougb;	state Exp;
branches
	1.3.2.1;
next	1.2;

1.2
date	2011.05.28.00.21.28;	author dougb;	state Exp;
branches
	1.2.2.1;
next	1.1;

1.1
date	2004.09.19.01.30.08;	author trhodes;	state Exp;
branches
	1.1.1.1;
next	;

1.3.2.1
date	2012.04.05.04.29.35;	author svnexp;	state dead;
branches;
next	1.3.2.2;

1.3.2.2
date	2013.03.28.13.00.21;	author svnexp;	state Exp;
branches;
next	;

1.2.2.1
date	2012.04.08.01.43.41;	author dougb;	state Exp;
branches;
next	;

1.1.1.1
date	2004.09.19.01.30.08;	author trhodes;	state Exp;
branches
	1.1.1.1.2.1
	1.1.1.1.4.1;
next	1.1.1.2;

1.1.1.2
date	2007.06.02.23.21.18;	author dougb;	state Exp;
branches
	1.1.1.2.2.1
	1.1.1.2.10.1;
next	;

1.1.1.1.2.1
date	2004.09.26.03.09.39;	author des;	state Exp;
branches;
next	;

1.1.1.1.4.1
date	2008.06.03.05.38.10;	author dougb;	state Exp;
branches;
next	;

1.1.1.2.2.1
date	2011.05.28.00.58.19;	author dougb;	state Exp;
branches;
next	;

1.1.1.2.10.1
date	2011.05.28.00.33.06;	author dougb;	state Exp;
branches;
next	1.1.1.2.10.2;

1.1.1.2.10.2
date	2012.04.05.04.31.17;	author dougb;	state Exp;
branches;
next	;


desc
@@


1.3
log
@SVN rev 233914 on 2012-04-05 04:29:35Z by dougb

Update to version 9.8.2, the latest from ISC, which contains numerous bug fixes.
@
text
@Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
Copyright (C) 2000-2002  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.


OpenSSL Library Required

To support DNSSEC, BIND 9 must be linked with version 0.9.6e or newer of
the OpenSSL library.  As of BIND 9.2, the library is no longer
included in the distribution - it must be provided by the operating
system or installed separately.

To build BIND 9 with OpenSSL, use "configure --with-openssl".  If
the OpenSSL library is installed in a nonstandard location, you can
specify a path as in "configure --with-openssl=/var".


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 when the request
has the DO flag set in the query.


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.


Secure Zone Transfers

BIND 9 does not implement the zone transfer security mechanisms of
RFC2535 section 5.6, and we have no plans to implement them in the
future as we consider them inferior to the use of TSIG or SIG(0) to
ensure the integrity of zone transfers.


$Id: dnssec,v 1.19 2004/03/05 05:04:53 marka Exp $
@


1.3.2.1
log
@file dnssec was added on branch RELENG_8_4 on 2013-03-28 13:00:21 +0000
@
text
@d1 84
@


1.3.2.2
log
@## SVN ## Exported commit - http://svnweb.freebsd.org/changeset/base/248810
## SVN ## CVS IS DEPRECATED: http://wiki.freebsd.org/CvsIsDeprecated
@
text
@a0 84
Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
Copyright (C) 2000-2002  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.


OpenSSL Library Required

To support DNSSEC, BIND 9 must be linked with version 0.9.6e or newer of
the OpenSSL library.  As of BIND 9.2, the library is no longer
included in the distribution - it must be provided by the operating
system or installed separately.

To build BIND 9 with OpenSSL, use "configure --with-openssl".  If
the OpenSSL library is installed in a nonstandard location, you can
specify a path as in "configure --with-openssl=/var".


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 when the request
has the DO flag set in the query.


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.


Secure Zone Transfers

BIND 9 does not implement the zone transfer security mechanisms of
RFC2535 section 5.6, and we have no plans to implement them in the
future as we consider them inferior to the use of TSIG or SIG(0) to
ensure the integrity of zone transfers.


$Id: dnssec,v 1.19 2004/03/05 05:04:53 marka Exp $
@


1.2
log
@SVN rev 222395 on 2011-05-28 00:21:28Z by dougb

Upgrade to 9.6-ESV-R4-P1, which address the following issues:

1. Very large RRSIG RRsets included in a negative cache can trigger
an assertion failure that will crash named (BIND 9 DNS) due to an
off-by-one error in a buffer size check.

This bug affects all resolving name servers, whether DNSSEC validation
is enabled or not, on all BIND versions prior to today. There is a
possibility of malicious exploitation of this bug by remote users.

2. Named could fail to validate zones listed in a DLV that validated
insecure without using DLV and had DS records in the parent zone.

Add a patch provided by ru@@ and confirmed by ISC to fix a crash at
shutdown time when a SIG(0) key is being used.
@
text
@d84 1
a84 1
$Id: dnssec,v 1.19 2004-03-05 05:04:53 marka Exp $
@


1.2.2.1
log
@SVN rev 234010 on 2012-04-08 01:43:41Z by dougb

MFC r233909:

Add Bv9ARM.pdf to the list of docs to install.

MFV/MFC r233914:

Update to version 9.8.2, the latest from ISC, which contains numerous bug fixes.
@
text
@d84 1
a84 1
$Id: dnssec,v 1.19 2004/03/05 05:04:53 marka Exp $
@


1.1
log
@Initial revision
@
text
@d84 1
a84 1
$Id: dnssec,v 1.14.2.6.4.4 2004/03/08 09:04:25 marka Exp $
@


1.1.1.1
log
@Vender import of BIND 9.3.0rc4.
@
text
@@


1.1.1.1.4.1
log
@SVN rev 179502 on 2008-06-03 05:38:10Z by dougb

Update to version 9.3.5. It contains the latest bug fixes, updates
to root server addresses, and a fix for the vulnerability mentioned
here: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0122

Users of BIND 9.3.x are strongly encouraged to upgrade to this
version. Also, the 9.3.x branch is now in maintenance-only mode.
Users are encouraged to investigate BIND 9.4.x or perhaps 9.5.x.

http://www.isc.org/index.pl?/sw/bind/versions_and_support.php

This udpate is being done by updating the files directly in this
branch rather than an import + MFC because BIND in HEAD is 9.4.x.
@
text
@d1 2
a2 2
Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
Copyright (C) 2000-2003  Internet Software Consortium.
d84 1
a84 1
$Id: dnssec,v 1.14.2.6.4.6 2007/01/18 00:06:08 marka Exp $
@


1.1.1.2
log
@Vendor import of BIND 9.4.1
@
text
@d84 1
a84 1
$Id: dnssec,v 1.19 2004/03/05 05:04:53 marka Exp $
@


1.1.1.2.2.1
log
@SVN rev 222399 on 2011-05-28 00:58:19Z by dougb

Upgrade to 9.4-ESV-R4-P1, which addresses the following issues:

1. Very large RRSIG RRsets included in a negative cache can trigger
an assertion failure that will crash named (BIND 9 DNS) due to an
off-by-one error in a buffer size check.

This bug affects all resolving name servers, whether DNSSEC validation
is enabled or not, on all BIND versions prior to today. There is a
possibility of malicious exploitation of this bug by remote users.

2. Named could fail to validate zones listed in a DLV that validated
insecure without using DLV and had DS records in the parent zone.
@
text
@d84 1
a84 1
$Id: dnssec,v 1.19 2004-03-05 05:04:53 marka Exp $
@


1.1.1.2.10.1
log
@SVN rev 222396 on 2011-05-28 00:33:06Z by dougb

Upgrade to 9.6-ESV-R4-P1, which address the following issues:

1. Very large RRSIG RRsets included in a negative cache can trigger
an assertion failure that will crash named (BIND 9 DNS) due to an
off-by-one error in a buffer size check.

This bug affects all resolving name servers, whether DNSSEC validation
is enabled or not, on all BIND versions prior to today. There is a
possibility of malicious exploitation of this bug by remote users.

2. Named could fail to validate zones listed in a DLV that validated
insecure without using DLV and had DS records in the parent zone.

Add a patch provided by ru@@ and confirmed by ISC to fix a crash at
shutdown time when a SIG(0) key is being used.
@
text
@d84 1
a84 1
$Id: dnssec,v 1.19 2004-03-05 05:04:53 marka Exp $
@


1.1.1.2.10.2
log
@SVN rev 233915 on 2012-04-05 04:31:17Z by dougb

Update to version 9.6-ESV-R6, the latest from ISC, which contains numerous
bug fixes.
@
text
@d84 1
a84 1
$Id: dnssec,v 1.19 2004/03/05 05:04:53 marka Exp $
@


1.1.1.1.2.1
log
@MFC: BIND 9 and related bits.

Approved by:	re
@
text
@@

