Ready for 7.4-RELEASE builds to start.

Approved by:	re (implicit)

COPYRIGHT

@@ -4,7 +4,7 @@
 The compilation of software known as FreeBSD is distributed under the
 following terms:
 
-Copyright (c) 1992-2010 The FreeBSD Project. All rights reserved.
+Copyright (c) 1992-2011 The FreeBSD Project. All rights reserved.
 
 Redistribution and use in source and binary forms, with or without
 modification, are permitted provided that the following conditions

Makefile

@@ -295,6 +295,7 @@ universe_${target}:
 	    "check _.${target}.buildworld for details")
 	@echo ">> ${target} buildworld completed on `LC_ALL=C date`"
 .endif
+.if !defined(MAKE_JUST_WORLDS)
 .if exists(${.CURDIR}/sys/${target}/conf/NOTES)
 	@(cd ${.CURDIR}/sys/${target}/conf && env __MAKE_CONF=/dev/null \
 	    ${MAKE} LINT > ${.CURDIR}/_.${target}.makeLINT 2>&1 || \
@@ -310,6 +311,7 @@ universe_${target}:
 	    echo "${target} ${kernel} kernel failed," \
 	    "check _.${target}.${kernel} for details")
 .endfor
+.endif
 	@echo ">> ${target} completed on `LC_ALL=C date`"
 .endfor
 universe: universe_epilogue

Makefile.inc1

@@ -88,7 +88,7 @@ CLEANDIR=	cleandir
 .endif
 
 CVS?=		cvs
-CVSFLAGS?=	-r RELENG_7_3 -P -d -I!
+CVSFLAGS?=	-r RELENG_7_4 -P -d -I!
 SUP?=		/usr/bin/csup
 SUPFLAGS?=	-g -L 2
 .if defined(SUPHOST)
@@ -263,6 +263,7 @@ LIB32WMAKEENV=	MAKEOBJDIRPREFIX=${OBJTREE}/lib32 \
 		VERSION="${VERSION}" \
 		MACHINE=i386 \
 		MACHINE_ARCH=i386 \
+		MACHINE_CPU="i686 mmx sse sse2" \
 		INSTALL="sh ${.CURDIR}/tools/install.sh" \
 		PATH=${TMPPATH} \
 		CC="${CC} ${LIB32FLAGS}" \

ObsoleteFiles.inc

@@ -14,6 +14,12 @@
 # The file is partitioned: OLD_FILES first, then OLD_LIBS and OLD_DIRS last.
 #
 
+# 20101114: Remove long-obsolete MAKEDEV.8
+OLD_FILES+=usr/share/man/man8/MAKEDEV.8.gz
+# 20101112: vgonel(9) has gone to private API a while ago
+OLD_FILES+=usr/share/man/man9/vgonel.9.gz
+# 20101025: catch up with vm_page_sleep_if_busy rename
+OLD_FILES+=usr/share/man/man9/vm_page_sleep_busy.9.gz
 # 20091129: pecoff image activator removed
 .if ${TARGET_ARCH} == "i386"
 OLD_FILES+=usr/include/machine/pecoff_machdep.h

UPDATING

@@ -8,57 +8,14 @@ Items affecting the ports and packages system can be found in
 /usr/ports/UPDATING.  Please read that file before running
 portupgrade.
 
-20120104:	p10	FreeBSD-EN-12:01.freebsd-update
-	Extend the character set accepted by freebsd-update(8) in file
-	names in order to allow upgrades to FreeBSD 9.0-RELEASE.
+20110221:
+	FreeBSD 7.4-RELEASE
 
-20111223:	p9	FreeBSD-SA-11:06.bind, FreeBSD-SA-11:07.chroot
-			FreeBSD-SA-11:08.telnetd, FreeBSD-SA-11:09.pam_ssh
-			FreeBSD-SA-11:10.pam
-	Fix a problem whereby a corrupt DNS record can cause named to crash.
-	[11:06]
-
-	Add an API for alerting internal libc routines to the presence of
-	"unsafe" paths post-chroot, and use it in ftpd. [11:07]
-
-	Fix a buffer overflow in telnetd. [11:08]
-
-	Make pam_ssh ignore unpassphrased keys unless the "nullok" option is
-	specified. [11:09]
-
-	Add sanity checking of service names in pam_start. [11:10]
-
-20111004:	p8	FreeBSD-SA-11:05.unix (revised)
-	Fix a bug in UNIX socket handling in the linux emulator which was
-	exposed by the security fix in FreeBSD-SA-11:05.unix.
-
-20110928:	p7	FreeBSD-SA-11:04.compress, FreeBSD-SA-11:05.unix
-	Fix handling of corrupt compress(1)ed data. [11:04]
-
-	Add missing length checks on unix socket addresses. [11:05]
-
-20110528:	p6	FreeBSD-SA-11:02.bind
-	Fix BIND remote DoS with large RRSIG RRsets and negative
-	caching.
-
-20110420:	p5	FreeBSD-SA-11:01.mountd
-	Fix CIDR parsing bug in mountd ACLs.
-
-20101129:	p4	FreeBSD-SA-10:10.openssl
-	Fix OpenSSL multiple vulnerabilities.
-
-20100920:	p3	FreeBSD-SA-10:08.bzip2
-	Fix an integer overflow in RLE length parsing when decompressing
-	corrupt bzip2 data.
-
-20100713:	p2	FreeBSD-SA-10:07.mbuf
-	Correctly copy the M_RDONLY flag when duplicating a reference
-	to an mbuf external buffer.
-
-20100526:	p1	FreeBSD-SA-10:05.opie, FreeBSD-SA-10:06.nfsclient
-	Fix a one-NUL-byte buffer overflow in libopie. [10:05]
-
-	Correctly sanity-check a buffer length in nfs mount. [10:06]
+20101126:
+	New version of minidump format for amd64 architecture was
+	introduced in r215874.  To analyze vmcore files produced by
+	kernels at or after this version you will need updated userland,
+	libkvm actually, that is able to handle the new version.
 
 20100323:
 	FreeBSD 7.3-RELEASE

bin/chio/chio.c

@@ -1072,6 +1072,7 @@ find_element(char *voltag, uint16_t *et, uint16_t *eu)
 
 	/* Read in the changer slots */
 	if (cp.cp_nslots > 0) {
+		(void) memset(&cesr, 0, sizeof(cesr));
 		cesr.cesr_element_type = CHET_ST;
 		cesr.cesr_element_base = 0;
 		cesr.cesr_element_count = cp.cp_nslots;

bin/cp/cp.1

@@ -32,7 +32,7 @@
 .\"	@(#)cp.1	8.3 (Berkeley) 4/18/94
 .\" $FreeBSD$
 .\"
-.Dd October 27, 2006
+.Dd January 17, 2010
 .Dt CP 1
 .Os
 .Sh NAME
@@ -45,7 +45,7 @@
 .Op Fl H | Fl L | Fl P
 .Oc
 .Op Fl f | i | n
-.Op Fl alpv
+.Op Fl alpvx
 .Ar source_file target_file
 .Nm
 .Oo
@@ -53,7 +53,7 @@
 .Op Fl H | Fl L | Fl P
 .Oc
 .Op Fl f | i | n
-.Op Fl alpv
+.Op Fl alpvx
 .Ar source_file ... target_directory
 .Sh DESCRIPTION
 In the first synopsis form, the
@@ -183,6 +183,8 @@ permissions.
 Cause
 .Nm
 to be verbose, showing files as they are copied.
+.It Fl x
+File system mount points are not traversed.
 .El
 .Pp
 For each destination file that already exists, its contents are

bin/cp/cp.c

@@ -101,8 +101,9 @@ main(int argc, char *argv[])
 	int Hflag, Lflag, Pflag, ch, fts_options, r, have_trailing_slash;
 	char *target;
 
+	fts_options = FTS_NOCHDIR | FTS_PHYSICAL;
 	Hflag = Lflag = Pflag = 0;
-	while ((ch = getopt(argc, argv, "HLPRafilnprv")) != -1)
+	while ((ch = getopt(argc, argv, "HLPRafilnprvx")) != -1)
 		switch (ch) {
 		case 'H':
 			Hflag = 1;
@@ -150,6 +151,9 @@ main(int argc, char *argv[])
 		case 'v':
 			vflag = 1;
 			break;
+		case 'x':
+			fts_options |= FTS_XDEV;
+			break;
 		default:
 			usage();
 			break;
@@ -160,7 +164,6 @@ main(int argc, char *argv[])
 	if (argc < 2)
 		usage();
 
-	fts_options = FTS_NOCHDIR | FTS_PHYSICAL;
 	if (Rflag && rflag)
 		errx(1, "the -R and -r options may not be specified together");
 	if (rflag)

bin/cp/utils.c

@@ -429,8 +429,8 @@ usage(void)
 {
 
 	(void)fprintf(stderr, "%s\n%s\n",
-"usage: cp [-R [-H | -L | -P]] [-f | -i | -n] [-alpv] source_file target_file",
-"       cp [-R [-H | -L | -P]] [-f | -i | -n] [-alpv] source_file ... "
+"usage: cp [-R [-H | -L | -P]] [-f | -i | -n] [-alpvx] source_file target_file",
+"       cp [-R [-H | -L | -P]] [-f | -i | -n] [-alpvx] source_file ... "
 "target_directory");
 	exit(EX_USAGE);
 }

bin/echo/echo.1

@@ -32,7 +32,7 @@
 .\"	@(#)echo.1	8.1 (Berkeley) 7/22/93
 .\" $FreeBSD$
 .\"
-.Dd April 12, 2003
+.Dd November 12, 2010
 .Dt ECHO 1
 .Os
 .Sh NAME
@@ -56,24 +56,37 @@ The following option is available:
 .Bl -tag -width flag
 .It Fl n
 Do not print the trailing newline character.
-This may also be achieved by appending
+.El
+.Pp
+The end-of-options marker
+.Fl Fl
+is not recognized and written literally.
+.Pp
+The newline may also be suppressed by appending
 .Ql \ec
 to the end of the string, as is done
 by iBCS2 compatible systems.
-Note that this option as well as the effect of
+Note that the
+.Fl n
+option as well as the effect of
 .Ql \ec
 are implementation-defined in
 .St -p1003.1-2001
 as amended by Cor.\& 1-2002.
-Applications aiming for maximum
-portability are strongly encouraged to use
-.Xr printf 1
-to suppress the newline character.
-.El
-.Pp
-Some shells may provide a builtin
+For portability,
 .Nm
-command which is similar or identical to this utility.
+should only be used if the first argument does not start with a hyphen
+.Pq Ql "-"
+and does not contain any backslashes
+.Pq Ql "\e" .
+If this is not sufficient,
+.Xr printf 1
+should be used.
+.Pp
+Most shells provide a builtin
+.Nm
+command which tends to differ from this utility
+in the treatment of options and backslashes.
 Consult the
 .Xr builtin 1
 manual page.

bin/expr/expr.1

@@ -30,7 +30,7 @@
 .\"
 .\" $FreeBSD$
 .\"
-.Dd July 12, 2004
+.Dd September 9, 2010
 .Dt EXPR 1
 .Os
 .Sh NAME
@@ -217,6 +217,9 @@ command, one might rearrange the expression:
 More generally, parenthesize possibly-negative values:
 .Dl "a=$(expr \e( $a \e) + 1)"
 .It
+With shell arithmetic, no escaping is required:
+.Dl "a=$((a + 1))"
+.It
 This example prints the filename portion of a pathname stored
 in variable
 .Va a .
@@ -229,6 +232,12 @@ The
 .Li //
 characters resolve this ambiguity.
 .Dl "expr \*q//$a\*q \&: '.*/\e(.*\e)'"
+.It
+With modern
+.Xr sh 1
+syntax,
+.Dl "\*q${a##*/}\*q"
+expands to the same value.
 .El
 .Pp
 The following examples output the number of characters in variable
@@ -237,19 +246,21 @@ Again, if
 .Va a
 might begin with a hyphen, it is necessary to prevent it from being
 interpreted as an option to
-.Nm .
+.Nm ,
+and
+.Va a
+might be interpreted as an operator.
 .Bl -bullet
 .It
-If the
-.Nm
-command conforms to
-.St -p1003.1-2001 ,
-this is simple:
-.Dl "expr -- \*q$a\*q \&: \*q.*\*q"
-.It
-For portability to older systems, however, a more complicated command
+To deal with all of this, a complicated command
 is required:
 .Dl "expr \e( \*qX$a\*q \&: \*q.*\*q \e) - 1"
+.It
+With modern
+.Xr sh 1
+syntax, this can be done much more easily:
+.Dl "${#a}"
+expands to the required number.
 .El
 .Sh SEE ALSO
 .Xr sh 1 ,

bin/kill/kill.c

@@ -108,7 +108,7 @@ main(int argc, char *argv[])
 			numsig = strtol(*argv, &ep, 10);
 			if (!**argv || *ep)
 				errx(1, "illegal signal number: %s", *argv);
-			if (numsig < 0 || numsig >= sys_nsig)
+			if (numsig < 0)
 				nosig(*argv);
 		} else
 			nosig(*argv);

bin/ln/symlink.7

@@ -29,7 +29,7 @@
 .\"	@(#)symlink.7	8.3 (Berkeley) 3/31/94
 .\" $FreeBSD$
 .\"
-.Dd March 31, 1994
+.Dd April 25, 2010
 .Dt SYMLINK 7
 .Os
 .Sh NAME
@@ -138,8 +138,8 @@ an existing symbolic link can be changed by means of the
 and
 .Xr lutimes 2
 system calls, respectively.
-Of these, only the flags are used by the system;
-the access permissions and ownership are ignored.
+Of these, only the flags and ownership are used by the system;
+the access permissions are ignored.
 .Pp
 The
 .Bx 4.4

bin/ls/ls.c

@@ -504,7 +504,7 @@ traverse(int argc, char *argv[], int options)
 			break;
 		case FTS_DNR:
 		case FTS_ERR:
-			warnx("%s: %s", p->fts_name, strerror(p->fts_errno));
+			warnx("%s: %s", p->fts_path, strerror(p->fts_errno));
 			rval = 1;
 			break;
 		case FTS_D:

bin/pax/Makefile

@@ -29,9 +29,6 @@ PROG=   pax
 SRCS=	ar_io.c ar_subs.c buf_subs.c cache.c cpio.c file_subs.c ftree.c \
 	gen_subs.c getoldopt.c options.c pat_rep.c pax.c sel_subs.c \
 	tables.c tar.c tty_subs.c
-#XXX NOTYET
-#MAN=	pax.1 tar.1 cpio.1
-#LINKS=	${BINDIR}/pax ${BINDIR}/tar ${BINDIR}/pax ${BINDIR}/cpio
 
 .if ${MACHINE_ARCH} == "arm"
 WARNS?=	3

bin/pax/cpio.1

@@ -1,304 +0,0 @@
-.\"-
-.\" Copyright (c) 1997 SigmaSoft, Th. Lockert
-.\" All rights reserved.
-.\"
-.\" Redistribution and use in source and binary forms, with or without
-.\" modification, are permitted provided that the following conditions
-.\" are met:
-.\" 1. Redistributions of source code must retain the above copyright
-.\"    notice, this list of conditions and the following disclaimer.
-.\" 2. Redistributions in binary form must reproduce the above copyright
-.\"    notice, this list of conditions and the following disclaimer in the
-.\"    documentation and/or other materials provided with the distribution.
-.\" 3. All advertising materials mentioning features or use of this software
-.\"    must display the following acknowledgement:
-.\"      This product includes software developed by SigmaSoft, Th. Lockert.
-.\" 4. The name of the author may not be used to endorse or promote products
-.\"    derived from this software without specific prior written permission
-.\"
-.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
-.\" IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
-.\" OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
-.\" IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
-.\" INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
-.\" NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
-.\" DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
-.\" THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
-.\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
-.\" THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-.\"
-.\"	$OpenBSD: cpio.1,v 1.16 2001/05/01 17:58:01 aaron Exp $
-.\" $FreeBSD$
-.\"
-.Dd February 16, 1997
-.Dt CPIO 1
-.Os
-.Sh NAME
-.Nm cpio
-.Nd copy file archives in and out
-.Sh SYNOPSIS
-.Nm
-.Fl o
-.Op Fl aABcLvzZ
-.Op Fl C Ar bytes
-.Op Fl F Ar archive
-.Op Fl H Ar format
-.Op Fl O Ar archive
-.No < Ar name-list
-.Op No > Ar archive
-.Nm
-.Fl i
-.Op Fl bBcdfmrsStuvzZ6
-.Op Fl C Ar bytes
-.Op Fl E Ar file
-.Op Fl F Ar archive
-.Op Fl H Ar format
-.Op Fl I Ar archive
-.Op Ar pattern ...
-.Op No < Ar archive
-.Nm
-.Fl p
-.Op Fl adlLmuv
-.Ar destination-directory
-.No < Ar name-list
-.Sh DESCRIPTION
-The
-.Nm
-command copies files to and from a
-.Nm
-archive.
-.Pp
-The options are as follows:
-.Bl -tag -width indent
-.It Fl o
-Create an archive.
-Reads the list of files to store in the
-archive from standard input, and writes the archive on standard
-output.
-.Bl -tag -width indent
-.It Fl a
-Reset the access times on files that have been copied to the
-archive.
-.It Fl A
-Append to the specified archive.
-.It Fl B
-Set block size of output to 5120 bytes.
-.It Fl c
-Use
-.Tn ASCII
-format for
-.Nm
-header for portability.
-.It Fl C Ar bytes
-Set the block size of output to
-.Ar bytes .
-.It Fl F Ar archive
-.It Fl O Ar archive
-Use the specified file name as the archive to write to.
-.It Fl H Ar format
-Write the archive in the specified format.
-Recognized formats are:
-.Pp
-.Bl -tag -width sv4cpio -compact
-.It Cm bcpio
-Old binary
-.Nm
-format.
-.It Cm cpio
-Old octal character
-.Nm
-format.
-.It Cm sv4cpio
-.Tn SVR4
-hex
-.Nm
-format.
-.It Cm tar
-Old tar format.
-.It Cm ustar
-.Tn POSIX
-ustar format.
-.El
-.It Fl L
-Follow symbolic links.
-.It Fl v
-Be verbose about operations.
-List filenames as they are written to the archive.
-.It Fl z
-Compress archive using
-.Xr gzip 1
-format.
-.It Fl Z
-Compress archive using
-.Xr compress 1
-format.
-.El
-.It Fl i
-Restore files from an archive.
-Reads the archive file from
-standard input and extracts files matching the
-.Ar patterns
-that were specified on the command line.
-.Bl -tag -width indent
-.It Fl b
-Do byte and word swapping after reading in data from the
-archive, for restoring archives created on systems with
-a different byte order.
-.It Fl B
-Set the block size of the archive being read to 5120 bytes.
-.It Fl c
-Expect the archive headers to be in
-.Tn ASCII
-format.
-.It Fl C Ar bytes
-Read archive written with a block size of
-.Ar bytes .
-.It Fl d
-Create any intermediate directories as needed during
-restore.
-.It Fl E Ar file
-Read list of file name patterns to extract or list from
-.Ar file .
-.It Fl f
-Restore all files except those matching the
-.Ar patterns
-given on the command line.
-.It Fl F Ar archive , Fl I Ar archive
-Use the specified file as the input for the archive.
-.It Fl H Ar format
-Read an archive of the specified format.
-Recognized formats are:
-.Pp
-.Bl -tag -width sv4cpio -compact
-.It Cm bcpio
-Old binary
-.Nm
-format.
-.It Cm cpio
-Old octal character
-.Nm
-format.
-.It Cm sv4cpio
-.Tn SVR4
-hex
-.Nm
-format.
-.It Cm tar
-Old tar format.
-.It Cm ustar
-.Tn POSIX
-ustar format.
-.El
-.It Fl m
-Restore modification times on files.
-.It Fl r
-Rename restored files interactively.
-.It Fl s
-Swap bytes after reading data from the archive.
-.It Fl S
-Swap words after reading data from the archive.
-.It Fl t
-Only list the contents of the archive, no files or
-directories will be created.
-.It Fl u
-Overwrite files even when the file in the archive is
-older than the one that will be overwritten.
-.It Fl v
-Be verbose about operations.
-List filenames as they are copied in from the archive.
-.It Fl z
-Uncompress archive using
-.Xr gzip 1
-format.
-.It Fl Z
-Uncompress archive using
-.Xr compress 1
-format.
-.It Fl 6
-Process old-style
-.Nm
-format archives.
-.El
-.It Fl p
-Copy files from one location to another in a single pass.
-The list of files to copy are read from standard input and
-written out to a directory relative to the specified
-.Ar directory
-argument.
-.Bl -tag -width indent
-.It Fl a
-Reset the access times on files that have been copied.
-.It Fl d
-Create any intermediate directories as needed to write
-the files at the new location.
-.It Fl l
-When possible, link files rather than creating an
-extra copy.
-.It Fl L
-Follow symbolic links.
-.It Fl m
-Restore modification times on files.
-.It Fl u
-Overwrite files even when the original file being copied is
-older than the one that will be overwritten.
-.It Fl v
-Be verbose about operations.
-List filenames as they are copied.
-.El
-.El
-.Sh ENVIRONMENT
-.Bl -tag -width TMPDIR
-.It Ev TMPDIR
-Path in which to store temporary files.
-.El
-.Sh EXIT STATUS
-The
-.Nm
-utility will exit with one of the following values:
-.Bl -tag -width 2n
-.It 0
-All files were processed successfully.
-.It 1
-An error occurred.
-.El
-.Pp
-Whenever
-.Nm
-cannot create a file or a link when extracting an archive or cannot
-find a file while writing an archive, or cannot preserve the user
-ID, group ID, file mode, or access and modification times when the
-.Fl p
-option is specified, a diagnostic message is written to standard
-error and a non-zero exit value will be returned, but processing
-will continue.
-In the case where
-.Nm
-cannot create a link to a file,
-.Nm
-will not create a second copy of the file.
-.Pp
-If the extraction of a file from an archive is prematurely terminated
-by a signal or error,
-.Nm
-may have only partially extracted the file the user wanted.
-Additionally, the file modes of extracted files and directories may
-have incorrect file bits, and the modification and access times may
-be wrong.
-.Pp
-If the creation of an archive is prematurely terminated by a signal
-or error,
-.Nm
-may have only partially created the archive which may violate the
-specific archive format specification.
-.Sh SEE ALSO
-.Xr pax 1 ,
-.Xr tar 1
-.Sh AUTHORS
-.An Keith Muller
-at the University of California, San Diego.
-.Sh BUGS
-The
-.Fl s
-and
-.Fl S
-options are currently not implemented.

bin/pax/pax.1

@@ -33,7 +33,7 @@
 .\"	@(#)pax.1	8.4 (Berkeley) 4/18/94
 .\" $FreeBSD$
 .\"
-.Dd July 3, 2004
+.Dd August 29, 2010
 .Dt PAX 1
 .Os
 .Sh NAME
@@ -748,7 +748,9 @@ The extended tar interchange format specified in the
 .St -p1003.2
 standard.
 The default blocksize for this format is 10240 bytes.
-Pathnames stored by this format must be 250 characters or less in length.
+Pathnames stored by this format must be 255 characters or less in length.
+The directory part may be at most 155 characters and each path component
+must be less than 100 characters.
 .El
 .Pp
 The

bin/pax/tar.1

@@ -1,310 +0,0 @@
-.\"-
-.\" Copyright (c) 1996 SigmaSoft, Th. Lockert
-.\" All rights reserved.
-.\"
-.\" Redistribution and use in source and binary forms, with or without
-.\" modification, are permitted provided that the following conditions
-.\" are met:
-.\" 1. Redistributions of source code must retain the above copyright
-.\"    notice, this list of conditions and the following disclaimer.
-.\" 2. Redistributions in binary form must reproduce the above copyright
-.\"    notice, this list of conditions and the following disclaimer in the
-.\"    documentation and/or other materials provided with the distribution.
-.\" 3. All advertising materials mentioning features or use of this software
-.\"    must display the following acknowledgement:
-.\"      This product includes software developed by SigmaSoft, Th. Lockert.
-.\" 4. The name of the author may not be used to endorse or promote products
-.\"    derived from this software without specific prior written permission
-.\"
-.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
-.\" IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
-.\" OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
-.\" IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
-.\" INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
-.\" NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
-.\" DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
-.\" THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
-.\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
-.\" THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-.\"
-.\"	$OpenBSD: tar.1,v 1.33 2001/05/01 17:58:01 aaron Exp $
-.\" $FreeBSD$
-.\"
-.Dd February 7, 2001
-.Dt TAR 1
-.Os
-.Sh NAME
-.Nm tar
-.Nd tape archiver
-.Sh SYNOPSIS
-.Nm
-.Sm off
-.Op Fl
-.Brq Cm crtux
-.Op Cm befhjmopqsvwyzHLOPXZ014578
-.Sm on
-.Op Ar blocksize
-.Op Ar archive
-.Op Ar replstr
-.\" XXX how to do this right?
-.Op Fl C Ar directory
-.Op Fl I Ar file
-.Op Ar
-.Sh DESCRIPTION
-The
-.Nm
-command creates, adds files to, or extracts files from an
-archive file in
-.Nm
-format.
-A
-.Nm
-archive is often stored on a magnetic tape, but can be
-stored equally well on a floppy, CD-ROM, or in a regular disk file.
-.Pp
-One of the following flags must be present:
-.Bl -tag -width indent
-.It Fl c
-Create new archive, or overwrite an existing archive,
-adding the specified files to it.
-.It Fl r
-Append the named new files to existing archive.
-Note that this will only work on media on which an end-of-file mark
-can be overwritten.
-.It Fl t
-List contents of archive.
-If any files are named on the
-command line, only those files will be listed.
-.It Fl u
-Alias for
-.Fl r .
-.It Fl x
-Extract files from archive.
-If any files are named on the
-command line, only those files will be extracted from the
-archive.
-If more than one copy of a file exists in the
-archive, later copies will overwrite earlier copies during
-extraction.
-The file mode and modification time are preserved
-if possible.
-The file mode is subject to modification by the
-.Xr umask 2 .
-.El
-.Pp
-In addition to the flags mentioned above, any of the following
-flags may be used:
-.Bl -tag -width indent
-.It Fl b Ar "blocking factor"
-Set blocking factor to use for the archive, with 512 byte blocks.
-The default is 20, the maximum is 126.
-Archives with a blocking factor larger 63 violate the
-.Tn POSIX
-standard and will not be portable to all systems.
-.It Fl e
-Stop after first error.
-.It Fl f Ar archive
-Filename where the archive is stored.
-Defaults to
-.Pa /dev/sa0 .
-.It Fl h
-Follow symbolic links as if they were normal files
-or directories.
-.It Fl j
-Compress archives using
-.Xr bzip2 1 .
-.It Fl m
-Do not preserve modification time.
-.It Fl O
-Write old-style
-.Pq non- Ns Tn POSIX
-archives.
-.It Fl o
-Do not write directory information that the older (V7) style
-.Nm
-is unable to decode.
-This implies the
-.Fl O
-flag.
-.It Fl p
-Preserve user and group ID as well as file mode regardless of
-the current
-.Xr umask 2 .
-The setuid and setgid bits are only preserved if the user is
-the superuser.
-Only meaningful in conjunction with the
-.Fl x
-flag.
-.It Fl q
-Select the first archive member that matches each
-.Ar pattern
-operand.
-No more than one archive member is matched for each
-.Ar pattern .
-When members of type directory are matched, the file hierarchy rooted at that
-directory is also matched.
-.It Fl s Ar replstr
-Modify the file or archive member names specified by the
-.Ar pattern
-or
-.Ar file
-operands according to the substitution expression
-.Ar replstr ,
-using the syntax of the
-.Xr ed 1
-utility regular expressions.
-The format of these regular expressions are:
-.Dl /old/new/[gp]
-As in
-.Xr ed 1 ,
-.Cm old
-is a basic regular expression and
-.Cm new
-can contain an ampersand
-.Pq Ql & ,
-.Li \e Ns Ar n
-(where
-.Ar n
-is a digit) back-references,
-or subexpression matching.
-The
-.Cm old
-string may also contain newline characters.
-Any non-null character can be used as a delimiter
-.Ql ( /
-is shown here).
-Multiple
-.Fl s
-expressions can be specified.
-The expressions are applied in the order they are specified on the
-command line, terminating with the first successful substitution.
-The optional trailing
-.Cm g
-continues to apply the substitution expression to the pathname substring
-which starts with the first character following the end of the last successful
-substitution.
-The first unsuccessful substitution stops the operation of the
-.Cm g
-option.
-The optional trailing
-.Cm p
-will cause the final result of a successful substitution to be written to
-standard error
-in the following format:
-.Pp
-.Dl <original pathname> >> <new pathname>
-.Pp
-File or archive member names that substitute to the empty string
-are not selected and will be skipped.
-.It Fl v
-Verbose operation mode.
-.It Fl w
-Interactively rename files.
-This option causes
-.Nm
-to prompt the user for the filename to use when storing or
-extracting files in an archive.
-.It Fl y
-Compress archives using
-.Xr bzip2 1 .
-.It Fl z
-Compress archive using
-.Xr gzip 1 .
-.It Fl C Ar directory
-This is a positional argument which sets the working directory for the
-following files.
-When extracting, files will be extracted into
-the specified directory; when creating, the specified files will be matched
-from the directory.
-.It Fl H
-Follow symlinks given on command line only.
-.It Fl L
-Follow all symlinks.
-.It Fl P
-Do not strip leading slashes
-.Pq Ql /
-from pathnames.
-The default is to strip leading slashes.
-.It Fl I Ar file
-This is a positional argument which reads the names of files to
-archive or extract from the given file, one per line.
-.It Fl X
-Do not cross mount points in the file system.
-.It Fl Z
-Compress archive using
-.Xr compress 1 .
-.El
-.Pp
-The options
-.Op Fl 014578
-can be used to select one of the compiled-in backup devices,
-.Pa /dev/rst Ns Ar N .
-.Sh ENVIRONMENT
-.Bl -tag -width TMPDIR
-.It Ev TMPDIR
-Path in which to store temporary files.
-.It Ev TAPE
-Default tape device to use instead of
-.Pa /dev/sa0 .
-.El
-.Sh FILES
-.Bl -tag -width "/dev/sa0"
-.It Pa /dev/sa0
-default archive name
-.El
-.Sh EXIT STATUS
-The
-.Nm
-utility will exit with one of the following values:
-.Bl -tag -width 2n
-.It 0
-All files were processed successfully.
-.It 1
-An error occurred.
-.El
-.Pp
-Whenever
-.Nm
-cannot create a file or a link when extracting an archive or cannot
-find a file while writing an archive, or cannot preserve the user
-ID, group ID, file mode, or access and modification times when the
-.Fl p
-option is specified, a diagnostic message is written to standard
-error and a non-zero exit value will be returned, but processing
-will continue.
-In the case where
-.Nm
-cannot create a link to a file,
-.Nm
-will not create a second copy of the file.
-.Pp
-If the extraction of a file from an archive is prematurely terminated
-by a signal or error,
-.Nm
-may have only partially extracted the file the user wanted.
-Additionally, the file modes of extracted files and directories may
-have incorrect file bits, and the modification and access times may
-be wrong.
-.Pp
-If the creation of an archive is prematurely terminated by a signal
-or error,
-.Nm
-may have only partially created the archive which may violate the
-specific archive format specification.
-.Sh COMPATIBILITY
-The
-.Fl L
-flag is not portable to other versions of
-.Nm
-where it may have a different meaning.
-.Sh SEE ALSO
-.Xr cpio 1 ,
-.Xr pax 1
-.Sh HISTORY
-A
-.Nm
-command first appeared in
-.At v7 .
-.Sh AUTHORS
-.An Keith Muller
-at the University of California, San Diego.

bin/pax/tar.c

@@ -1086,7 +1086,7 @@ name_split(char *name, int len)
 	 */
 	if (len <= TNMSZ)
 		return(name);
-	if (len > (TPFSZ + TNMSZ + 1))
+	if (len > TPFSZ + TNMSZ)
 		return(NULL);
 
 	/*
@@ -1095,7 +1095,7 @@ name_split(char *name, int len)
 	 * to find the biggest piece to fit in the name field (or the smallest
 	 * prefix we can find)
 	 */
-	start = name + len - TNMSZ - 1;
+	start = name + len - TNMSZ;
 	while ((*start != '\0') && (*start != '/'))
 		++start;
 

bin/ps/ps.c

@@ -212,7 +212,8 @@ main(int argc, char *argv[])
 	init_list(&sesslist, addelem_pid, sizeof(pid_t), "session id");
 	init_list(&ttylist, addelem_tty, sizeof(dev_t), "tty");
 	init_list(&uidlist, addelem_uid, sizeof(uid_t), "user");
-	memf = nlistf = _PATH_DEVNULL;
+	memf = _PATH_DEVNULL;
+	nlistf = NULL;
 	while ((ch = getopt(argc, argv, PS_ARGS)) != -1)
 		switch ((char)ch) {
 		case 'A':

bin/sh/Makefile

@@ -21,12 +21,12 @@ LDADD= -ll -ledit -ltermcap
 LFLAGS= -8	# 8-bit lex scanner for arithmetic
 CFLAGS+=-DSHELL -I. -I${.CURDIR}
 # for debug:
-# CFLAGS+= -g -DDEBUG=2
+# DEBUG_FLAGS+= -g -DDEBUG=2 -fno-inline
 WARNS?=	2
 WFORMAT=0
 
 .PATH:	${.CURDIR}/bltin \
-	${.CURDIR}/../../bin/test
+	${.CURDIR}/../test
 
 CLEANFILES+= mkinit mkinit.o mknodes mknodes.o \
 	mksyntax mksyntax.o
@@ -62,4 +62,7 @@ syntax.c syntax.h: mksyntax
 token.h: mktokens
 	sh ${.CURDIR}/mktokens
 
+regress:
+	cd ${.CURDIR}/../../tools/regression/bin/sh && ${MAKE} SH=${.OBJDIR}/sh
+
 .include <bsd.prog.mk>

bin/sh/bltin/echo.1

@@ -1,114 +0,0 @@
-.\"-
-.\" Copyright (c) 1991, 1993
-.\"	The Regents of the University of California.  All rights reserved.
-.\"
-.\" This code is derived from software contributed to Berkeley by
-.\" Kenneth Almquist.
-.\" Copyright 1989 by Kenneth Almquist
-.\"
-.\" Redistribution and use in source and binary forms, with or without
-.\" modification, are permitted provided that the following conditions
-.\" are met:
-.\" 1. Redistributions of source code must retain the above copyright
-.\"    notice, this list of conditions and the following disclaimer.
-.\" 2. Redistributions in binary form must reproduce the above copyright
-.\"    notice, this list of conditions and the following disclaimer in the
-.\"    documentation and/or other materials provided with the distribution.
-.\" 4. Neither the name of the University nor the names of its contributors
-.\"    may be used to endorse or promote products derived from this software
-.\"    without specific prior written permission.
-.\"
-.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
-.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
-.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
-.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
-.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
-.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
-.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
-.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
-.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
-.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
-.\" SUCH DAMAGE.
-.\"
-.\"	@(#)echo.1	8.2 (Berkeley) 5/4/95
-.\" $FreeBSD$
-.\"
-.Dd May 4, 1995
-.Dt ECHO 1
-.Os
-.Sh NAME
-.Nm echo
-.Nd produce message in a shell script
-.Sh SYNOPSIS
-.Nm
-.Op Fl n | Fl e
-.Ar args...
-.Sh DESCRIPTION
-The
-.Nm
-utility prints its arguments on the standard output, separated by spaces.
-Unless the
-.Fl n
-option is present, a newline is output following the arguments.
-The
-.Fl e
-option causes
-.Nm
-to treat the escape sequences specially, as described in the following
-paragraph.
-The
-.Fl e
-option is the default, and is provided solely for compatibility with
-other systems.
-Only one of the options
-.Fl n
-and
-.Fl e
-may be given.
-.Pp
-If any of the following sequences of characters is encountered during
-output, the sequence is not output.
-Instead, the specified action is
-performed:
-.Bl -tag -width indent
-.It Li \eb
-A backspace character is output.
-.It Li \ec
-Subsequent output is suppressed.
-This is normally used at the end of the
-last argument to suppress the trailing newline that
-.Nm
-would otherwise output.
-.It Li \ef
-Output a form feed.
-.It Li \en
-Output a newline character.
-.It Li \er
-Output a carriage return.
-.It Li \et
-Output a (horizontal) tab character.
-.It Li \ev
-Output a vertical tab.
-.It Li \e0 Ns Ar digits
-Output the character whose value is given by zero to three digits.
-If there are zero digits, a
-.Dv NUL
-character is output.
-.It Li \e\e
-Output a backslash.
-.El
-.Sh HINTS
-Remember that backslash is special to the shell and needs to be escaped.
-To output a message to standard error, say
-.Pp
-.D1 echo message >&2
-.Sh BUGS
-The octal character escape mechanism
-.Pq Li \e0 Ns Ar digits
-differs from the
-C language mechanism.
-.Pp
-There is no way to force
-.Nm
-to treat its arguments literally, rather than interpreting them as
-options and escape sequences.

bin/sh/cd.c

@@ -70,7 +70,7 @@ STATIC int docd(char *, int, int);
 STATIC char *getcomponent(void);
 STATIC char *findcwd(char *);
 STATIC void updatepwd(char *);
-STATIC char *getpwd2(char *, size_t);
+STATIC char *getpwd2(void);
 
 STATIC char *curdir = NULL;	/* current working directory */
 STATIC char *prevdir;		/* previous working directory */
@@ -263,10 +263,8 @@ findcwd(char *dir)
 	 * any more because we traversed a symbolic link or something
 	 * we couldn't stat().
 	 */
-	if (dir == NULL || curdir == NULL)  {
-		p = stalloc(PATH_MAX);
-		return getpwd2(p, PATH_MAX);
-	}
+	if (dir == NULL || curdir == NULL)
+		return getpwd2();
 	cdcomppath = stalloc(strlen(dir) + 1);
 	scopy(dir, cdcomppath);
 	STARTSTACKSTR(new);
@@ -313,7 +311,7 @@ updatepwd(char *dir)
 int
 pwdcmd(int argc, char **argv)
 {
-	char buf[PATH_MAX];
+	char *p;
 	int ch, phys;
 
 	optreset = 1; optind = 1; opterr = 0; /* initialize getopt */
@@ -341,9 +339,9 @@ pwdcmd(int argc, char **argv)
 		out1str(curdir);
 		out1c('\n');
 	} else {
-		if (getcwd(buf, sizeof(buf)) == NULL)
+		if ((p = getpwd2()) == NULL)
 			error(".: %s", strerror(errno));
-		out1str(buf);
+		out1str(p);
 		out1c('\n');
 	}
 
@@ -356,36 +354,45 @@ pwdcmd(int argc, char **argv)
 char *
 getpwd(void)
 {
-	char buf[PATH_MAX];
 	char *p;
 
 	if (curdir)
 		return curdir;
 
-	p = getpwd2(buf, sizeof(buf));
+	p = getpwd2();
 	if (p != NULL)
 		curdir = savestr(p);
 
 	return curdir;
 }
 
+#define MAXPWD 256
+
 /*
  * Return the current directory.
  */
 STATIC char *
-getpwd2(char *buf, size_t size)
+getpwd2(void)
 {
-	if (getcwd(buf, size) == NULL) {
-		char *pwd = getenv("PWD");
-		struct stat stdot, stpwd;
+	struct stat stdot, stpwd;
+	char *pwd;
+	int i;
 
-		if (pwd && *pwd == '/' && stat(".", &stdot) != -1 &&
-		    stat(pwd, &stpwd) != -1 &&
-		    stdot.st_dev == stpwd.st_dev &&
-		    stdot.st_ino == stpwd.st_ino) {
+	for (i = MAXPWD;; i *= 2) {
+		pwd = stalloc(i);
+		if (getcwd(pwd, i) != NULL)
 			return pwd;
-		}
-		return NULL;
+		stunalloc(pwd);
+		if (errno != ERANGE)
+			break;
 	}
-	return buf;
+
+	pwd = getenv("PWD");
+	if (pwd && *pwd == '/' && stat(".", &stdot) != -1 &&
+	    stat(pwd, &stpwd) != -1 &&
+	    stdot.st_dev == stpwd.st_dev &&
+	    stdot.st_ino == stpwd.st_ino) {
+		return pwd;
+	}
+	return NULL;
 }

bin/sh/eval.c

@@ -83,6 +83,7 @@ MKINIT int evalskip;		/* set if we are skipping commands */
 STATIC int skipcount;		/* number of levels to skip */
 MKINIT int loopnest;		/* current loop nesting level */
 int funcnest;			/* depth of function calls */
+STATIC int builtin_flags;	/* evalcommand flags for builtins */
 
 
 char *commandname;
@@ -147,7 +148,7 @@ evalcmd(int argc, char **argv)
                         STPUTC('\0', concat);
                         p = grabstackstr(concat);
                 }
-                evalstring(p);
+                evalstring(p, builtin_flags & EV_TESTED);
         }
         return exitstatus;
 }
@@ -158,7 +159,7 @@ evalcmd(int argc, char **argv)
  */
 
 void
-evalstring(char *s)
+evalstring(char *s, int flags)
 {
 	union node *n;
 	struct stackmark smark;
@@ -166,7 +167,8 @@ evalstring(char *s)
 	setstackmark(&smark);
 	setinputstring(s, 1);
 	while ((n = parsecmd(0)) != NEOF) {
-		evaltree(n, 0);
+		if (n != NULL)
+			evaltree(n, flags);
 		popstackmark(&smark);
 	}
 	popfile();
@@ -840,6 +842,7 @@ evalcommand(union node *cmd, int flags, struct backcmd *backcmd)
 		commandname = argv[0];
 		argptr = argv + 1;
 		optptr = NULL;			/* initialize nextopt */
+		builtin_flags = flags;
 		exitstatus = (*builtinfunc[cmdentry.u.index])(argc, argv);
 		flushall();
 cmddone:

bin/sh/eval.h

@@ -46,7 +46,7 @@ struct backcmd {		/* result of evalbackcmd */
 };
 
 int evalcmd(int, char **);
-void evalstring(char *);
+void evalstring(char *, int);
 union node;	/* BLETCH for ansi C */
 void evaltree(union node *, int);
 void evalbackcmd(union node *, struct backcmd *);

bin/sh/expand.c

@@ -1,6 +1,8 @@
 /*-
  * Copyright (c) 1991, 1993
  *	The Regents of the University of California.  All rights reserved.
+ * Copyright (c) 1997-2005
+ *	Herbert Xu <herbert@gondor.apana.org.au>.  All rights reserved.
  *
  * This code is derived from software contributed to Berkeley by
  * Kenneth Almquist.
@@ -137,12 +139,18 @@ expandhere(union node *arg, int fd)
 
 
 /*
- * Perform variable substitution and command substitution on an argument,
- * placing the resulting list of arguments in arglist.  If EXP_FULL is true,
- * perform splitting and file name expansion.  When arglist is NULL, perform
- * here document expansion.
+ * Perform expansions on an argument, placing the resulting list of arguments
+ * in arglist.  Parameter expansion, command substitution and arithmetic
+ * expansion are always performed; additional expansions can be requested
+ * via flag (EXP_*).
+ * The result is left in the stack string.
+ * When arglist is NULL, perform here document expansion.  A partial result
+ * may be written to herefd, which is then not included in the stack string.
+ *
+ * Caution: this function uses global state and is not reentrant.
+ * However, a new invocation after an interrupted invocation is safe
+ * and will reset the global state for the new call.
  */
-
 void
 expandarg(union node *arg, struct arglist *arglist, int flag)
 {
@@ -194,11 +202,14 @@ expandarg(union node *arg, struct arglist *arglist, int flag)
 
 
 /*
- * Perform variable and command substitution.  If EXP_FULL is set, output CTLESC
- * characters to allow for further processing.  Otherwise treat
- * $@ like $* since no splitting will be performed.
+ * Perform parameter expansion, command substitution and arithmetic
+ * expansion, and tilde expansion if requested via EXP_TILDE/EXP_VARTILDE.
+ * Processing ends at a CTLENDVAR character as well as '\0'.
+ * This is used to expand word in ${var+word} etc.
+ * If EXP_FULL, EXP_CASE or EXP_REDIR are set, keep and/or generate CTLESC
+ * characters to allow for further processing.
+ * If EXP_FULL is set, also preserve CTLQUOTEMARK characters.
  */
-
 STATIC void
 argstr(char *p, int flag)
 {
@@ -211,7 +222,7 @@ argstr(char *p, int flag)
 	for (;;) {
 		switch (c = *p++) {
 		case '\0':
-		case CTLENDVAR: /* ??? */
+		case CTLENDVAR:
 			goto breakloop;
 		case CTLQUOTEMARK:
 			/* "$@" syntax adherence hack */
@@ -261,6 +272,10 @@ argstr(char *p, int flag)
 breakloop:;
 }
 
+/*
+ * Perform tilde expansion, placing the result in the stack string and
+ * returning the next position in the input string to process.
+ */
 STATIC char *
 exptilde(char *p, int flag)
 {
@@ -361,12 +376,11 @@ expari(int flag)
 	int quotes = flag & (EXP_FULL | EXP_CASE | EXP_REDIR);
 	int quoted;
 
-
 	/*
 	 * This routine is slightly over-complicated for
 	 * efficiency.  First we make sure there is
 	 * enough space for the result, which may be bigger
-	 * than the expression if we add exponentiation.  Next we
+	 * than the expression.  Next we
 	 * scan backwards looking for the start of arithmetic.  If the
 	 * next previous character is a CTLESC character, then we
 	 * have to rescan starting from the beginning since CTLESC
@@ -405,9 +419,8 @@ expari(int flag)
 
 
 /*
- * Expand stuff in backwards quotes.
+ * Perform command substitution.
  */
-
 STATIC void
 expbackq(union node *cmd, int quoted, int flag)
 {
@@ -959,6 +972,12 @@ recordregion(int start, int end, int nulonly)
  * Break the argument string into pieces based upon IFS and add the
  * strings to the argument list.  The regions of the string to be
  * searched for IFS characters have been stored by recordregion.
+ * CTLESC characters are preserved but have little effect in this pass
+ * other than escaping CTL* characters.  In particular, they do not escape
+ * IFS characters: that should be done with the ifsregion mechanism.
+ * CTLQUOTEMARK characters are used to preserve empty quoted strings.
+ * This pass treats them as a regular character, making the string non-empty.
+ * Later, they are removed along with the other CTL* characters.
  */
 STATIC void
 ifsbreakup(char *string, struct arglist *arglist)
@@ -1046,15 +1065,14 @@ ifsbreakup(char *string, struct arglist *arglist)
 }
 
 
+STATIC char expdir[PATH_MAX];
+#define expdir_end (expdir + sizeof(expdir))
 
 /*
- * Expand shell metacharacters.  At this point, the only control characters
- * should be escapes.  The results are stored in the list exparg.
+ * Perform pathname generation and remove control characters.
+ * At this point, the only control characters should be CTLESC and CTLQUOTEMARK.
+ * The results are stored in the list exparg.
  */
-
-STATIC char *expdir;
-
-
 STATIC void
 expandmeta(struct strlist *str, int flag __unused)
 {
@@ -1076,14 +1094,7 @@ expandmeta(struct strlist *str, int flag __unused)
 		}
 		savelastp = exparg.lastp;
 		INTOFF;
-		if (expdir == NULL) {
-			int i = strlen(str->text);
-			expdir = ckmalloc(i < 2048 ? 2048 : i); /* XXX */
-		}
-
 		expmeta(expdir, str->text);
-		ckfree(expdir);
-		expdir = NULL;
 		INTON;
 		if (exparg.lastp == savelastp) {
 			/*
@@ -1122,10 +1133,11 @@ expmeta(char *enddir, char *name)
 	struct dirent *dp;
 	int atend;
 	int matchdot;
+	int esc;
 
 	metaflag = 0;
 	start = name;
-	for (p = name ; ; p++) {
+	for (p = name; esc = 0, *p; p += esc + 1) {
 		if (*p == '*' || *p == '?')
 			metaflag = 1;
 		else if (*p == '[') {
@@ -1150,12 +1162,14 @@ expmeta(char *enddir, char *name)
 			break;
 		else if (*p == CTLQUOTEMARK)
 			continue;
-		else if (*p == CTLESC)
-			p++;
-		if (*p == '/') {
-			if (metaflag)
-				break;
-			start = p + 1;
+		else {
+			if (*p == CTLESC)
+				esc++;
+			if (p[esc] == '/') {
+				if (metaflag)
+					break;
+				start = p + esc + 1;
+			}
 		}
 	}
 	if (metaflag == 0) {	/* we've reached the end of the file name */
@@ -1169,6 +1183,8 @@ expmeta(char *enddir, char *name)
 			*enddir++ = *p;
 			if (*p == '\0')
 				break;
+			if (enddir == expdir_end)
+				return;
 		}
 		if (metaflag == 0 || lstat(expdir, &statb) >= 0)
 			addfname(expdir);
@@ -1183,6 +1199,8 @@ expmeta(char *enddir, char *name)
 			if (*p == CTLESC)
 				p++;
 			*enddir++ = *p++;
+			if (enddir == expdir_end)
+				return;
 		}
 	}
 	if (enddir == expdir) {
@@ -1201,7 +1219,8 @@ expmeta(char *enddir, char *name)
 		atend = 1;
 	} else {
 		atend = 0;
-		*endname++ = '\0';
+		*endname = '\0';
+		endname += esc + 1;
 	}
 	matchdot = 0;
 	p = start;
@@ -1215,21 +1234,23 @@ expmeta(char *enddir, char *name)
 		if (dp->d_name[0] == '.' && ! matchdot)
 			continue;
 		if (patmatch(start, dp->d_name, 0)) {
-			if (atend) {
-				scopy(dp->d_name, enddir);
+			if (enddir + dp->d_namlen + 1 > expdir_end)
+				continue;
+			memcpy(enddir, dp->d_name, dp->d_namlen + 1);
+			if (atend)
 				addfname(expdir);
-			} else {
-				for (p = enddir, q = dp->d_name;
-				     (*p++ = *q++) != '\0';)
+			else {
+				if (enddir + dp->d_namlen + 2 > expdir_end)
 					continue;
-				p[-1] = '/';
-				expmeta(p, endname);
+				enddir[dp->d_namlen] = '/';
+				enddir[dp->d_namlen + 1] = '\0';
+				expmeta(enddir + dp->d_namlen + 1, endname);
 			}
 		}
 	}
 	closedir(dirp);
 	if (! atend)
-		endname[-1] = '/';
+		endname[-esc - 1] = esc ? CTLESC : '/';
 }
 
 
@@ -1451,7 +1472,7 @@ breakloop:
 
 
 /*
- * Remove any CTLESC characters from a string.
+ * Remove any CTLESC and CTLQUOTEMARK characters from a string.
  */
 
 void

bin/sh/histedit.c

@@ -350,7 +350,7 @@ histcmd(int argc, char **argv)
 				if (displayhist) {
 					out2str(s);
 				}
-				evalstring(s);
+				evalstring(s, 0);
 				if (displayhist && hist) {
 					/*
 					 *  XXX what about recursive and
@@ -382,7 +382,7 @@ histcmd(int argc, char **argv)
 		fclose(efp);
 		editcmd = stalloc(strlen(editor) + strlen(editfile) + 2);
 		sprintf(editcmd, "%s %s", editor, editfile);
-		evalstring(editcmd);	/* XXX - should use no JC command */
+		evalstring(editcmd, 0);	/* XXX - should use no JC command */
 		INTON;
 		readcmdfile(editfile);	/* XXX - should read back - quick tst */
 		unlink(editfile);
@@ -411,7 +411,7 @@ fc_replace(const char *s, char *p, char *r)
 		} else
 			STPUTC(*s++, dest);
 	}
-	STACKSTRNUL(dest);
+	STPUTC('\0', dest);
 	dest = grabstackstr(dest);
 
 	return (dest);

bin/sh/main.c

@@ -178,7 +178,7 @@ state2:
 state3:
 	state = 4;
 	if (minusc) {
-		evalstring(minusc);
+		evalstring(minusc, 0);
 	}
 	if (sflag || minusc == NULL) {
 state4:	/* XXX ??? - why isn't this before the "if" statement */

bin/sh/memalloc.c

@@ -295,6 +295,13 @@ grabstackblock(int len)
  * is space for at least one character.
  */
 
+static char *
+growstrstackblock(int n)
+{
+	growstackblock();
+	sstrnleft = stackblocksize() - n;
+	return stackblock() + n;
+}
 
 char *
 growstackstr(void)
@@ -304,12 +311,10 @@ growstackstr(void)
 	len = stackblocksize();
 	if (herefd >= 0 && len >= 1024) {
 		xwrite(herefd, stackblock(), len);
-		sstrnleft = len - 1;
+		sstrnleft = len;
 		return stackblock();
 	}
-	growstackblock();
-	sstrnleft = stackblocksize() - len - 1;
-	return stackblock() + len;
+	return growstrstackblock(len);
 }
 
 
@@ -323,9 +328,7 @@ makestrspace(void)
 	int len;
 
 	len = stackblocksize() - sstrnleft;
-	growstackblock();
-	sstrnleft = stackblocksize() - len;
-	return stackblock() + len;
+	return growstrstackblock(len);
 }
 
 

bin/sh/memalloc.h

@@ -65,9 +65,16 @@ void ungrabstackstr(char *, char *);
 #define stackblock() stacknxt
 #define stackblocksize() stacknleft
 #define STARTSTACKSTR(p)	p = stackblock(), sstrnleft = stackblocksize()
-#define STPUTC(c, p)	(--sstrnleft >= 0? (*p++ = (c)) : (p = growstackstr(), *p++ = (c)))
+#define STPUTC(c, p)	(--sstrnleft >= 0? (*p++ = (c)) : (p = growstackstr(), --sstrnleft, *p++ = (c)))
 #define CHECKSTRSPACE(n, p)	{ if (sstrnleft < n) p = makestrspace(); }
 #define USTPUTC(c, p)	(--sstrnleft, *p++ = (c))
+/*
+ * STACKSTRNUL's use is where we want to be able to turn a stack
+ * (non-sentinel, character counting string) into a C string,
+ * and later pretend the NUL is not there.
+ * Note: Because of STACKSTRNUL's semantics, STACKSTRNUL cannot be used
+ * on a stack that will grabstackstr()ed.
+ */
 #define STACKSTRNUL(p)	(sstrnleft == 0? (p = growstackstr(), *p = '\0') : (*p = '\0'))
 #define STUNPUTC(p)	(++sstrnleft, --p)
 #define STTOPC(p)	p[-1]

bin/sh/sh.1

@@ -32,7 +32,7 @@
 .\"	from: @(#)sh.1	8.6 (Berkeley) 5/4/95
 .\" $FreeBSD$
 .\"
-.Dd October 7, 2006
+.Dd October 31, 2010
 .Dt SH 1
 .Os
 .Sh NAME
@@ -40,9 +40,24 @@
 .Nd command interpreter (shell)
 .Sh SYNOPSIS
 .Nm
-.Op Fl /+abCEefIimnPpsTuVvx
+.Op Fl /+abCEefIimnPpTuVvx
 .Op Fl /+o Ar longname
-.Op Fl c Ar string
+.Oo
+.Ar script
+.Op Ar arg ...
+.Oc
+.Nm
+.Op Fl /+abCEefIimnPpTuVvx
+.Op Fl /+o Ar longname
+.Fl c Ar string
+.Oo
+.Ar name
+.Op Ar arg ...
+.Oc
+.Nm
+.Op Fl /+abCEefIimnPpTuVvx
+.Op Fl /+o Ar longname
+.Fl s
 .Op Ar arg ...
 .Sh DESCRIPTION
 The
@@ -411,11 +426,11 @@ character, with the exception of the newline character
 .Pq Ql \en .
 A backslash preceding a newline is treated as a line continuation.
 .El
-.Ss Reserved Words
-Reserved words are words that have special meaning to the
+.Ss Keywords
+Keywords or reserved words are words that have special meaning to the
 shell and are recognized at the beginning of a line and
 after a control operator.
-The following are reserved words:
+The following are keywords:
 .Bl -column "doneXX" "elifXX" "elseXX" "untilXX" "whileX" -offset center
 .It Li \&! Ta { Ta } Ta Ic case Ta Ic do
 .It Ic done Ta Ic elif Ta Ic else Ta Ic esac Ta Ic fi
@@ -425,8 +440,8 @@ The following are reserved words:
 An alias is a name and corresponding value set using the
 .Ic alias
 built-in command.
-Whenever a reserved word may occur (see above),
-and after checking for reserved words, the shell
+Whenever a keyword may occur (see above),
+and after checking for keywords, the shell
 checks the word to see if it matches an alias.
 If it does, it replaces it in the input stream with its value.
 For example, if there is an alias called
@@ -465,7 +480,7 @@ of this man page (refer to the BNF in the
 document).
 Essentially though, a line is read and if
 the first word of the line (or after a control operator)
-is not a reserved word, then the shell has recognized a
+is not a keyword, then the shell has recognized a
 simple command.
 Otherwise, a complex command or some
 other special construct may have been recognized.
@@ -685,7 +700,7 @@ Signal numbers are defined in the header file
 .In sys/signal.h .
 .Ss Complex Commands
 Complex commands are combinations of simple commands
-with control operators or reserved words, together creating a larger complex
+with control operators or keywords, together creating a larger complex
 command.
 More generally, a command is one of the following:
 .Bl -item -offset indent
@@ -726,10 +741,17 @@ both of a command is considered to be assigned by the
 pipeline before any redirection specified by redirection
 operators that are part of the command.
 .Pp
+Note that unlike some other shells,
+.Nm
+executes each process in a pipeline with more than one command
+in a subshell environment and as a child of the
+.Nm
+process.
+.Pp
 If the pipeline is not in the background (discussed later),
 the shell waits for all commands to complete.
 .Pp
-If the reserved word
+If the keyword
 .Ic !\&
 does not precede the pipeline, the
 exit status is the exit status of the last command specified
@@ -763,15 +785,6 @@ to be executed sequentially;
 an
 .Ql &
 causes asynchronous execution of the preceding AND-OR-list.
-.Pp
-Note that unlike some other shells,
-.Nm
-executes each process in the pipeline as a child of the
-.Nm
-process.
-Shell built-in commands are the exception to this rule.
-They are executed in the current shell, although they do not affect its
-environment when used in pipelines.
 .Ss Background Commands (&)
 If a command is terminated by the control operator ampersand
 .Pq Ql & ,
@@ -1101,7 +1114,12 @@ For a
 pipeline, the process ID is that of the last command in the
 pipeline.
 .It Li $0
-(zero) Expands to the name of the shell or shell script.
+(zero) Expands to the name of the shell script if passed on the command line,
+the
+.Ar name
+operand if given (with
+.Fl c )
+or otherwise argument 0 passed to the shell.
 .El
 .Ss Word Expansions
 This clause describes the various expansions that are
@@ -1142,7 +1160,7 @@ Quote Removal.
 The
 .Ql $
 character is used to introduce parameter expansion, command
-substitution, or arithmetic evaluation.
+substitution, or arithmetic expansion.
 .Ss Tilde Expansion (substituting a user's home directory)
 A word beginning with an unquoted tilde character
 .Pq Ql ~
@@ -1221,6 +1239,9 @@ In all cases, the
 final value of
 .Ar parameter
 is substituted.
+Quoting inside
+.Ar word
+does not prevent field splitting or pathname expansion.
 Only variables, not positional
 parameters or special parameters, can be
 assigned in this way.
@@ -1354,10 +1375,41 @@ The
 shell expands all tokens in the
 .Ar expression
 for parameter expansion,
-command substitution, and quote removal.
+command substitution,
+arithmetic expansion
+and quote removal.
 .Pp
-Next, the shell treats this as an arithmetic expression and
-substitutes the value of the expression.
+The allowed expressions are a subset of C expressions,
+summarized below.
+.Bl -tag -width "Variables" -offset indent
+.It Values
+All values are of type
+.Ft intmax_t .
+.It Constants
+Decimal, octal (starting with
+.Li 0 )
+and hexadecimal (starting with 
+.Li 0x )
+integer constants.
+.It Variables
+Shell variables can be read and written
+and contain integer constants.
+.It Unary operators
+.Li "! ~ + -"
+.It Binary operators
+.Li "* / % + - << >> < <= > >= == != & ^ | && ||"
+.It Assignment operators
+.Li "= += -= *= /= %= <<= >>= &= ^= |="
+.It Short-circuit evaluation
+The
+.Li &&
+and
+.Li ||
+operators always evaluate both sides.
+This is a bug.
+.El
+.Pp
+The result of the expression is substituted in decimal.
 .Ss White Space Splitting (Field Splitting)
 After parameter expansion, command substitution, and
 arithmetic expansion the shell scans the results of
@@ -2352,8 +2404,6 @@ will return the argument.
 .Xr echo 1 ,
 .Xr ed 1 ,
 .Xr emacs 1 ,
-.Xr expr 1 ,
-.Xr getopt 1 ,
 .Xr pwd 1 ,
 .Xr test 1 ,
 .Xr vi 1 ,

bin/sh/trap.c

@@ -416,7 +416,7 @@ dotrap(void)
 					if (i == SIGCHLD)
 						ignore_sigchld++;
 					savestatus = exitstatus;
-					evalstring(trap[i]);
+					evalstring(trap[i], 0);
 					exitstatus = savestatus;
 					if (i == SIGCHLD)
 						ignore_sigchld--;
@@ -471,7 +471,7 @@ exitshell(int status)
 	handler = &loc1;
 	if ((p = trap[0]) != NULL && *p != '\0') {
 		trap[0] = NULL;
-		evalstring(p);
+		evalstring(p, 0);
 	}
 l1:   handler = &loc2;			/* probably unnecessary */
 	flushall();

bin/test/TEST.README

@@ -1,24 +0,0 @@
-# $FreeBSD$
-
-OS/shell			syntax error	failed
---------------------------------------------------------------------
-bash 1.14.5 			3		0
-pdksh 5.2.5			7		0
-zsh 2.6-beta17			6		4
-FreeBSD 2.1 /bin/test		8		0
-IRIX 5.3 ksh			3		0
-IRIX 5.3 sh			3		0
-IRIX 5.3 /usr/bin/test		11		3
-SunOS 5.4 ksh			3		0
-SunOS 5.4 sh			3		0
-SunOS 5.4 /usr/ucb/test		3		0
-SunOS 5.5 ksh			0		0
-SunOS 5.5 sh			3		0
-SunOS 5.5 /usr/ucb/test		3		0
-SunOS 4.1.3_U1 sh		3		0
-SunOS 4.1.3_U1 /usr/bin/test	3		0
-ULTRIX 4.2 /bin/test		9		0
-ULTRIX 4.2 ksh			1		0
-ULTRIX 4.2 sh5			4		0
-
-96/06/16

bin/test/TEST.csh

@@ -1,152 +0,0 @@
-#	@(#)TEST.csh	5.2 (Berkeley) 4/30/93
-# $FreeBSD$
-
-#alias t '/usr/src/bin/test/obj/test \!*; echo $status'
-alias t '/bin/test \!*; echo $status'
-
-echo 't -b /dev/ttyp2'
-t -b /dev/ttyp2
-echo 't -b /dev/jb1a'
-t -b /dev/jb1a
-
-echo 't -c test.c'
-t -c test.c
-echo 't -c /dev/tty'
-t -c /dev/tty
-
-echo 't -d test.c'
-t -d test.c
-echo 't -d /etc'
-t -d /etc
-
-echo 't -e noexist'
-t -e noexist
-echo 't -e test.c'
-t -e test.c
-
-echo 't -f noexist'
-t -f noexist
-echo 't -f /dev/tty'
-t -f /dev/tty
-echo 't -f test.c'
-t -f test.c
-
-echo 't -g test.c'
-t -g test.c
-echo 't -g /bin/ps'
-t -g /bin/ps
-
-echo 't -n ""'
-t -n ""
-echo 't -n "hello"'
-t -n "hello"
-
-echo 't -p test.c'
-t -p test.c
-
-echo 't -r noexist'
-t -r noexist
-echo 't -r /etc/master.passwd'
-t -r /etc/master.passwd
-echo 't -r test.c'
-t -r test.c
-
-echo 't -s noexist'
-t -s noexist
-echo 't -s /dev/null'
-t -s /dev/null
-echo 't -s test.c'
-t -s test.c
-
-echo 't -t 20'
-t -t 20
-echo 't -t 0'
-t -t 0
-
-echo 't -u test.c'
-t -u test.c
-echo 't -u /bin/rcp'
-t -u /bin/rcp
-
-echo 't -w noexist'
-t -w noexist
-echo 't -w /etc/master.passwd'
-t -w /etc/master.passwd
-echo 't -w /dev/null'
-t -w /dev/null
-
-echo 't -x noexist'
-t -x noexist
-echo 't -x /bin/ps'
-t -x /bin/ps
-echo 't -x /etc/motd'
-t -x /etc/motd
-
-echo 't -z ""'
-t -z ""
-echo 't -z "foo"'
-t -z "foo"
-
-echo 't "foo"'
-t "foo"
-echo 't ""'
-t ""
-
-echo 't "hello" = "hello"'
-t "hello" = "hello"
-echo 't "hello" = "goodbye"'
-t "hello" = "goodbye"
-
-echo 't "hello" != "hello"'
-t "hello" != "hello"
-echo 't "hello" != "goodbye"'
-t "hello" != "goodbye"
-
-echo 't 200 -eq 200'
-t 200 -eq 200
-echo 't 34 -eq 222'
-t 34 -eq 222
-
-echo 't 200 -ne 200'
-t 200 -ne 200
-echo 't 34 -ne 222'
-t 34 -ne 222
-
-echo 't 200 -gt 200'
-t 200 -gt 200
-echo 't 340 -gt 222'
-t 340 -gt 222
-
-echo 't 200 -ge 200'
-t 200 -ge 200
-echo 't 34 -ge 222'
-t 34 -ge 222
-
-echo 't 200 -lt 200'
-t 200 -lt 200
-echo 't 34 -lt 222'
-t 34 -lt 222
-
-echo 't 200 -le 200'
-t 200 -le 200
-echo 't 340 -le 222'
-t 340 -le 222
-
-echo 't 700 -le 1000 -a -n "1" -a "20" = "20"'
-t 700 -le 1000 -a -n "1" -a "20" = "20"
-echo 't ! \( 700 -le 1000 -a -n "1" -a "20" = "20" \)'
-t ! \( 700 -le 1000 -a -n "1" -a "20" = "20" \)
-
-echo 't -5 -eq 5'
-t -5 -eq 5
-
-
-echo 't foo -a ""'
-t foo -a ""
-echo 't "" -a foo'
-t "" -a foo
-echo 't "" -a ""'
-t "" -a ""
-echo 't "" -o ""'
-t "" -o ""
-

bin/test/test.1

@@ -32,7 +32,7 @@
 .\"     @(#)test.1	8.1 (Berkeley) 5/31/93
 .\" $FreeBSD$
 .\"
-.Dd July 31, 2006
+.Dd September 10, 2010
 .Dt TEST 1
 .Os
 .Sh NAME
@@ -282,7 +282,7 @@ True if either
 or
 .Ar expression2
 are true.
-.It Cm \&( Ns Ar expression Ns Cm \&)
+.It Cm \&( Ar expression Cm \&)
 True if expression is true.
 .El
 .Pp
@@ -310,6 +310,14 @@ are evaluated consistently according to the rules specified in the
 standards document.
 All other cases are subject to the ambiguity in the
 command semantics.
+.Pp
+In particular, only expressions containing
+.Fl a ,
+.Fl o ,
+.Cm \&(
+or
+.Cm \&)
+can be ambiguous.
 .Sh EXIT STATUS
 The
 .Nm
@@ -338,12 +346,11 @@ specification.
 Both sides are always evaluated in
 .Fl a
 and
-.Fl o ,
-unlike in the logical operators of
-.Xr sh 1 .
+.Fl o .
 For instance, the writable status of
 .Pa file
 will be tested by the following command even though the former expression
 indicated false, which results in a gratuitous access to the file system:
-.Pp
 .Dl "[ -z abc -a -w file ]"
+To avoid this, write
+.Dl "[ -z abc ] && [ -w file ]"

bin/test/test.c

@@ -163,6 +163,7 @@ struct t_op {
 struct t_op const *t_wp_op;
 int nargc;
 char **t_wp;
+int parenlevel;
 
 static int	aexpr(enum token);
 static int	binop(void);
@@ -171,7 +172,9 @@ static int	filstat(char *, enum token);
 static int	getn(const char *);
 static intmax_t	getq(const char *);
 static int	intcmp(const char *, const char *);
-static int	isoperand(void);
+static int	isunopoperand(void);
+static int	islparenoperand(void);
+static int	isrparenoperand(void);
 static int	newerf(const char *, const char *);
 static int	nexpr(enum token);
 static int	oexpr(enum token);
@@ -205,7 +208,14 @@ main(int argc, char **argv)
 #endif
 	nargc = argc;
 	t_wp = &argv[1];
-	res = !oexpr(t_lex(*t_wp));
+	parenlevel = 0;
+	if (nargc == 4 && strcmp(*t_wp, "!") == 0) {
+		/* Things like ! "" -o x do not fit in the normal grammar. */
+		--nargc;
+		++t_wp;
+		res = oexpr(t_lex(*t_wp));
+	} else
+		res = !oexpr(t_lex(*t_wp));
 
 	if (--nargc > 0)
 		syntax(*t_wp, "unexpected operator");
@@ -268,12 +278,16 @@ primary(enum token n)
 	if (n == EOI)
 		return 0;		/* missing expression */
 	if (n == LPAREN) {
+		parenlevel++;
 		if ((nn = t_lex(nargc > 0 ? (--nargc, *++t_wp) : NULL)) ==
-		    RPAREN)
+		    RPAREN) {
+			parenlevel--;
 			return 0;	/* missing expression */
+		}
 		res = oexpr(nn);
 		if (t_lex(nargc > 0 ? (--nargc, *++t_wp) : NULL) != RPAREN)
 			syntax(NULL, "closing paren expected");
+		parenlevel--;
 		return res;
 	}
 	if (t_wp_op && t_wp_op->op_type == UNOP) {
@@ -410,8 +424,10 @@ t_lex(char *s)
 	}
 	while (op->op_text) {
 		if (strcmp(s, op->op_text) == 0) {
-			if ((op->op_type == UNOP && isoperand()) ||
-			    (op->op_num == LPAREN && nargc == 1))
+			if (((op->op_type == UNOP || op->op_type == BUNOP)
+						&& isunopoperand()) ||
+			    (op->op_num == LPAREN && islparenoperand()) ||
+			    (op->op_num == RPAREN && isrparenoperand()))
 				break;
 			t_wp_op = op;
 			return op->op_num;
@@ -423,7 +439,7 @@ t_lex(char *s)
 }
 
 static int
-isoperand(void)
+isunopoperand(void)
 {
 	struct t_op const *op = ops;
 	char *s;
@@ -431,19 +447,53 @@ isoperand(void)
 
 	if (nargc == 1)
 		return 1;
-	if (nargc == 2)
-		return 0;
 	s = *(t_wp + 1);
+	if (nargc == 2)
+		return parenlevel == 1 && strcmp(s, ")") == 0;
 	t = *(t_wp + 2);
 	while (op->op_text) {
 		if (strcmp(s, op->op_text) == 0)
 			return op->op_type == BINOP &&
-			    (t[0] != ')' || t[1] != '\0');
+			    (parenlevel == 0 || t[0] != ')' || t[1] != '\0');
 		op++;
 	}
 	return 0;
 }
 
+static int
+islparenoperand(void)
+{
+	struct t_op const *op = ops;
+	char *s;
+
+	if (nargc == 1)
+		return 1;
+	s = *(t_wp + 1);
+	if (nargc == 2)
+		return parenlevel == 1 && strcmp(s, ")") == 0;
+	if (nargc != 3)
+		return 0;
+	while (op->op_text) {
+		if (strcmp(s, op->op_text) == 0)
+			return op->op_type == BINOP;
+		op++;
+	}
+	return 0;
+}
+
+static int
+isrparenoperand(void)
+{
+	char *s;
+
+	if (nargc == 1)
+		return 0;
+	s = *(t_wp + 1);
+	if (nargc == 2)
+		return parenlevel == 1 && strcmp(s, ")") == 0;
+	return 0;
+}
+
 /* atoi with error detection */
 static int
 getn(const char *s)

cddl/contrib/opensolaris/cmd/ztest/ztest.c

@@ -19,7 +19,7 @@
  * CDDL HEADER END
  */
 /*
- * Copyright 2008 Sun Microsystems, Inc.  All rights reserved.
+ * Copyright 2009 Sun Microsystems, Inc.  All rights reserved.
  * Use is subject to license terms.
  */
 
@@ -93,6 +93,7 @@
 #include <sys/vdev_file.h>
 #include <sys/spa_impl.h>
 #include <sys/dsl_prop.h>
+#include <sys/dsl_dataset.h>
 #include <sys/refcount.h>
 #include <stdio.h>
 #include <stdio_ext.h>
@@ -174,6 +175,7 @@ ztest_func_t ztest_traverse;
 ztest_func_t ztest_dsl_prop_get_set;
 ztest_func_t ztest_dmu_objset_create_destroy;
 ztest_func_t ztest_dmu_snapshot_create_destroy;
+ztest_func_t ztest_dsl_dataset_promote_busy;
 ztest_func_t ztest_spa_create_destroy;
 ztest_func_t ztest_fault_inject;
 ztest_func_t ztest_spa_rename;
@@ -208,6 +210,7 @@ ztest_info_t ztest_info[] = {
 	{ ztest_dsl_prop_get_set,		1,	&zopt_sometimes	},
 	{ ztest_dmu_objset_create_destroy,	1,	&zopt_sometimes },
 	{ ztest_dmu_snapshot_create_destroy,	1,	&zopt_sometimes },
+	{ ztest_dsl_dataset_promote_busy,	1,	&zopt_sometimes },
 	{ ztest_spa_create_destroy,		1,	&zopt_sometimes },
 	{ ztest_fault_inject,			1,	&zopt_sometimes	},
 	{ ztest_spa_rename,			1,	&zopt_rarely	},
@@ -1591,6 +1594,109 @@ ztest_traverse(ztest_args_t *za)
 	}
 }
 
+/*
+ * Verify dsl_dataset_promote handles EBUSY
+ */
+void
+ztest_dsl_dataset_promote_busy(ztest_args_t *za)
+{
+	int error;
+	objset_t *os = za->za_os;
+	objset_t *clone;
+	dsl_dataset_t *ds;
+	char snap1name[100];
+	char clone1name[100];
+	char snap2name[100];
+	char clone2name[100];
+	char snap3name[100];
+	char osname[MAXNAMELEN];
+	static uint64_t uniq = 0;
+	uint64_t curval;
+
+	curval = atomic_add_64_nv(&uniq, 5) - 5;
+
+	(void) rw_rdlock(&ztest_shared->zs_name_lock);
+
+	dmu_objset_name(os, osname);
+	(void) snprintf(snap1name, 100, "%s@s1_%llu", osname, curval++);
+	(void) snprintf(clone1name, 100, "%s/c1_%llu", osname, curval++);
+	(void) snprintf(snap2name, 100, "%s@s2_%llu", clone1name, curval++);
+	(void) snprintf(clone2name, 100, "%s/c2_%llu", osname, curval++);
+	(void) snprintf(snap3name, 100, "%s@s3_%llu", clone1name, curval++);
+
+	error = dmu_objset_snapshot(osname, strchr(snap1name, '@')+1, FALSE);
+	if (error == ENOSPC)
+		ztest_record_enospc("dmu_take_snapshot");
+	else if (error != 0 && error != EEXIST)
+		fatal(0, "dmu_take_snapshot = %d", error);
+
+	error = dmu_objset_open(snap1name, DMU_OST_OTHER,
+	    DS_MODE_USER | DS_MODE_READONLY, &clone);
+	if (error)
+		fatal(0, "dmu_open_snapshot(%s) = %d", snap1name, error);
+
+	error = dmu_objset_create(clone1name, DMU_OST_OTHER, clone, 0,
+	    NULL, NULL);
+	if (error)
+		fatal(0, "dmu_objset_create(%s) = %d", clone1name, error);
+	dmu_objset_close(clone);
+
+	error = dmu_objset_snapshot(clone1name, strchr(snap2name, '@')+1,
+	    FALSE);
+	if (error == ENOSPC)
+		ztest_record_enospc("dmu_take_snapshot");
+	else if (error != 0 && error != EEXIST)
+		fatal(0, "dmu_take_snapshot = %d", error);
+
+	error = dmu_objset_snapshot(clone1name, strchr(snap3name, '@')+1,
+	    FALSE);
+	if (error == ENOSPC)
+		ztest_record_enospc("dmu_take_snapshot");
+	else if (error != 0 && error != EEXIST)
+		fatal(0, "dmu_take_snapshot = %d", error);
+
+	error = dmu_objset_open(snap3name, DMU_OST_OTHER,
+	    DS_MODE_USER | DS_MODE_READONLY, &clone);
+	if (error)
+		fatal(0, "dmu_open_snapshot(%s) = %d", snap3name, error);
+
+	error = dmu_objset_create(clone2name, DMU_OST_OTHER, clone, 0,
+	    NULL, NULL);
+	if (error)
+		fatal(0, "dmu_objset_create(%s) = %d", clone2name, error);
+	dmu_objset_close(clone);
+
+	error = dsl_dataset_own(snap1name, 0, FTAG, &ds);
+	if (error)
+		fatal(0, "dsl_dataset_own(%s) = %d", snap1name, error);
+	error = dsl_dataset_promote(clone2name);
+	if (error != EBUSY)
+		fatal(0, "dsl_dataset_promote(%s), %d, not EBUSY", clone2name,
+		    error);
+	dsl_dataset_disown(ds, FTAG);
+
+	error = dmu_objset_destroy(clone2name);
+	if (error)
+		fatal(0, "dmu_objset_destroy(%s) = %d", clone2name, error);
+
+	error = dmu_objset_destroy(snap3name);
+	if (error)
+		fatal(0, "dmu_objset_destroy(%s) = %d", snap2name, error);
+
+	error = dmu_objset_destroy(snap2name);
+	if (error)
+		fatal(0, "dmu_objset_destroy(%s) = %d", snap2name, error);
+
+	error = dmu_objset_destroy(clone1name);
+	if (error)
+		fatal(0, "dmu_objset_destroy(%s) = %d", clone1name, error);
+	error = dmu_objset_destroy(snap1name);
+	if (error)
+		fatal(0, "dmu_objset_destroy(%s) = %d", snap1name, error);
+
+	(void) rw_unlock(&ztest_shared->zs_name_lock);
+}
+
 /*
  * Verify that dmu_object_{alloc,free} work as expected.
  */

cddl/contrib/opensolaris/lib/libdtrace/common/dt_impl.h

@@ -137,6 +137,7 @@ typedef struct dt_module {
 	dt_idhash_t *dm_extern;	/* external symbol definitions */
 #if !defined(sun)
 	caddr_t dm_reloc_offset;	/* Symbol relocation offset. */
+	uintptr_t *dm_sec_offsets;
 #endif
 } dt_module_t;
 

cddl/contrib/opensolaris/lib/libdtrace/common/dt_module.c

@@ -83,6 +83,14 @@ dt_module_syminit32(dt_module_t *dmp)
 	uint_t i, n = dmp->dm_nsymelems;
 	uint_t asrsv = 0;
 
+#if defined(__FreeBSD__)
+	GElf_Ehdr ehdr;
+	int is_elf_obj;
+
+	gelf_getehdr(dmp->dm_elf, &ehdr);
+	is_elf_obj = (ehdr.e_type == ET_REL);
+#endif
+
 	for (i = 0; i < n; i++, sym++) {
 		const char *name = base + sym->st_name;
 		uchar_t type = ELF32_ST_TYPE(sym->st_info);
@@ -97,8 +105,12 @@ dt_module_syminit32(dt_module_t *dmp)
 		    (ELF32_ST_BIND(sym->st_info) != STB_LOCAL || sym->st_size)) {
 			asrsv++; /* reserve space in the address map */
 
-#if !defined(sun)
+#if defined(__FreeBSD__)
 			sym->st_value += (Elf_Addr) dmp->dm_reloc_offset;
+			if (is_elf_obj && sym->st_shndx != SHN_UNDEF &&
+			    sym->st_shndx < ehdr.e_shnum)
+				sym->st_value +=
+				    dmp->dm_sec_offsets[sym->st_shndx];
 #endif
 		}
 
@@ -117,6 +129,14 @@ dt_module_syminit64(dt_module_t *dmp)
 	uint_t i, n = dmp->dm_nsymelems;
 	uint_t asrsv = 0;
 
+#if defined(__FreeBSD__)
+	GElf_Ehdr ehdr;
+	int is_elf_obj;
+
+	gelf_getehdr(dmp->dm_elf, &ehdr);
+	is_elf_obj = (ehdr.e_type == ET_REL);
+#endif
+
 	for (i = 0; i < n; i++, sym++) {
 		const char *name = base + sym->st_name;
 		uchar_t type = ELF64_ST_TYPE(sym->st_info);
@@ -130,9 +150,12 @@ dt_module_syminit64(dt_module_t *dmp)
 		if (sym->st_value != 0 &&
 		    (ELF64_ST_BIND(sym->st_info) != STB_LOCAL || sym->st_size)) {
 			asrsv++; /* reserve space in the address map */
-
-#if !defined(sun)
+#if defined(__FreeBSD__)
 			sym->st_value += (Elf_Addr) dmp->dm_reloc_offset;
+			if (is_elf_obj && sym->st_shndx != SHN_UNDEF &&
+			    sym->st_shndx < ehdr.e_shnum)
+				sym->st_value +=
+				    dmp->dm_sec_offsets[sym->st_shndx];
 #endif
 		}
 
@@ -722,7 +745,12 @@ dt_module_unload(dtrace_hdl_t *dtp, dt_module_t *dmp)
 		free(dmp->dm_asmap);
 		dmp->dm_asmap = NULL;
 	}
-
+#if defined(__FreeBSD__)
+	if (dmp->dm_sec_offsets != NULL) {
+		free(dmp->dm_sec_offsets);
+		dmp->dm_sec_offsets = NULL;
+	}
+#endif
 	dmp->dm_symfree = 0;
 	dmp->dm_nsymbuckets = 0;
 	dmp->dm_nsymelems = 0;
@@ -846,9 +874,12 @@ dt_module_update(dtrace_hdl_t *dtp, struct kld_file_stat *k_stat)
 	(void) snprintf(fname, sizeof (fname),
 	    "%s/%s/object", OBJFS_ROOT, name);
 #else
+	GElf_Ehdr ehdr;
 	GElf_Phdr ph;
 	char name[MAXPATHLEN];
+	uintptr_t mapbase, alignmask;
 	int i = 0;
+	int is_elf_obj;
 
 	(void) strlcpy(name, k_stat->name, sizeof(name));
 	(void) strlcpy(fname, k_stat->pathname, sizeof(fname));
@@ -893,7 +924,20 @@ dt_module_update(dtrace_hdl_t *dtp, struct kld_file_stat *k_stat)
 		dt_module_destroy(dtp, dmp);
 		return;
 	}
-
+#if defined(__FreeBSD__)
+	mapbase = (uintptr_t)k_stat->address;
+	gelf_getehdr(dmp->dm_elf, &ehdr);
+	is_elf_obj = (ehdr.e_type == ET_REL);
+	if (is_elf_obj) {
+		dmp->dm_sec_offsets =
+		    malloc(ehdr.e_shnum * sizeof(*dmp->dm_sec_offsets));
+		if (dmp->dm_sec_offsets == NULL) {
+			dt_dprintf("failed to allocate memory\n");
+			dt_module_destroy(dtp, dmp);
+			return;
+		}
+	}
+#endif
 	/*
 	 * Iterate over the section headers locating various sections of
 	 * interest and use their attributes to flesh out the dt_module_t.
@@ -902,7 +946,19 @@ dt_module_update(dtrace_hdl_t *dtp, struct kld_file_stat *k_stat)
 		if (gelf_getshdr(sp, &sh) == NULL || sh.sh_type == SHT_NULL ||
 		    (s = elf_strptr(dmp->dm_elf, shstrs, sh.sh_name)) == NULL)
 			continue; /* skip any malformed sections */
-
+#if defined(__FreeBSD__)
+		if (sh.sh_size == 0)
+			continue;
+		if (is_elf_obj && (sh.sh_type == SHT_PROGBITS ||
+		    sh.sh_type == SHT_NOBITS)) {
+			alignmask = sh.sh_addralign - 1;
+			mapbase += alignmask;
+			mapbase &= ~alignmask;
+			sh.sh_addr = mapbase;
+			dmp->dm_sec_offsets[elf_ndxscn(sp)] = sh.sh_addr;
+			mapbase += sh.sh_size;
+		}
+#endif
 		if (strcmp(s, ".text") == 0) {
 			dmp->dm_text_size = sh.sh_size;
 			dmp->dm_text_va = sh.sh_addr;
@@ -927,6 +983,13 @@ dt_module_update(dtrace_hdl_t *dtp, struct kld_file_stat *k_stat)
 #if defined(sun)
 	dmp->dm_modid = (int)OBJFS_MODID(st.st_ino);
 #else
+	/*
+	 * Include .rodata and special sections into .text.
+	 * This depends on default section layout produced by GNU ld
+	 * for ELF objects and libraries:
+	 * [Text][R/O data][R/W data][Dynamic][BSS][Non loadable]
+	 */
+	dmp->dm_text_size = dmp->dm_data_va - dmp->dm_text_va;
 #if defined(__i386__)
 	/*
 	 * Find the first load section and figure out the relocation

cddl/contrib/opensolaris/tools/ctf/cvt/output.c

@@ -644,7 +644,7 @@ write_file(Elf *src, const char *srcname, Elf *dst, const char *dstname,
 		}
 
 #if !defined(sun)
-		if (ddata->d_buf == NULL) {
+		if (ddata->d_buf == NULL && sdata->d_buf != NULL) {
 			ddata->d_buf = xmalloc(shdr.sh_size);
 			bcopy(sdata->d_buf, ddata->d_buf, shdr.sh_size);
 		}

cddl/lib/libzpool/Makefile

@@ -11,7 +11,7 @@
 # LIST_SRCS
 .PATH: ${.CURDIR}/../../../sys/cddl/contrib/opensolaris/uts/common/os
 # ATOMIC_SRCS
-.if ${MACHINE_ARCH} == "i386" || ${MACHINE_ARCH} == "amd64" || ${MACHINE_ARCH} == "ia64"
+.if ${MACHINE_ARCH} == "i386" || ${MACHINE_ARCH} == "amd64" || ${MACHINE_ARCH} == "ia64" || ${MACHINE_ARCH} == "sparc64"
 .PATH: ${.CURDIR}/../../../sys/cddl/contrib/opensolaris/common/atomic/${MACHINE_ARCH}
 ATOMIC_SRCS=	opensolaris_atomic.S
 .else

contrib/bind9/CHANGES

@@ -1,3 +1,68 @@
+	--- 9.4-ESV-R4 released ---
+
+2970.	[security]	Adding a NO DATA negative cache entry failed to clear
+			any matching RRSIG records.  A subsequent lookup of
+			of NO DATA cache entry could trigger a INSIST when the
+			unexpected RRSIG was also returned with the NO DATA
+			cache entry.
+
+			CVE-2010-3613, VU#706148. [RT #22288]
+
+2968.	[security]	Named could fail to prove a data set was insecure
+			before marking it as insecure.  One set of conditions
+			that can trigger this occurs naturally when rolling
+			DNSKEY algorithms.
+
+			CVE-2010-3614, VU#837744. [RT #22309]
+
+2966.	[bug]		isc_print_vsnprintf() failed to check if there was
+			space available in the buffer when adding a left
+			justified character with a non zero width,
+			(e.g. "%-1c"). [RT #22270]
+
+2962.	[port]		win32: add more dependancies to BINDBuild.dsw.
+			[RT #22062]
+
+2786.	[bug]		Additional could be promoted to answer. [RT #20663]
+
+	--- 9.4-ESV-R3 released ---
+
+2925.	[bug]		Named failed to accept uncachable negative responses
+			from insecure zones. [RT# 21555]
+
+2921.	[bug]		The resolver could attempt to destroy a fetch context
+			too soon.  [RT #19878]
+
+2904.   [bug]           When using DLV, sub-zones of the zones in the DLV,
+			could be incorrectly marked as insecure instead of
+			secure leading to negative proofs failing.  This was
+			a unintended outcome from change 2890. [RT# 21392]
+
+2900.	[bug]	 	The placeholder negative caching element was not
+			properly constructed triggering a INSIST in 
+			dns_ncache_towire(). [RT #21346]
+
+2890.	[bug]		Handle the introduction of new trusted-keys and
+			DS, DLV RRsets better. [RT #21097]
+
+2869.	[bug]		Fix arguments to dns_keytable_findnextkeynode() call.
+			[RT #20877]
+
+2678.	[func]		Treat DS queries as if "minimal-response yes;"
+			was set. [RT #20258]
+
+2427.	[func]		Treat DNSKEY queries as if "minimal-response yes;"
+			was set. [RT #18528]
+
+	--- 9.4-ESV-R2 released ---
+
+2876.	[bug]		Named could return SERVFAIL for negative responses
+			from unsigned zones. [RT #21131]
+
+	--- 9.4-ESV-R1 released ---
+
+2852.	[bug]		Handle broken DNSSEC trust chains better. [RT #15619]
+
 	--- 9.4-ESV released ---
 
 2831.	[security]	Do not attempt to validate or cache

contrib/bind9/RELEASE-NOTES-BIND-9.4-ESV.html

@@ -0,0 +1,123 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<!--
+ - Copyright (C) 2010  Internet Systems Consortium, Inc. ("ISC")
+ -
+ - Permission to use, copy, modify, and/or distribute this software for any
+ - purpose with or without fee is hereby granted, provided that the above
+ - copyright notice and this permission notice appear in all copies.
+ -
+ - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
+ - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
+ - AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
+ - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
+ - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+ - PERFORMANCE OF THIS SOFTWARE.
+-->
+
+<!-- $Id: RELEASE-NOTES-BIND-9.4-ESV.html,v 1.1.2.2 2010/11/29 01:15:44 tbox Exp $ -->
+
+<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title></title><link rel="stylesheet" type="text/css" href="release-notes.css" /><meta name="generator" content="DocBook XSL Stylesheets V1.76.1" /></head><body><div class="article"><div class="titlepage"><hr /></div>
+
+  <div class="section" title="Introduction"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id36111797"></a>Introduction</h2></div></div></div>
+    
+    <p>
+			BIND 9.3-ESV-R4 is a maintenance release for BIND 9.4-ESV.
+		</p>
+    <p>
+			This document summarizes changes from BIND 9.4-ESV-R3 to BIND 9.4-ESV-R4.
+			Please see the CHANGES file in the source code release for a
+			complete list of all changes.
+		</p>
+  </div>
+
+  <div class="section" title="Download"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id36111880"></a>Download</h2></div></div></div>
+    
+    <p>
+			The latest release of BIND 9 software can always be found
+	 		on our web site at
+      <a class="ulink" href="http://www.isc.org/software/bind" target="_top">http://www.isc.org/software/bind</a>.
+  		There you will find additional information about each release,
+ 			source code, and some pre-compiled versions for certain operating
+ 			systems.
+		</p>
+  </div>
+
+  <div class="section" title="Support"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id36111815"></a>Support</h2></div></div></div>
+    
+    <p>Product support information is available on
+      <a class="ulink" href="http://www.isc.org/services/support" target="_top">http://www.isc.org/services/support</a>
+      for paid support options.  Free support is provided by our user
+ 			community via a mailing list.  Information on all public email
+ 			lists is available at
+      <a class="ulink" href="https://lists.isc.org/mailman/listinfo" target="_top">https://lists.isc.org/mailman/listinfo</a>.
+    </p>
+  </div>
+
+  <div class="section" title="New Features"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id36111957"></a>New Features</h2></div></div></div>
+    
+		<div class="section" title="9.4-ESV-R4"><div class="titlepage"><div><div><h3 class="title"><a id="id36111972"></a>9.4-ESV-R4</h3></div></div></div>
+			
+			<p>None.</p>
+		</div>
+  </div>
+
+  <div class="section" title="Feature Changes"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id36111905"></a>Feature Changes</h2></div></div></div>
+    
+		<div class="section" title="9.4-ESV-R4"><div class="titlepage"><div><div><h3 class="title"><a id="id36111988"></a>9.4-ESV-R4</h3></div></div></div>
+			
+			<p>None.</p>
+		</div>
+  </div>
+
+  <div class="section" title="Security Fixes"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id36111999"></a>Security Fixes</h2></div></div></div>
+    
+		<div class="section" title="9.4-ESV-R4"><div class="titlepage"><div><div><h3 class="title"><a id="id36112004"></a>9.4-ESV-R4</h3></div></div></div>
+			
+			<div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem">
+				 	Adding a NO DATA signed negative response to cache failed to clear
+				  any matching RRSIG records already in cache. A subsequent lookup
+				  of the cached NO DATA entry could crash named (INSIST) when the
+				  unexpected RRSIG was also returned with the NO DATA cache entry.
+				  [RT #22288] [CVE-2010-3613] [VU#706148]
+				</li><li class="listitem">
+					BIND, acting as a DNSSEC validator, was determining if the NS RRset
+				  is insecure based on a value that could mean either that the RRset
+				  is actually insecure or that there wasn't a matching key for the RRSIG
+				  in the DNSKEY RRset when resuming from validating the DNSKEY RRset.
+				  This can happen when in the middle of a DNSKEY algorithm rollover,
+				  when two different algorithms were used to sign a zone but only the
+				  new set of keys are in the zone DNSKEY RRset.
+					[RT #22309] [CVE-2010-3614] [VU#837744]
+				</li></ul></div>
+		</div>
+  </div>
+
+  <div class="section" title="Bug Fixes"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id36112029"></a>Bug Fixes</h2></div></div></div>
+    
+		<div class="section" title="9.4-ESV-R4"><div class="titlepage"><div><div><h3 class="title"><a id="id36112035"></a>9.4-ESV-R4</h3></div></div></div>
+			
+	    <div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem">
+          isc_print_vsnprintf() failed to check if there was
+					space available in the buffer when adding a left
+					justified character with a non zero width,
+					(e.g. "%-1c").
+					[RT #22270]
+				</li><li class="listitem">
+          win32: add more dependencies to BINDBuild.dsw.
+          [RT #22062]
+				</li></ul></div>
+		</div>
+  </div>
+
+  <div class="section" title="Thank You"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id36112054"></a>Thank You</h2></div></div></div>
+    
+    <p>
+      Thank you to everyone who assisted us in making this release possible.
+      If you would like to contribute to ISC to assist us in continuing to make
+      quality open source software, please visit our donations page at
+      <a class="ulink" href="http://www.isc.org/supportisc" target="_top">http://www.isc.org/supportisc</a>.
+    </p>
+  </div>
+</div></body></html>

contrib/bind9/RELEASE-NOTES-BIND-9.4-ESV.txt

@@ -0,0 +1,70 @@
+     __________________________________________________________________
+
+Introduction
+
+   BIND 9.3-ESV-R4 is a maintenance release for BIND 9.4-ESV.
+
+   This document summarizes changes from BIND 9.4-ESV-R3 to BIND
+   9.4-ESV-R4. Please see the CHANGES file in the source code release for
+   a complete list of all changes.
+
+Download
+
+   The latest release of BIND 9 software can always be found on our web
+   site at http://www.isc.org/software/bind. There you will find
+   additional information about each release, source code, and some
+   pre-compiled versions for certain operating systems.
+
+Support
+
+   Product support information is available on
+   http://www.isc.org/services/support for paid support options. Free
+   support is provided by our user community via a mailing list.
+   Information on all public email lists is available at
+   https://lists.isc.org/mailman/listinfo.
+
+New Features
+
+9.4-ESV-R4
+
+   None.
+
+Feature Changes
+
+9.4-ESV-R4
+
+   None.
+
+Security Fixes
+
+9.4-ESV-R4
+
+     * Adding a NO DATA signed negative response to cache failed to clear
+       any matching RRSIG records already in cache. A subsequent lookup of
+       the cached NO DATA entry could crash named (INSIST) when the
+       unexpected RRSIG was also returned with the NO DATA cache entry.
+       [RT #22288] [CVE-2010-3613] [VU#706148]
+     * BIND, acting as a DNSSEC validator, was determining if the NS RRset
+       is insecure based on a value that could mean either that the RRset
+       is actually insecure or that there wasn't a matching key for the
+       RRSIG in the DNSKEY RRset when resuming from validating the DNSKEY
+       RRset. This can happen when in the middle of a DNSKEY algorithm
+       rollover, when two different algorithms were used to sign a zone
+       but only the new set of keys are in the zone DNSKEY RRset. [RT
+       #22309] [CVE-2010-3614] [VU#837744]
+
+Bug Fixes
+
+9.4-ESV-R4
+
+     * isc_print_vsnprintf() failed to check if there was space available
+       in the buffer when adding a left justified character with a non
+       zero width, (e.g. "%-1c"). [RT #22270]
+     * win32: add more dependencies to BINDBuild.dsw. [RT #22062]
+
+Thank You
+
+   Thank you to everyone who assisted us in making this release possible.
+   If you would like to contribute to ISC to assist us in continuing to
+   make quality open source software, please visit our donations page at
+   http://www.isc.org/supportisc.

contrib/bind9/bin/named/query.c

@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2010  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: query.c,v 1.257.18.53 2009/12/30 08:55:48 jinmei Exp $ */
+/* $Id: query.c,v 1.257.18.56 2010/11/17 10:21:01 marka Exp $ */
 
 /*! \file */
 
@@ -1129,7 +1129,8 @@ query_addadditional(void *arg, dns_name_t *name, dns_rdatatype_t qtype) {
 			goto cleanup;
 	}
 	result = dns_db_find(db, name, version, type,
-			     client->query.dboptions | DNS_DBFIND_GLUEOK,
+			     client->query.dboptions |
+			     DNS_DBFIND_GLUEOK | DNS_DBFIND_ADDITIONALOK,
 			     client->now, &node, fname, rdataset,
 			     sigrdataset);
 	if (result == DNS_R_GLUE &&
@@ -1250,9 +1251,11 @@ query_addadditional(void *arg, dns_name_t *name, dns_rdatatype_t qtype) {
 			goto addname;
 		if (result == DNS_R_NCACHENXRRSET) {
 			dns_rdataset_disassociate(rdataset);
-			if (sigrdataset != NULL &&
-			    dns_rdataset_isassociated(sigrdataset))
-				dns_rdataset_disassociate(sigrdataset);
+			/*
+			 * Negative cache entries don't have sigrdatasets.
+			 */
+			INSIST(sigrdataset == NULL ||
+			       ! dns_rdataset_isassociated(sigrdataset));
 		}
 		if (result == ISC_R_SUCCESS) {
 			mname = NULL;
@@ -1293,9 +1296,8 @@ query_addadditional(void *arg, dns_name_t *name, dns_rdatatype_t qtype) {
 			goto addname;
 		if (result == DNS_R_NCACHENXRRSET) {
 			dns_rdataset_disassociate(rdataset);
-			if (sigrdataset != NULL &&
-			    dns_rdataset_isassociated(sigrdataset))
-				dns_rdataset_disassociate(sigrdataset);
+			INSIST(sigrdataset == NULL ||
+			       ! dns_rdataset_isassociated(sigrdataset));
 		}
 		if (result == ISC_R_SUCCESS) {
 			mname = NULL;
@@ -1613,7 +1615,8 @@ query_addadditional2(void *arg, dns_name_t *name, dns_rdatatype_t qtype) {
 		goto try_glue;
 
 	result = dns_db_find(db, name, version, type,
-			     client->query.dboptions | DNS_DBFIND_GLUEOK,
+			     client->query.dboptions |
+			     DNS_DBFIND_GLUEOK | DNS_DBFIND_ADDITIONALOK,
 			     client->now, &node, fname, NULL, NULL);
 	if (result == ISC_R_SUCCESS)
 		goto found;
@@ -1743,8 +1746,10 @@ query_addadditional2(void *arg, dns_name_t *name, dns_rdatatype_t qtype) {
 		goto setcache;
 	if (result == DNS_R_NCACHENXRRSET) {
 		dns_rdataset_disassociate(rdataset);
-		if (dns_rdataset_isassociated(sigrdataset))
-			dns_rdataset_disassociate(sigrdataset);
+		/*
+		 * Negative cache entries don't have sigrdatasets.
+		 */
+		INSIST(! dns_rdataset_isassociated(sigrdataset));
 	}
 	if (result == ISC_R_SUCCESS) {
 		/* Remember the result as a cache */
@@ -4650,6 +4655,13 @@ ns_query_start(ns_client_t *client) {
 		}
 	}
 
+	/*
+	 * Turn on minimal response for DNSKEY and DS queries.
+	 */
+	if (qtype == dns_rdatatype_dnskey || qtype == dns_rdatatype_ds)
+		client->query.attributes |= (NS_QUERYATTR_NOAUTHORITY |
+					     NS_QUERYATTR_NOADDITIONAL);
+
 	/*
 	 * If the client has requested that DNSSEC checking be disabled,
 	 * allow lookups to return pending data and instruct the resolver

contrib/bind9/bin/named/server.c

@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2010  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: server.c,v 1.419.18.75 2009/07/11 04:30:49 marka Exp $ */
+/* $Id: server.c,v 1.419.18.77 2010/02/26 23:46:32 tbox Exp $ */
 
 /*! \file */
 
@@ -4563,6 +4563,8 @@ dumpdone(void *arg, isc_result_t result) {
 	}
 	if (dctx->cache != NULL) {
 		dns_adb_dump(dctx->view->view->adb, dctx->fp);
+		dns_resolver_printbadcache(dctx->view->view->resolver,
+					   dctx->fp);
 		dns_db_detach(&dctx->cache);
 	}
 	if (dctx->dumpzones) {

contrib/bind9/doc/arm/Bv9ARM-book.xml

@@ -2,7 +2,7 @@
                "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
 	       [<!ENTITY mdash "&#8212;">]>
 <!--
- - Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010  Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003  Internet Software Consortium.
  -
  - Permission to use, copy, modify, and/or distribute this software for any
@@ -18,7 +18,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- File: $Id: Bv9ARM-book.xml,v 1.241.18.111 2009/09/24 21:38:50 jinmei Exp $ -->
+<!-- File: $Id: Bv9ARM-book.xml,v 1.241.18.113 2010/02/26 23:46:35 tbox Exp $ -->
 <book xmlns:xi="http://www.w3.org/2001/XInclude">
   <title>BIND 9 Administrator Reference Manual</title>
 
@@ -30,6 +30,7 @@
       <year>2007</year>
       <year>2008</year>
       <year>2009</year>
+      <year>2010</year>
       <holder>Internet Systems Consortium, Inc. ("ISC")</holder>
     </copyright>
     <copyright>
@@ -7422,6 +7423,13 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
                   <literal>1800</literal> (30 minutes).
                 </para>
 
+		<para>
+		  Lame-ttl also controls the amount of time DNSSEC
+		  validation failures are cached.  There is a minimum
+		  of 30 seconds applied to bad cache entries if the
+		  lame-ttl is set to less than 30 seconds.
+		</para>
+
               </listitem>
             </varlistentry>
 

contrib/bind9/doc/arm/Bv9ARM.ch01.html

@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: Bv9ARM.ch01.html,v 1.16.18.29 2009/07/11 01:31:48 tbox Exp $ -->
+<!-- $Id: Bv9ARM.ch01.html,v 1.16.18.30 2010/02/27 01:33:43 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -45,17 +45,17 @@
 <div class="toc">
 <p><b>Table of Contents</b></p>
 <dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2563409">Scope of Document</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564388">Organization of This Document</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564528">Conventions Used in This Document</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564641">The Domain Name System (<acronym class="acronym">DNS</acronym>)</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2563412">Scope of Document</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564391">Organization of This Document</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564531">Conventions Used in This Document</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564712">The Domain Name System (<acronym class="acronym">DNS</acronym>)</a></span></dt>
 <dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2564662">DNS Fundamentals</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2564696">Domains and Domain Names</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567170">Zones</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567246">Authoritative Name Servers</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567419">Caching Name Servers</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567549">Name Servers in Multiple Roles</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2564733">DNS Fundamentals</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2564768">Domains and Domain Names</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567173">Zones</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567250">Authoritative Name Servers</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567422">Caching Name Servers</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567553">Name Servers in Multiple Roles</a></span></dt>
 </dl></dd>
 </dl>
 </div>
@@ -71,7 +71,7 @@
     </p>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2563409"></a>Scope of Document</h2></div></div></div>
+<a name="id2563412"></a>Scope of Document</h2></div></div></div>
 <p>
         The Berkeley Internet Name Domain
         (<acronym class="acronym">BIND</acronym>) implements a
@@ -87,7 +87,7 @@
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2564388"></a>Organization of This Document</h2></div></div></div>
+<a name="id2564391"></a>Organization of This Document</h2></div></div></div>
 <p>
         In this document, <span class="emphasis"><em>Chapter 1</em></span> introduces
         the basic <acronym class="acronym">DNS</acronym> and <acronym class="acronym">BIND</acronym> concepts. <span class="emphasis"><em>Chapter 2</em></span>
@@ -116,7 +116,7 @@
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2564528"></a>Conventions Used in This Document</h2></div></div></div>
+<a name="id2564531"></a>Conventions Used in This Document</h2></div></div></div>
 <p>
         In this document, we use the following general typographic
         conventions:
@@ -243,7 +243,7 @@
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2564641"></a>The Domain Name System (<acronym class="acronym">DNS</acronym>)</h2></div></div></div>
+<a name="id2564712"></a>The Domain Name System (<acronym class="acronym">DNS</acronym>)</h2></div></div></div>
 <p>
         The purpose of this document is to explain the installation
         and upkeep of the <acronym class="acronym">BIND</acronym> (Berkeley Internet
@@ -253,7 +253,7 @@
       </p>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2564662"></a>DNS Fundamentals</h3></div></div></div>
+<a name="id2564733"></a>DNS Fundamentals</h3></div></div></div>
 <p>
           The Domain Name System (DNS) is a hierarchical, distributed
           database.  It stores information for mapping Internet host names to
@@ -273,7 +273,7 @@
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2564696"></a>Domains and Domain Names</h3></div></div></div>
+<a name="id2564768"></a>Domains and Domain Names</h3></div></div></div>
 <p>
           The data stored in the DNS is identified by <span class="emphasis"><em>domain names</em></span> that are organized as a tree according to
           organizational or administrative boundaries. Each node of the tree,
@@ -319,7 +319,7 @@
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2567170"></a>Zones</h3></div></div></div>
+<a name="id2567173"></a>Zones</h3></div></div></div>
 <p>
           To properly operate a name server, it is important to understand
           the difference between a <span class="emphasis"><em>zone</em></span>
@@ -372,7 +372,7 @@
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2567246"></a>Authoritative Name Servers</h3></div></div></div>
+<a name="id2567250"></a>Authoritative Name Servers</h3></div></div></div>
 <p>
           Each zone is served by at least
           one <span class="emphasis"><em>authoritative name server</em></span>,
@@ -389,7 +389,7 @@
         </p>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2567270"></a>The Primary Master</h4></div></div></div>
+<a name="id2567273"></a>The Primary Master</h4></div></div></div>
 <p>
             The authoritative server where the master copy of the zone
             data is maintained is called the
@@ -409,7 +409,7 @@
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2567300"></a>Slave Servers</h4></div></div></div>
+<a name="id2567303"></a>Slave Servers</h4></div></div></div>
 <p>
             The other authoritative servers, the <span class="emphasis"><em>slave</em></span>
             servers (also known as <span class="emphasis"><em>secondary</em></span> servers)
@@ -425,7 +425,7 @@
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2567389"></a>Stealth Servers</h4></div></div></div>
+<a name="id2567393"></a>Stealth Servers</h4></div></div></div>
 <p>
             Usually all of the zone's authoritative servers are listed in
             NS records in the parent zone.  These NS records constitute
@@ -460,7 +460,7 @@
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2567419"></a>Caching Name Servers</h3></div></div></div>
+<a name="id2567422"></a>Caching Name Servers</h3></div></div></div>
 <p>
           The resolver libraries provided by most operating systems are
           <span class="emphasis"><em>stub resolvers</em></span>, meaning that they are not
@@ -487,7 +487,7 @@
         </p>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2567523"></a>Forwarding</h4></div></div></div>
+<a name="id2567526"></a>Forwarding</h4></div></div></div>
 <p>
             Even a caching name server does not necessarily perform
             the complete recursive lookup itself.  Instead, it can
@@ -514,7 +514,7 @@
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2567549"></a>Name Servers in Multiple Roles</h3></div></div></div>
+<a name="id2567553"></a>Name Servers in Multiple Roles</h3></div></div></div>
 <p>
           The <acronym class="acronym">BIND</acronym> name server can
           simultaneously act as

contrib/bind9/doc/arm/Bv9ARM.ch02.html

@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: Bv9ARM.ch02.html,v 1.13.18.30 2009/07/11 01:31:47 tbox Exp $ -->
+<!-- $Id: Bv9ARM.ch02.html,v 1.13.18.31 2010/02/27 01:33:43 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -45,16 +45,16 @@
 <div class="toc">
 <p><b>Table of Contents</b></p>
 <dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567584">Hardware requirements</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567610">CPU Requirements</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567623">Memory Requirements</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567854">Name Server Intensive Environment Issues</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567865">Supported Operating Systems</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567587">Hardware requirements</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567613">CPU Requirements</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567626">Memory Requirements</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567721">Name Server Intensive Environment Issues</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567732">Supported Operating Systems</a></span></dt>
 </dl>
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2567584"></a>Hardware requirements</h2></div></div></div>
+<a name="id2567587"></a>Hardware requirements</h2></div></div></div>
 <p>
         <acronym class="acronym">DNS</acronym> hardware requirements have
         traditionally been quite modest.
@@ -73,7 +73,7 @@
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2567610"></a>CPU Requirements</h2></div></div></div>
+<a name="id2567613"></a>CPU Requirements</h2></div></div></div>
 <p>
         CPU requirements for <acronym class="acronym">BIND</acronym> 9 range from
         i486-class machines
@@ -84,7 +84,7 @@
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2567623"></a>Memory Requirements</h2></div></div></div>
+<a name="id2567626"></a>Memory Requirements</h2></div></div></div>
 <p>
         The memory of the server has to be large enough to fit the
         cache and zones loaded off disk.  The <span><strong class="command">max-cache-size</strong></span>
@@ -107,7 +107,7 @@
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2567854"></a>Name Server Intensive Environment Issues</h2></div></div></div>
+<a name="id2567721"></a>Name Server Intensive Environment Issues</h2></div></div></div>
 <p>
         For name server intensive environments, there are two alternative
         configurations that may be used. The first is where clients and
@@ -124,7 +124,7 @@
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2567865"></a>Supported Operating Systems</h2></div></div></div>
+<a name="id2567732"></a>Supported Operating Systems</h2></div></div></div>
 <p>
         ISC <acronym class="acronym">BIND</acronym> 9 compiles and runs on a large
         number of Unix-like operating systems, and on some versions of

contrib/bind9/doc/arm/Bv9ARM.ch03.html

@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: Bv9ARM.ch03.html,v 1.35.18.39 2009/07/11 01:31:48 tbox Exp $ -->
+<!-- $Id: Bv9ARM.ch03.html,v 1.35.18.40 2010/02/27 01:33:43 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -47,14 +47,14 @@
 <dl>
 <dt><span class="sect1"><a href="Bv9ARM.ch03.html#sample_configuration">Sample Configurations</a></span></dt>
 <dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2567897">A Caching-only Name Server</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2567913">An Authoritative-only Name Server</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2567764">A Caching-only Name Server</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2567780">An Authoritative-only Name Server</a></span></dt>
 </dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch03.html#id2568004">Load Balancing</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch03.html#id2568426">Name Server Operations</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch03.html#id2568007">Load Balancing</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch03.html#id2568429">Name Server Operations</a></span></dt>
 <dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2568432">Tools for Use With the Name Server Daemon</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2570041">Signals</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2568435">Tools for Use With the Name Server Daemon</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2570044">Signals</a></span></dt>
 </dl></dd>
 </dl>
 </div>
@@ -68,7 +68,7 @@
 <a name="sample_configuration"></a>Sample Configurations</h2></div></div></div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2567897"></a>A Caching-only Name Server</h3></div></div></div>
+<a name="id2567764"></a>A Caching-only Name Server</h3></div></div></div>
 <p>
           The following sample configuration is appropriate for a caching-only
           name server for use by clients internal to a corporation.  All
@@ -95,7 +95,7 @@ zone "0.0.127.in-addr.arpa" {
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2567913"></a>An Authoritative-only Name Server</h3></div></div></div>
+<a name="id2567780"></a>An Authoritative-only Name Server</h3></div></div></div>
 <p>
           This sample configuration is for an authoritative-only server
           that is the master server for "<code class="filename">example.com</code>"
@@ -137,7 +137,7 @@ zone "eng.example.com" {
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2568004"></a>Load Balancing</h2></div></div></div>
+<a name="id2568007"></a>Load Balancing</h2></div></div></div>
 <p>
         A primitive form of load balancing can be achieved in
         the <acronym class="acronym">DNS</acronym> by using multiple records
@@ -280,10 +280,10 @@ zone "eng.example.com" {
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2568426"></a>Name Server Operations</h2></div></div></div>
+<a name="id2568429"></a>Name Server Operations</h2></div></div></div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2568432"></a>Tools for Use With the Name Server Daemon</h3></div></div></div>
+<a name="id2568435"></a>Tools for Use With the Name Server Daemon</h3></div></div></div>
 <p>
           This section describes several indispensable diagnostic,
           administrative and monitoring tools available to the system
@@ -739,7 +739,7 @@ controls {
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2570041"></a>Signals</h3></div></div></div>
+<a name="id2570044"></a>Signals</h3></div></div></div>
 <p>
           Certain UNIX signals cause the name server to take specific
           actions, as described in the following table.  These signals can

contrib/bind9/doc/arm/Bv9ARM.ch04.html

@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: Bv9ARM.ch04.html,v 1.40.18.50 2009/07/15 01:32:15 tbox Exp $ -->
+<!-- $Id: Bv9ARM.ch04.html,v 1.40.18.51 2010/02/27 01:33:43 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -49,29 +49,29 @@
 <dt><span class="sect1"><a href="Bv9ARM.ch04.html#dynamic_update">Dynamic Update</a></span></dt>
 <dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch04.html#journal">The journal file</a></span></dt></dl></dd>
 <dt><span class="sect1"><a href="Bv9ARM.ch04.html#incremental_zone_transfers">Incremental Zone Transfers (IXFR)</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2570437">Split DNS</a></span></dt>
-<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2570455">Example split DNS setup</a></span></dt></dl></dd>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2570440">Split DNS</a></span></dt>
+<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2570458">Example split DNS setup</a></span></dt></dl></dd>
 <dt><span class="sect1"><a href="Bv9ARM.ch04.html#tsig">TSIG</a></span></dt>
 <dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2570958">Generate Shared Keys for Each Pair of Hosts</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571032">Copying the Shared Secret to Both Machines</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571043">Informing the Servers of the Key's Existence</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571085">Instructing the Server to Use the Key</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571280">TSIG Key Based Access Control</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571328">Errors</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571098">Generate Shared Keys for Each Pair of Hosts</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571172">Copying the Shared Secret to Both Machines</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571182">Informing the Servers of the Key's Existence</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571225">Instructing the Server to Use the Key</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571419">TSIG Key Based Access Control</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571467">Errors</a></span></dt>
 </dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2571410">TKEY</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2571459">SIG(0)</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2571549">TKEY</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2571598">SIG(0)</a></span></dt>
 <dt><span class="sect1"><a href="Bv9ARM.ch04.html#DNSSEC">DNSSEC</a></span></dt>
 <dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2564086">Generating Keys</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2564155">Signing the Zone</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571880">Configuring Servers</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571735">Generating Keys</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571804">Signing the Zone</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571883">Configuring Servers</a></span></dt>
 </dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2572026">IPv6 Support in <acronym class="acronym">BIND</acronym> 9</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2572029">IPv6 Support in <acronym class="acronym">BIND</acronym> 9</a></span></dt>
 <dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572156">Address Lookups Using AAAA Records</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572178">Address to Name Lookups Using Nibble Format</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572160">Address Lookups Using AAAA Records</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572181">Address to Name Lookups Using Nibble Format</a></span></dt>
 </dl></dd>
 </dl>
 </div>
@@ -205,7 +205,7 @@
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2570437"></a>Split DNS</h2></div></div></div>
+<a name="id2570440"></a>Split DNS</h2></div></div></div>
 <p>
         Setting up different views, or visibility, of the DNS space to
         internal and external resolvers is usually referred to as a
@@ -235,7 +235,7 @@
       </p>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2570455"></a>Example split DNS setup</h3></div></div></div>
+<a name="id2570458"></a>Example split DNS setup</h3></div></div></div>
 <p>
         Let's say a company named <span class="emphasis"><em>Example, Inc.</em></span>
         (<code class="literal">example.com</code>)
@@ -481,7 +481,7 @@ nameserver 172.16.72.4
       </p>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2570958"></a>Generate Shared Keys for Each Pair of Hosts</h3></div></div></div>
+<a name="id2571098"></a>Generate Shared Keys for Each Pair of Hosts</h3></div></div></div>
 <p>
           A shared secret is generated to be shared between <span class="emphasis"><em>host1</em></span> and <span class="emphasis"><em>host2</em></span>.
           An arbitrary key name is chosen: "host1-host2.". The key name must
@@ -489,7 +489,7 @@ nameserver 172.16.72.4
         </p>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2570976"></a>Automatic Generation</h4></div></div></div>
+<a name="id2571115"></a>Automatic Generation</h4></div></div></div>
 <p>
             The following command will generate a 128-bit (16 byte) HMAC-MD5
             key as described above. Longer keys are better, but shorter keys
@@ -514,7 +514,7 @@ nameserver 172.16.72.4
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2571014"></a>Manual Generation</h4></div></div></div>
+<a name="id2571154"></a>Manual Generation</h4></div></div></div>
 <p>
             The shared secret is simply a random sequence of bits, encoded
             in base-64. Most ASCII strings are valid base-64 strings (assuming
@@ -529,7 +529,7 @@ nameserver 172.16.72.4
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2571032"></a>Copying the Shared Secret to Both Machines</h3></div></div></div>
+<a name="id2571172"></a>Copying the Shared Secret to Both Machines</h3></div></div></div>
 <p>
           This is beyond the scope of DNS. A secure transport mechanism
           should be used. This could be secure FTP, ssh, telephone, etc.
@@ -537,7 +537,7 @@ nameserver 172.16.72.4
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2571043"></a>Informing the Servers of the Key's Existence</h3></div></div></div>
+<a name="id2571182"></a>Informing the Servers of the Key's Existence</h3></div></div></div>
 <p>
           Imagine <span class="emphasis"><em>host1</em></span> and <span class="emphasis"><em>host 2</em></span>
           are
@@ -566,7 +566,7 @@ key host1-host2. {
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2571085"></a>Instructing the Server to Use the Key</h3></div></div></div>
+<a name="id2571225"></a>Instructing the Server to Use the Key</h3></div></div></div>
 <p>
           Since keys are shared between two hosts only, the server must
           be told when keys are to be used. The following is added to the <code class="filename">named.conf</code> file
@@ -598,7 +598,7 @@ server 10.1.2.3 {
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2571280"></a>TSIG Key Based Access Control</h3></div></div></div>
+<a name="id2571419"></a>TSIG Key Based Access Control</h3></div></div></div>
 <p>
           <acronym class="acronym">BIND</acronym> allows IP addresses and ranges
           to be specified in ACL
@@ -626,7 +626,7 @@ allow-update { key host1-host2. ;};
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2571328"></a>Errors</h3></div></div></div>
+<a name="id2571467"></a>Errors</h3></div></div></div>
 <p>
           The processing of TSIG signed messages can result in
           several errors. If a signed message is sent to a non-TSIG aware
@@ -652,7 +652,7 @@ allow-update { key host1-host2. ;};
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2571410"></a>TKEY</h2></div></div></div>
+<a name="id2571549"></a>TKEY</h2></div></div></div>
 <p><span><strong class="command">TKEY</strong></span>
         is a mechanism for automatically generating a shared secret
         between two hosts.  There are several "modes" of
@@ -688,7 +688,7 @@ allow-update { key host1-host2. ;};
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2571459"></a>SIG(0)</h2></div></div></div>
+<a name="id2571598"></a>SIG(0)</h2></div></div></div>
 <p>
         <acronym class="acronym">BIND</acronym> 9 partially supports DNSSEC SIG(0)
             transaction signatures as specified in RFC 2535 and RFC 2931.
@@ -749,7 +749,7 @@ allow-update { key host1-host2. ;};
       </p>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2564086"></a>Generating Keys</h3></div></div></div>
+<a name="id2571735"></a>Generating Keys</h3></div></div></div>
 <p>
           The <span><strong class="command">dnssec-keygen</strong></span> program is used to
           generate keys.
@@ -800,7 +800,7 @@ allow-update { key host1-host2. ;};
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2564155"></a>Signing the Zone</h3></div></div></div>
+<a name="id2571804"></a>Signing the Zone</h3></div></div></div>
 <p>
           The <span><strong class="command">dnssec-signzone</strong></span> program is used
           to
@@ -844,7 +844,7 @@ allow-update { key host1-host2. ;};
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2571880"></a>Configuring Servers</h3></div></div></div>
+<a name="id2571883"></a>Configuring Servers</h3></div></div></div>
 <p>
           To enable <span><strong class="command">named</strong></span> to respond appropriately
           to DNS requests from DNSSEC aware clients,
@@ -932,7 +932,7 @@ options {
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2572026"></a>IPv6 Support in <acronym class="acronym">BIND</acronym> 9</h2></div></div></div>
+<a name="id2572029"></a>IPv6 Support in <acronym class="acronym">BIND</acronym> 9</h2></div></div></div>
 <p>
         <acronym class="acronym">BIND</acronym> 9 fully supports all currently
         defined forms of IPv6
@@ -971,7 +971,7 @@ options {
       </p>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2572156"></a>Address Lookups Using AAAA Records</h3></div></div></div>
+<a name="id2572160"></a>Address Lookups Using AAAA Records</h3></div></div></div>
 <p>
           The IPv6 AAAA record is a parallel to the IPv4 A record,
           and, unlike the deprecated A6 record, specifies the entire
@@ -990,7 +990,7 @@ host            3600    IN      AAAA    2001:db8::1
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2572178"></a>Address to Name Lookups Using Nibble Format</h3></div></div></div>
+<a name="id2572181"></a>Address to Name Lookups Using Nibble Format</h3></div></div></div>
 <p>
           When looking up an address in nibble format, the address
           components are simply reversed, just as in IPv4, and

contrib/bind9/doc/arm/Bv9ARM.ch05.html

@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: Bv9ARM.ch05.html,v 1.33.18.41 2009/07/11 01:31:49 tbox Exp $ -->
+<!-- $Id: Bv9ARM.ch05.html,v 1.33.18.42 2010/02/27 01:33:44 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -45,13 +45,13 @@
 <div class="toc">
 <p><b>Table of Contents</b></p>
 <dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch05.html#id2572211">The Lightweight Resolver Library</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch05.html#id2572214">The Lightweight Resolver Library</a></span></dt>
 <dt><span class="sect1"><a href="Bv9ARM.ch05.html#lwresd">Running a Resolver Daemon</a></span></dt>
 </dl>
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2572211"></a>The Lightweight Resolver Library</h2></div></div></div>
+<a name="id2572214"></a>The Lightweight Resolver Library</h2></div></div></div>
 <p>
         Traditionally applications have been linked with a stub resolver
         library that sends recursive DNS queries to a local caching name

contrib/bind9/doc/arm/Bv9ARM.ch06.html

@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: Bv9ARM.ch06.html,v 1.82.18.98 2009/09/25 01:33:41 tbox Exp $ -->
+<!-- $Id: Bv9ARM.ch06.html,v 1.82.18.100 2010/02/27 01:33:44 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -48,52 +48,52 @@
 <dt><span class="sect1"><a href="Bv9ARM.ch06.html#configuration_file_elements">Configuration File Elements</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="Bv9ARM.ch06.html#address_match_lists">Address Match Lists</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2573560">Comment Syntax</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2573563">Comment Syntax</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="Bv9ARM.ch06.html#Configuration_File_Grammar">Configuration File Grammar</a></span></dt>
 <dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574164"><span><strong class="command">acl</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574167"><span><strong class="command">acl</strong></span> Statement Grammar</a></span></dt>
 <dt><span class="sect2"><a href="Bv9ARM.ch06.html#acl"><span><strong class="command">acl</strong></span> Statement Definition and
           Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574422"><span><strong class="command">controls</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574425"><span><strong class="command">controls</strong></span> Statement Grammar</a></span></dt>
 <dt><span class="sect2"><a href="Bv9ARM.ch06.html#controls_statement_definition_and_usage"><span><strong class="command">controls</strong></span> Statement Definition and
           Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574851"><span><strong class="command">include</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574868"><span><strong class="command">include</strong></span> Statement Definition and
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574854"><span><strong class="command">include</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574871"><span><strong class="command">include</strong></span> Statement Definition and
           Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574891"><span><strong class="command">key</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574915"><span><strong class="command">key</strong></span> Statement Definition and Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575005"><span><strong class="command">logging</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575200"><span><strong class="command">logging</strong></span> Statement Definition and
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574894"><span><strong class="command">key</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574918"><span><strong class="command">key</strong></span> Statement Definition and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575009"><span><strong class="command">logging</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575203"><span><strong class="command">logging</strong></span> Statement Definition and
           Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577096"><span><strong class="command">lwres</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577238"><span><strong class="command">lwres</strong></span> Statement Definition and Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577302"><span><strong class="command">masters</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577346"><span><strong class="command">masters</strong></span> Statement Definition and
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577099"><span><strong class="command">lwres</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577241"><span><strong class="command">lwres</strong></span> Statement Definition and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577305"><span><strong class="command">masters</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577349"><span><strong class="command">masters</strong></span> Statement Definition and
           Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577361"><span><strong class="command">options</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577364"><span><strong class="command">options</strong></span> Statement Grammar</a></span></dt>
 <dt><span class="sect2"><a href="Bv9ARM.ch06.html#options"><span><strong class="command">options</strong></span> Statement Definition and
           Usage</a></span></dt>
 <dt><span class="sect2"><a href="Bv9ARM.ch06.html#server_statement_grammar"><span><strong class="command">server</strong></span> Statement Grammar</a></span></dt>
 <dt><span class="sect2"><a href="Bv9ARM.ch06.html#server_statement_definition_and_usage"><span><strong class="command">server</strong></span> Statement Definition and
             Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2586451"><span><strong class="command">trusted-keys</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2586502"><span><strong class="command">trusted-keys</strong></span> Statement Definition
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2586321"><span><strong class="command">trusted-keys</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2586372"><span><strong class="command">trusted-keys</strong></span> Statement Definition
             and Usage</a></span></dt>
 <dt><span class="sect2"><a href="Bv9ARM.ch06.html#view_statement_grammar"><span><strong class="command">view</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2586652"><span><strong class="command">view</strong></span> Statement Definition and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2586590"><span><strong class="command">view</strong></span> Statement Definition and Usage</a></span></dt>
 <dt><span class="sect2"><a href="Bv9ARM.ch06.html#zone_statement_grammar"><span><strong class="command">zone</strong></span>
             Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2587989"><span><strong class="command">zone</strong></span> Statement Definition and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2587995"><span><strong class="command">zone</strong></span> Statement Definition and Usage</a></span></dt>
 </dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch06.html#id2590251">Zone File</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch06.html#id2590189">Zone File</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="Bv9ARM.ch06.html#types_of_resource_records_and_when_to_use_them">Types of Resource Records and When to Use Them</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2592275">Discussion of MX Records</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2592281">Discussion of MX Records</a></span></dt>
 <dt><span class="sect2"><a href="Bv9ARM.ch06.html#Setting_TTLs">Setting TTLs</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2592890">Inverse Mapping in IPv4</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2593085">Other Zone File Directives</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2593342"><acronym class="acronym">BIND</acronym> Master File Extension: the  <span><strong class="command">$GENERATE</strong></span> Directive</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2592965">Inverse Mapping in IPv4</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2593092">Other Zone File Directives</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2593349"><acronym class="acronym">BIND</acronym> Master File Extension: the  <span><strong class="command">$GENERATE</strong></span> Directive</a></span></dt>
 <dt><span class="sect2"><a href="Bv9ARM.ch06.html#zonefile_format">Additional File Formats</a></span></dt>
 </dl></dd>
 </dl>
@@ -455,7 +455,7 @@
 <a name="address_match_lists"></a>Address Match Lists</h3></div></div></div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2573353"></a>Syntax</h4></div></div></div>
+<a name="id2573356"></a>Syntax</h4></div></div></div>
 <pre class="programlisting"><code class="varname">address_match_list</code> = address_match_list_element ;
   [<span class="optional"> address_match_list_element; ... </span>]
 <code class="varname">address_match_list_element</code> = [<span class="optional"> ! </span>] (ip_address [<span class="optional">/length</span>] |
@@ -464,7 +464,7 @@
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2573381"></a>Definition and Usage</h4></div></div></div>
+<a name="id2573384"></a>Definition and Usage</h4></div></div></div>
 <p>
             Address match lists are primarily used to determine access
             control for various server operations. They are also used in
@@ -542,7 +542,7 @@
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2573560"></a>Comment Syntax</h3></div></div></div>
+<a name="id2573563"></a>Comment Syntax</h3></div></div></div>
 <p>
           The <acronym class="acronym">BIND</acronym> 9 comment syntax allows for
           comments to appear
@@ -552,7 +552,7 @@
         </p>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2573575"></a>Syntax</h4></div></div></div>
+<a name="id2573578"></a>Syntax</h4></div></div></div>
 <p>
             </p>
 <pre class="programlisting">/* This is a <acronym class="acronym">BIND</acronym> comment as in C */</pre>
@@ -567,7 +567,7 @@
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2573605"></a>Definition and Usage</h4></div></div></div>
+<a name="id2573608"></a>Definition and Usage</h4></div></div></div>
 <p>
             Comments may appear anywhere that whitespace may appear in
             a <acronym class="acronym">BIND</acronym> configuration file.
@@ -797,7 +797,7 @@
       </p>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2574164"></a><span><strong class="command">acl</strong></span> Statement Grammar</h3></div></div></div>
+<a name="id2574167"></a><span><strong class="command">acl</strong></span> Statement Grammar</h3></div></div></div>
 <pre class="programlisting"><span><strong class="command">acl</strong></span> acl-name {
     address_match_list
 };
@@ -880,7 +880,7 @@
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2574422"></a><span><strong class="command">controls</strong></span> Statement Grammar</h3></div></div></div>
+<a name="id2574425"></a><span><strong class="command">controls</strong></span> Statement Grammar</h3></div></div></div>
 <pre class="programlisting"><span><strong class="command">controls</strong></span> {
    [ inet ( ip_addr | * ) [ port ip_port ] allow { <em class="replaceable"><code> address_match_list </code></em> }
                 keys { <em class="replaceable"><code>key_list</code></em> }; ]
@@ -1002,12 +1002,12 @@
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2574851"></a><span><strong class="command">include</strong></span> Statement Grammar</h3></div></div></div>
+<a name="id2574854"></a><span><strong class="command">include</strong></span> Statement Grammar</h3></div></div></div>
 <pre class="programlisting"><span><strong class="command">include</strong></span> <em class="replaceable"><code>filename</code></em>;</pre>
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2574868"></a><span><strong class="command">include</strong></span> Statement Definition and
+<a name="id2574871"></a><span><strong class="command">include</strong></span> Statement Definition and
           Usage</h3></div></div></div>
 <p>
           The <span><strong class="command">include</strong></span> statement inserts the
@@ -1022,7 +1022,7 @@
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2574891"></a><span><strong class="command">key</strong></span> Statement Grammar</h3></div></div></div>
+<a name="id2574894"></a><span><strong class="command">key</strong></span> Statement Grammar</h3></div></div></div>
 <pre class="programlisting"><span><strong class="command">key</strong></span> <em class="replaceable"><code>key_id</code></em> {
     algorithm <em class="replaceable"><code>string</code></em>;
     secret <em class="replaceable"><code>string</code></em>;
@@ -1031,7 +1031,7 @@
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2574915"></a><span><strong class="command">key</strong></span> Statement Definition and Usage</h3></div></div></div>
+<a name="id2574918"></a><span><strong class="command">key</strong></span> Statement Definition and Usage</h3></div></div></div>
 <p>
           The <span><strong class="command">key</strong></span> statement defines a shared
           secret key for use with TSIG (see <a href="Bv9ARM.ch04.html#tsig" title="TSIG">the section called &#8220;TSIG&#8221;</a>)
@@ -1078,7 +1078,7 @@
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2575005"></a><span><strong class="command">logging</strong></span> Statement Grammar</h3></div></div></div>
+<a name="id2575009"></a><span><strong class="command">logging</strong></span> Statement Grammar</h3></div></div></div>
 <pre class="programlisting"><span><strong class="command">logging</strong></span> {
    [ <span><strong class="command">channel</strong></span> <em class="replaceable"><code>channel_name</code></em> {
      ( <span><strong class="command">file</strong></span> <em class="replaceable"><code>path_name</code></em>
@@ -1102,7 +1102,7 @@
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2575200"></a><span><strong class="command">logging</strong></span> Statement Definition and
+<a name="id2575203"></a><span><strong class="command">logging</strong></span> Statement Definition and
           Usage</h3></div></div></div>
 <p>
           The <span><strong class="command">logging</strong></span> statement configures a
@@ -1136,7 +1136,7 @@
         </p>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2575252"></a>The <span><strong class="command">channel</strong></span> Phrase</h4></div></div></div>
+<a name="id2575255"></a>The <span><strong class="command">channel</strong></span> Phrase</h4></div></div></div>
 <p>
             All log output goes to one or more <span class="emphasis"><em>channels</em></span>;
             you can make as many of them as you want.
@@ -1665,7 +1665,7 @@ category notify { null; };
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2576508"></a>The <span><strong class="command">query-errors</strong></span> Category</h4></div></div></div>
+<a name="id2576512"></a>The <span><strong class="command">query-errors</strong></span> Category</h4></div></div></div>
 <p>
             The <span><strong class="command">query-errors</strong></span> category is
             specifically intended for debugging purposes: To identify
@@ -1893,7 +1893,7 @@ badresp:1,adberr:0,findfail:0,valfail:0]
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2577096"></a><span><strong class="command">lwres</strong></span> Statement Grammar</h3></div></div></div>
+<a name="id2577099"></a><span><strong class="command">lwres</strong></span> Statement Grammar</h3></div></div></div>
 <p>
            This is the grammar of the <span><strong class="command">lwres</strong></span>
           statement in the <code class="filename">named.conf</code> file:
@@ -1908,7 +1908,7 @@ badresp:1,adberr:0,findfail:0,valfail:0]
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2577238"></a><span><strong class="command">lwres</strong></span> Statement Definition and Usage</h3></div></div></div>
+<a name="id2577241"></a><span><strong class="command">lwres</strong></span> Statement Definition and Usage</h3></div></div></div>
 <p>
           The <span><strong class="command">lwres</strong></span> statement configures the
           name
@@ -1959,14 +1959,14 @@ badresp:1,adberr:0,findfail:0,valfail:0]
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2577302"></a><span><strong class="command">masters</strong></span> Statement Grammar</h3></div></div></div>
+<a name="id2577305"></a><span><strong class="command">masters</strong></span> Statement Grammar</h3></div></div></div>
 <pre class="programlisting">
 <span><strong class="command">masters</strong></span> <em class="replaceable"><code>name</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] { ( <em class="replaceable"><code>masters_list</code></em> | <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] [<span class="optional">key <em class="replaceable"><code>key</code></em></span>] ) ; [<span class="optional">...</span>] };
 </pre>
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2577346"></a><span><strong class="command">masters</strong></span> Statement Definition and
+<a name="id2577349"></a><span><strong class="command">masters</strong></span> Statement Definition and
           Usage</h3></div></div></div>
 <p><span><strong class="command">masters</strong></span>
           lists allow for a common set of masters to be easily used by
@@ -1975,7 +1975,7 @@ badresp:1,adberr:0,findfail:0,valfail:0]
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2577361"></a><span><strong class="command">options</strong></span> Statement Grammar</h3></div></div></div>
+<a name="id2577364"></a><span><strong class="command">options</strong></span> Statement Grammar</h3></div></div></div>
 <p>
           This is the grammar of the <span><strong class="command">options</strong></span>
           statement in the <code class="filename">named.conf</code> file:
@@ -3086,7 +3086,7 @@ options {
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2581241"></a>Forwarding</h4></div></div></div>
+<a name="id2581244"></a>Forwarding</h4></div></div></div>
 <p>
             The forwarding facility can be used to create a large site-wide
             cache on a few servers, reducing traffic over links to external
@@ -3130,7 +3130,7 @@ options {
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2581368"></a>Dual-stack Servers</h4></div></div></div>
+<a name="id2581371"></a>Dual-stack Servers</h4></div></div></div>
 <p>
             Dual-stack servers are used as servers of last resort to work
             around
@@ -3286,7 +3286,7 @@ options {
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2581867"></a>Interfaces</h4></div></div></div>
+<a name="id2581870"></a>Interfaces</h4></div></div></div>
 <p>
             The interfaces and ports that the server will answer queries
             from may be specified using the <span><strong class="command">listen-on</strong></span> option. <span><strong class="command">listen-on</strong></span> takes
@@ -3719,7 +3719,7 @@ avoid-v6-udp-ports {};
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2582869"></a>UDP Port Lists</h4></div></div></div>
+<a name="id2582872"></a>UDP Port Lists</h4></div></div></div>
 <p>
             <span><strong class="command">use-v4-udp-ports</strong></span>,
             <span><strong class="command">avoid-v4-udp-ports</strong></span>,
@@ -3761,7 +3761,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2582929"></a>Operating System Resource Limits</h4></div></div></div>
+<a name="id2582932"></a>Operating System Resource Limits</h4></div></div></div>
 <p>
             The server's usage of many system resources can be limited.
             Scaled values are allowed when specifying resource limits.  For
@@ -3922,7 +3922,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2583488"></a>Periodic Task Intervals</h4></div></div></div>
+<a name="id2583422"></a>Periodic Task Intervals</h4></div></div></div>
 <div class="variablelist"><dl>
 <dt><span class="term"><span><strong class="command">cleaning-interval</strong></span></span></dt>
 <dd><p>
@@ -4227,14 +4227,22 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 <a name="tuning"></a>Tuning</h4></div></div></div>
 <div class="variablelist"><dl>
 <dt><span class="term"><span><strong class="command">lame-ttl</strong></span></span></dt>
-<dd><p>
+<dd>
+<p>
                   Sets the number of seconds to cache a
                   lame server indication. 0 disables caching. (This is
                   <span class="bold"><strong>NOT</strong></span> recommended.)
                   The default is <code class="literal">600</code> (10 minutes) and the
                   maximum value is
                   <code class="literal">1800</code> (30 minutes).
-                </p></dd>
+                </p>
+<p>
+                  Lame-ttl also controls the amount of time DNSSEC
+                  validation failures are cached.  There is a minimum
+                  of 30 seconds applied to bad cache entries if the
+                  lame-ttl is set to less than 30 seconds.
+                </p>
+</dd>
 <dt><span class="term"><span><strong class="command">max-ncache-ttl</strong></span></span></dt>
 <dd><p>
                   To reduce network traffic and increase performance,
@@ -4993,7 +5001,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2586451"></a><span><strong class="command">trusted-keys</strong></span> Statement Grammar</h3></div></div></div>
+<a name="id2586321"></a><span><strong class="command">trusted-keys</strong></span> Statement Grammar</h3></div></div></div>
 <pre class="programlisting"><span><strong class="command">trusted-keys</strong></span> {
     <em class="replaceable"><code>string</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>string</code></em> ;
     [<span class="optional"> <em class="replaceable"><code>string</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>string</code></em> ; [<span class="optional">...</span>]</span>]
@@ -5002,7 +5010,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2586502"></a><span><strong class="command">trusted-keys</strong></span> Statement Definition
+<a name="id2586372"></a><span><strong class="command">trusted-keys</strong></span> Statement Definition
             and Usage</h3></div></div></div>
 <p>
             The <span><strong class="command">trusted-keys</strong></span> statement defines
@@ -5045,7 +5053,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2586652"></a><span><strong class="command">view</strong></span> Statement Definition and Usage</h3></div></div></div>
+<a name="id2586590"></a><span><strong class="command">view</strong></span> Statement Definition and Usage</h3></div></div></div>
 <p>
             The <span><strong class="command">view</strong></span> statement is a powerful
             feature
@@ -5301,10 +5309,10 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2587989"></a><span><strong class="command">zone</strong></span> Statement Definition and Usage</h3></div></div></div>
+<a name="id2587995"></a><span><strong class="command">zone</strong></span> Statement Definition and Usage</h3></div></div></div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2587996"></a>Zone Types</h4></div></div></div>
+<a name="id2588003"></a>Zone Types</h4></div></div></div>
 <div class="informaltable"><table border="1">
 <colgroup>
 <col>
@@ -5515,7 +5523,7 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2588424"></a>Class</h4></div></div></div>
+<a name="id2588362"></a>Class</h4></div></div></div>
 <p>
               The zone's name may optionally be followed by a class. If
               a class is not specified, class <code class="literal">IN</code> (for <code class="varname">Internet</code>),
@@ -5537,7 +5545,7 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2588457"></a>Zone Options</h4></div></div></div>
+<a name="id2588395"></a>Zone Options</h4></div></div></div>
 <div class="variablelist"><dl>
 <dt><span class="term"><span><strong class="command">allow-notify</strong></span></span></dt>
 <dd><p>
@@ -6038,7 +6046,7 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2590251"></a>Zone File</h2></div></div></div>
+<a name="id2590189"></a>Zone File</h2></div></div></div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="types_of_resource_records_and_when_to_use_them"></a>Types of Resource Records and When to Use Them</h3></div></div></div>
@@ -6051,7 +6059,7 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"
           </p>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2590269"></a>Resource Records</h4></div></div></div>
+<a name="id2590208"></a>Resource Records</h4></div></div></div>
 <p>
               A domain name identifies a node.  Each node has a set of
               resource information, which may be empty.  The set of resource
@@ -6741,7 +6749,7 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2591754"></a>Textual expression of RRs</h4></div></div></div>
+<a name="id2591761"></a>Textual expression of RRs</h4></div></div></div>
 <p>
               RRs are represented in binary form in the packets of the DNS
               protocol, and are usually represented in highly encoded form
@@ -6944,7 +6952,7 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2592275"></a>Discussion of MX Records</h3></div></div></div>
+<a name="id2592281"></a>Discussion of MX Records</h3></div></div></div>
 <p>
             As described above, domain servers store information as a
             series of resource records, each of which contains a particular
@@ -7200,7 +7208,7 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2592890"></a>Inverse Mapping in IPv4</h3></div></div></div>
+<a name="id2592965"></a>Inverse Mapping in IPv4</h3></div></div></div>
 <p>
             Reverse name resolution (that is, translation from IP address
             to name) is achieved by means of the <span class="emphasis"><em>in-addr.arpa</em></span> domain
@@ -7261,7 +7269,7 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2593085"></a>Other Zone File Directives</h3></div></div></div>
+<a name="id2593092"></a>Other Zone File Directives</h3></div></div></div>
 <p>
             The Master File Format was initially defined in RFC 1035 and
             has subsequently been extended. While the Master File Format
@@ -7276,7 +7284,7 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"
           </p>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2593108"></a>The <span><strong class="command">$ORIGIN</strong></span> Directive</h4></div></div></div>
+<a name="id2593114"></a>The <span><strong class="command">$ORIGIN</strong></span> Directive</h4></div></div></div>
 <p>
               Syntax: <span><strong class="command">$ORIGIN</strong></span>
               <em class="replaceable"><code>domain-name</code></em>
@@ -7304,7 +7312,7 @@ WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM.
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2593169"></a>The <span><strong class="command">$INCLUDE</strong></span> Directive</h4></div></div></div>
+<a name="id2593175"></a>The <span><strong class="command">$INCLUDE</strong></span> Directive</h4></div></div></div>
 <p>
               Syntax: <span><strong class="command">$INCLUDE</strong></span>
               <em class="replaceable"><code>filename</code></em>
@@ -7340,7 +7348,7 @@ WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM.
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2593238"></a>The <span><strong class="command">$TTL</strong></span> Directive</h4></div></div></div>
+<a name="id2593244"></a>The <span><strong class="command">$TTL</strong></span> Directive</h4></div></div></div>
 <p>
               Syntax: <span><strong class="command">$TTL</strong></span>
               <em class="replaceable"><code>default-ttl</code></em>
@@ -7359,7 +7367,7 @@ WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM.
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2593342"></a><acronym class="acronym">BIND</acronym> Master File Extension: the  <span><strong class="command">$GENERATE</strong></span> Directive</h3></div></div></div>
+<a name="id2593349"></a><acronym class="acronym">BIND</acronym> Master File Extension: the  <span><strong class="command">$GENERATE</strong></span> Directive</h3></div></div></div>
 <p>
             Syntax: <span><strong class="command">$GENERATE</strong></span>
             <em class="replaceable"><code>range</code></em>

contrib/bind9/doc/arm/Bv9ARM.ch07.html

@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: Bv9ARM.ch07.html,v 1.75.18.84 2009/09/25 01:33:44 tbox Exp $ -->
+<!-- $Id: Bv9ARM.ch07.html,v 1.75.18.86 2010/02/27 01:33:45 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -46,10 +46,10 @@
 <p><b>Table of Contents</b></p>
 <dl>
 <dt><span class="sect1"><a href="Bv9ARM.ch07.html#Access_Control_Lists">Access Control Lists</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch07.html#id2593952"><span><strong class="command">Chroot</strong></span> and <span><strong class="command">Setuid</strong></span></a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch07.html#id2593958"><span><strong class="command">Chroot</strong></span> and <span><strong class="command">Setuid</strong></span></a></span></dt>
 <dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2594033">The <span><strong class="command">chroot</strong></span> Environment</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2594092">Using the <span><strong class="command">setuid</strong></span> Function</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2594039">The <span><strong class="command">chroot</strong></span> Environment</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2594099">Using the <span><strong class="command">setuid</strong></span> Function</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="Bv9ARM.ch07.html#dynamic_update_security">Dynamic Update Security</a></span></dt>
 </dl>
@@ -118,7 +118,7 @@ zone "example.com" {
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2593952"></a><span><strong class="command">Chroot</strong></span> and <span><strong class="command">Setuid</strong></span>
+<a name="id2593958"></a><span><strong class="command">Chroot</strong></span> and <span><strong class="command">Setuid</strong></span>
 </h2></div></div></div>
 <p>
           On UNIX servers, it is possible to run <acronym class="acronym">BIND</acronym>
@@ -144,7 +144,7 @@ zone "example.com" {
         </p>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2594033"></a>The <span><strong class="command">chroot</strong></span> Environment</h3></div></div></div>
+<a name="id2594039"></a>The <span><strong class="command">chroot</strong></span> Environment</h3></div></div></div>
 <p>
             In order for a <span><strong class="command">chroot</strong></span> environment
             to
@@ -172,7 +172,7 @@ zone "example.com" {
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2594092"></a>Using the <span><strong class="command">setuid</strong></span> Function</h3></div></div></div>
+<a name="id2594099"></a>Using the <span><strong class="command">setuid</strong></span> Function</h3></div></div></div>
 <p>
             Prior to running the <span><strong class="command">named</strong></span> daemon,
             use

contrib/bind9/doc/arm/Bv9ARM.ch08.html

@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: Bv9ARM.ch08.html,v 1.75.18.85 2009/09/25 01:33:41 tbox Exp $ -->
+<!-- $Id: Bv9ARM.ch08.html,v 1.75.18.87 2010/02/27 01:33:45 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -45,18 +45,18 @@
 <div class="toc">
 <p><b>Table of Contents</b></p>
 <dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2594241">Common Problems</a></span></dt>
-<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch08.html#id2594246">It's not working; how can I figure out what's wrong?</a></span></dt></dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2594258">Incrementing and Changing the Serial Number</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2594343">Where Can I Get Help?</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2594247">Common Problems</a></span></dt>
+<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch08.html#id2594252">It's not working; how can I figure out what's wrong?</a></span></dt></dl></dd>
+<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2594264">Incrementing and Changing the Serial Number</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2594281">Where Can I Get Help?</a></span></dt>
 </dl>
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2594241"></a>Common Problems</h2></div></div></div>
+<a name="id2594247"></a>Common Problems</h2></div></div></div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2594246"></a>It's not working; how can I figure out what's wrong?</h3></div></div></div>
+<a name="id2594252"></a>It's not working; how can I figure out what's wrong?</h3></div></div></div>
 <p>
             The best solution to solving installation and
             configuration issues is to take preventative measures by setting
@@ -68,7 +68,7 @@
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2594258"></a>Incrementing and Changing the Serial Number</h2></div></div></div>
+<a name="id2594264"></a>Incrementing and Changing the Serial Number</h2></div></div></div>
 <p>
           Zone serial numbers are just numbers &#8212; they aren't
           date related.  A lot of people set them to a number that
@@ -95,7 +95,7 @@
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2594343"></a>Where Can I Get Help?</h2></div></div></div>
+<a name="id2594281"></a>Where Can I Get Help?</h2></div></div></div>
 <p>
           The Internet Systems Consortium
           (<acronym class="acronym">ISC</acronym>) offers a wide range

contrib/bind9/doc/arm/Bv9ARM.ch09.html

@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: Bv9ARM.ch09.html,v 1.75.18.88 2009/09/25 01:33:40 tbox Exp $ -->
+<!-- $Id: Bv9ARM.ch09.html,v 1.75.18.90 2010/02/27 01:33:43 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -45,21 +45,21 @@
 <div class="toc">
 <p><b>Table of Contents</b></p>
 <dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch09.html#id2594405">Acknowledgments</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch09.html#id2594480">Acknowledgments</a></span></dt>
 <dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch09.html#historical_dns_information">A Brief History of the <acronym class="acronym">DNS</acronym> and <acronym class="acronym">BIND</acronym></a></span></dt></dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch09.html#id2594645">General <acronym class="acronym">DNS</acronym> Reference Information</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch09.html#id2594651">General <acronym class="acronym">DNS</acronym> Reference Information</a></span></dt>
 <dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch09.html#ipv6addresses">IPv6 addresses (AAAA)</a></span></dt></dl></dd>
 <dt><span class="sect1"><a href="Bv9ARM.ch09.html#bibliography">Bibliography (and Suggested Reading)</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="Bv9ARM.ch09.html#rfcs">Request for Comments (RFCs)</a></span></dt>
 <dt><span class="sect2"><a href="Bv9ARM.ch09.html#internet_drafts">Internet Drafts</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch09.html#id2597993">Other Documents About <acronym class="acronym">BIND</acronym></a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch09.html#id2598000">Other Documents About <acronym class="acronym">BIND</acronym></a></span></dt>
 </dl></dd>
 </dl>
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2594405"></a>Acknowledgments</h2></div></div></div>
+<a name="id2594480"></a>Acknowledgments</h2></div></div></div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="historical_dns_information"></a>A Brief History of the <acronym class="acronym">DNS</acronym> and <acronym class="acronym">BIND</acronym>
@@ -162,7 +162,7 @@
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2594645"></a>General <acronym class="acronym">DNS</acronym> Reference Information</h2></div></div></div>
+<a name="id2594651"></a>General <acronym class="acronym">DNS</acronym> Reference Information</h2></div></div></div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="ipv6addresses"></a>IPv6 addresses (AAAA)</h3></div></div></div>
@@ -250,17 +250,17 @@
           </p>
 <div class="bibliography">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2594901"></a>Bibliography</h4></div></div></div>
+<a name="id2594907"></a>Bibliography</h4></div></div></div>
 <div class="bibliodiv">
 <h3 class="title">Standards</h3>
 <div class="biblioentry">
-<a name="id2594912"></a><p>[<abbr class="abbrev">RFC974</abbr>] <span class="author"><span class="firstname">C.</span> <span class="surname">Partridge</span>. </span><span class="title"><i>Mail Routing and the Domain System</i>. </span><span class="pubdate">January 1986. </span></p>
+<a name="id2594918"></a><p>[<abbr class="abbrev">RFC974</abbr>] <span class="author"><span class="firstname">C.</span> <span class="surname">Partridge</span>. </span><span class="title"><i>Mail Routing and the Domain System</i>. </span><span class="pubdate">January 1986. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2594935"></a><p>[<abbr class="abbrev">RFC1034</abbr>] <span class="author"><span class="firstname">P.V.</span> <span class="surname">Mockapetris</span>. </span><span class="title"><i>Domain Names &#8212; Concepts and Facilities</i>. </span><span class="pubdate">November 1987. </span></p>
+<a name="id2594941"></a><p>[<abbr class="abbrev">RFC1034</abbr>] <span class="author"><span class="firstname">P.V.</span> <span class="surname">Mockapetris</span>. </span><span class="title"><i>Domain Names &#8212; Concepts and Facilities</i>. </span><span class="pubdate">November 1987. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2594958"></a><p>[<abbr class="abbrev">RFC1035</abbr>] <span class="author"><span class="firstname">P. V.</span> <span class="surname">Mockapetris</span>. </span><span class="title"><i>Domain Names &#8212; Implementation and
+<a name="id2594965"></a><p>[<abbr class="abbrev">RFC1035</abbr>] <span class="author"><span class="firstname">P. V.</span> <span class="surname">Mockapetris</span>. </span><span class="title"><i>Domain Names &#8212; Implementation and
                   Specification</i>. </span><span class="pubdate">November 1987. </span></p>
 </div>
 </div>
@@ -268,42 +268,42 @@
 <h3 class="title">
 <a name="proposed_standards"></a>Proposed Standards</h3>
 <div class="biblioentry">
-<a name="id2594995"></a><p>[<abbr class="abbrev">RFC2181</abbr>] <span class="author"><span class="firstname">R., R. Bush</span> <span class="surname">Elz</span>. </span><span class="title"><i>Clarifications to the <acronym class="acronym">DNS</acronym>
+<a name="id2595001"></a><p>[<abbr class="abbrev">RFC2181</abbr>] <span class="author"><span class="firstname">R., R. Bush</span> <span class="surname">Elz</span>. </span><span class="title"><i>Clarifications to the <acronym class="acronym">DNS</acronym>
                   Specification</i>. </span><span class="pubdate">July 1997. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2595021"></a><p>[<abbr class="abbrev">RFC2308</abbr>] <span class="author"><span class="firstname">M.</span> <span class="surname">Andrews</span>. </span><span class="title"><i>Negative Caching of <acronym class="acronym">DNS</acronym>
+<a name="id2595028"></a><p>[<abbr class="abbrev">RFC2308</abbr>] <span class="author"><span class="firstname">M.</span> <span class="surname">Andrews</span>. </span><span class="title"><i>Negative Caching of <acronym class="acronym">DNS</acronym>
                   Queries</i>. </span><span class="pubdate">March 1998. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2595047"></a><p>[<abbr class="abbrev">RFC1995</abbr>] <span class="author"><span class="firstname">M.</span> <span class="surname">Ohta</span>. </span><span class="title"><i>Incremental Zone Transfer in <acronym class="acronym">DNS</acronym></i>. </span><span class="pubdate">August 1996. </span></p>
+<a name="id2595053"></a><p>[<abbr class="abbrev">RFC1995</abbr>] <span class="author"><span class="firstname">M.</span> <span class="surname">Ohta</span>. </span><span class="title"><i>Incremental Zone Transfer in <acronym class="acronym">DNS</acronym></i>. </span><span class="pubdate">August 1996. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2595072"></a><p>[<abbr class="abbrev">RFC1996</abbr>] <span class="author"><span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="title"><i>A Mechanism for Prompt Notification of Zone Changes</i>. </span><span class="pubdate">August 1996. </span></p>
+<a name="id2595078"></a><p>[<abbr class="abbrev">RFC1996</abbr>] <span class="author"><span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="title"><i>A Mechanism for Prompt Notification of Zone Changes</i>. </span><span class="pubdate">August 1996. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2595095"></a><p>[<abbr class="abbrev">RFC2136</abbr>] <span class="authorgroup"><span class="firstname">P.</span> <span class="surname">Vixie</span>, <span class="firstname">S.</span> <span class="surname">Thomson</span>, <span class="firstname">Y.</span> <span class="surname">Rekhter</span>, and <span class="firstname">J.</span> <span class="surname">Bound</span>. </span><span class="title"><i>Dynamic Updates in the Domain Name System</i>. </span><span class="pubdate">April 1997. </span></p>
+<a name="id2595101"></a><p>[<abbr class="abbrev">RFC2136</abbr>] <span class="authorgroup"><span class="firstname">P.</span> <span class="surname">Vixie</span>, <span class="firstname">S.</span> <span class="surname">Thomson</span>, <span class="firstname">Y.</span> <span class="surname">Rekhter</span>, and <span class="firstname">J.</span> <span class="surname">Bound</span>. </span><span class="title"><i>Dynamic Updates in the Domain Name System</i>. </span><span class="pubdate">April 1997. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2595150"></a><p>[<abbr class="abbrev">RFC2671</abbr>] <span class="authorgroup"><span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="title"><i>Extension Mechanisms for DNS (EDNS0)</i>. </span><span class="pubdate">August 1997. </span></p>
+<a name="id2595157"></a><p>[<abbr class="abbrev">RFC2671</abbr>] <span class="authorgroup"><span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="title"><i>Extension Mechanisms for DNS (EDNS0)</i>. </span><span class="pubdate">August 1997. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2595177"></a><p>[<abbr class="abbrev">RFC2672</abbr>] <span class="authorgroup"><span class="firstname">M.</span> <span class="surname">Crawford</span>. </span><span class="title"><i>Non-Terminal DNS Name Redirection</i>. </span><span class="pubdate">August 1999. </span></p>
+<a name="id2595184"></a><p>[<abbr class="abbrev">RFC2672</abbr>] <span class="authorgroup"><span class="firstname">M.</span> <span class="surname">Crawford</span>. </span><span class="title"><i>Non-Terminal DNS Name Redirection</i>. </span><span class="pubdate">August 1999. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2595204"></a><p>[<abbr class="abbrev">RFC2845</abbr>] <span class="authorgroup"><span class="firstname">P.</span> <span class="surname">Vixie</span>, <span class="firstname">O.</span> <span class="surname">Gudmundsson</span>, <span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>, and <span class="firstname">B.</span> <span class="surname">Wellington</span>. </span><span class="title"><i>Secret Key Transaction Authentication for <acronym class="acronym">DNS</acronym> (TSIG)</i>. </span><span class="pubdate">May 2000. </span></p>
+<a name="id2595210"></a><p>[<abbr class="abbrev">RFC2845</abbr>] <span class="authorgroup"><span class="firstname">P.</span> <span class="surname">Vixie</span>, <span class="firstname">O.</span> <span class="surname">Gudmundsson</span>, <span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>, and <span class="firstname">B.</span> <span class="surname">Wellington</span>. </span><span class="title"><i>Secret Key Transaction Authentication for <acronym class="acronym">DNS</acronym> (TSIG)</i>. </span><span class="pubdate">May 2000. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2595266"></a><p>[<abbr class="abbrev">RFC2930</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>Secret Key Establishment for DNS (TKEY RR)</i>. </span><span class="pubdate">September 2000. </span></p>
+<a name="id2595272"></a><p>[<abbr class="abbrev">RFC2930</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>Secret Key Establishment for DNS (TKEY RR)</i>. </span><span class="pubdate">September 2000. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2595296"></a><p>[<abbr class="abbrev">RFC2931</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>DNS Request and Transaction Signatures (SIG(0)s)</i>. </span><span class="pubdate">September 2000. </span></p>
+<a name="id2595302"></a><p>[<abbr class="abbrev">RFC2931</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>DNS Request and Transaction Signatures (SIG(0)s)</i>. </span><span class="pubdate">September 2000. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2595325"></a><p>[<abbr class="abbrev">RFC3007</abbr>] <span class="authorgroup"><span class="firstname">B.</span> <span class="surname">Wellington</span>. </span><span class="title"><i>Secure Domain Name System (DNS) Dynamic Update</i>. </span><span class="pubdate">November 2000. </span></p>
+<a name="id2595332"></a><p>[<abbr class="abbrev">RFC3007</abbr>] <span class="authorgroup"><span class="firstname">B.</span> <span class="surname">Wellington</span>. </span><span class="title"><i>Secure Domain Name System (DNS) Dynamic Update</i>. </span><span class="pubdate">November 2000. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2595352"></a><p>[<abbr class="abbrev">RFC3645</abbr>] <span class="authorgroup"><span class="firstname">S.</span> <span class="surname">Kwan</span>, <span class="firstname">P.</span> <span class="surname">Garg</span>, <span class="firstname">J.</span> <span class="surname">Gilroy</span>, <span class="firstname">L.</span> <span class="surname">Esibov</span>, <span class="firstname">J.</span> <span class="surname">Westhead</span>, and <span class="firstname">R.</span> <span class="surname">Hall</span>. </span><span class="title"><i>Generic Security Service Algorithm for Secret
+<a name="id2595358"></a><p>[<abbr class="abbrev">RFC3645</abbr>] <span class="authorgroup"><span class="firstname">S.</span> <span class="surname">Kwan</span>, <span class="firstname">P.</span> <span class="surname">Garg</span>, <span class="firstname">J.</span> <span class="surname">Gilroy</span>, <span class="firstname">L.</span> <span class="surname">Esibov</span>, <span class="firstname">J.</span> <span class="surname">Westhead</span>, and <span class="firstname">R.</span> <span class="surname">Hall</span>. </span><span class="title"><i>Generic Security Service Algorithm for Secret
                        Key Transaction Authentication for DNS
                        (GSS-TSIG)</i>. </span><span class="pubdate">October 2003. </span></p>
 </div>
@@ -312,19 +312,19 @@
 <h3 class="title">
 <acronym class="acronym">DNS</acronym> Security Proposed Standards</h3>
 <div class="biblioentry">
-<a name="id2595434"></a><p>[<abbr class="abbrev">RFC3225</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Conrad</span>. </span><span class="title"><i>Indicating Resolver Support of DNSSEC</i>. </span><span class="pubdate">December 2001. </span></p>
+<a name="id2595441"></a><p>[<abbr class="abbrev">RFC3225</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Conrad</span>. </span><span class="title"><i>Indicating Resolver Support of DNSSEC</i>. </span><span class="pubdate">December 2001. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2595461"></a><p>[<abbr class="abbrev">RFC3833</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Atkins</span> and <span class="firstname">R.</span> <span class="surname">Austein</span>. </span><span class="title"><i>Threat Analysis of the Domain Name System (DNS)</i>. </span><span class="pubdate">August 2004. </span></p>
+<a name="id2595467"></a><p>[<abbr class="abbrev">RFC3833</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Atkins</span> and <span class="firstname">R.</span> <span class="surname">Austein</span>. </span><span class="title"><i>Threat Analysis of the Domain Name System (DNS)</i>. </span><span class="pubdate">August 2004. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2595497"></a><p>[<abbr class="abbrev">RFC4033</abbr>] <span class="authorgroup"><span class="firstname">R.</span> <span class="surname">Arends</span>, <span class="firstname">R.</span> <span class="surname">Austein</span>, <span class="firstname">M.</span> <span class="surname">Larson</span>, <span class="firstname">D.</span> <span class="surname">Massey</span>, and <span class="firstname">S.</span> <span class="surname">Rose</span>. </span><span class="title"><i>DNS Security Introduction and Requirements</i>. </span><span class="pubdate">March 2005. </span></p>
+<a name="id2595504"></a><p>[<abbr class="abbrev">RFC4033</abbr>] <span class="authorgroup"><span class="firstname">R.</span> <span class="surname">Arends</span>, <span class="firstname">R.</span> <span class="surname">Austein</span>, <span class="firstname">M.</span> <span class="surname">Larson</span>, <span class="firstname">D.</span> <span class="surname">Massey</span>, and <span class="firstname">S.</span> <span class="surname">Rose</span>. </span><span class="title"><i>DNS Security Introduction and Requirements</i>. </span><span class="pubdate">March 2005. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2595562"></a><p>[<abbr class="abbrev">RFC4034</abbr>] <span class="authorgroup"><span class="firstname">R.</span> <span class="surname">Arends</span>, <span class="firstname">R.</span> <span class="surname">Austein</span>, <span class="firstname">M.</span> <span class="surname">Larson</span>, <span class="firstname">D.</span> <span class="surname">Massey</span>, and <span class="firstname">S.</span> <span class="surname">Rose</span>. </span><span class="title"><i>Resource Records for the DNS Security Extensions</i>. </span><span class="pubdate">March 2005. </span></p>
+<a name="id2595569"></a><p>[<abbr class="abbrev">RFC4034</abbr>] <span class="authorgroup"><span class="firstname">R.</span> <span class="surname">Arends</span>, <span class="firstname">R.</span> <span class="surname">Austein</span>, <span class="firstname">M.</span> <span class="surname">Larson</span>, <span class="firstname">D.</span> <span class="surname">Massey</span>, and <span class="firstname">S.</span> <span class="surname">Rose</span>. </span><span class="title"><i>Resource Records for the DNS Security Extensions</i>. </span><span class="pubdate">March 2005. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2595627"></a><p>[<abbr class="abbrev">RFC4035</abbr>] <span class="authorgroup"><span class="firstname">R.</span> <span class="surname">Arends</span>, <span class="firstname">R.</span> <span class="surname">Austein</span>, <span class="firstname">M.</span> <span class="surname">Larson</span>, <span class="firstname">D.</span> <span class="surname">Massey</span>, and <span class="firstname">S.</span> <span class="surname">Rose</span>. </span><span class="title"><i>Protocol Modifications for the DNS
+<a name="id2595634"></a><p>[<abbr class="abbrev">RFC4035</abbr>] <span class="authorgroup"><span class="firstname">R.</span> <span class="surname">Arends</span>, <span class="firstname">R.</span> <span class="surname">Austein</span>, <span class="firstname">M.</span> <span class="surname">Larson</span>, <span class="firstname">D.</span> <span class="surname">Massey</span>, and <span class="firstname">S.</span> <span class="surname">Rose</span>. </span><span class="title"><i>Protocol Modifications for the DNS
                        Security Extensions</i>. </span><span class="pubdate">March 2005. </span></p>
 </div>
 </div>
@@ -332,146 +332,146 @@
 <h3 class="title">Other Important RFCs About <acronym class="acronym">DNS</acronym>
                 Implementation</h3>
 <div class="biblioentry">
-<a name="id2595701"></a><p>[<abbr class="abbrev">RFC1535</abbr>] <span class="author"><span class="firstname">E.</span> <span class="surname">Gavron</span>. </span><span class="title"><i>A Security Problem and Proposed Correction With Widely
+<a name="id2595707"></a><p>[<abbr class="abbrev">RFC1535</abbr>] <span class="author"><span class="firstname">E.</span> <span class="surname">Gavron</span>. </span><span class="title"><i>A Security Problem and Proposed Correction With Widely
                   Deployed <acronym class="acronym">DNS</acronym> Software.</i>. </span><span class="pubdate">October 1993. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2595726"></a><p>[<abbr class="abbrev">RFC1536</abbr>] <span class="authorgroup"><span class="firstname">A.</span> <span class="surname">Kumar</span>, <span class="firstname">J.</span> <span class="surname">Postel</span>, <span class="firstname">C.</span> <span class="surname">Neuman</span>, <span class="firstname">P.</span> <span class="surname">Danzig</span>, and <span class="firstname">S.</span> <span class="surname">Miller</span>. </span><span class="title"><i>Common <acronym class="acronym">DNS</acronym> Implementation
+<a name="id2595733"></a><p>[<abbr class="abbrev">RFC1536</abbr>] <span class="authorgroup"><span class="firstname">A.</span> <span class="surname">Kumar</span>, <span class="firstname">J.</span> <span class="surname">Postel</span>, <span class="firstname">C.</span> <span class="surname">Neuman</span>, <span class="firstname">P.</span> <span class="surname">Danzig</span>, and <span class="firstname">S.</span> <span class="surname">Miller</span>. </span><span class="title"><i>Common <acronym class="acronym">DNS</acronym> Implementation
                   Errors and Suggested Fixes</i>. </span><span class="pubdate">October 1993. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2595795"></a><p>[<abbr class="abbrev">RFC1982</abbr>] <span class="authorgroup"><span class="firstname">R.</span> <span class="surname">Elz</span> and <span class="firstname">R.</span> <span class="surname">Bush</span>. </span><span class="title"><i>Serial Number Arithmetic</i>. </span><span class="pubdate">August 1996. </span></p>
+<a name="id2595801"></a><p>[<abbr class="abbrev">RFC1982</abbr>] <span class="authorgroup"><span class="firstname">R.</span> <span class="surname">Elz</span> and <span class="firstname">R.</span> <span class="surname">Bush</span>. </span><span class="title"><i>Serial Number Arithmetic</i>. </span><span class="pubdate">August 1996. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2595830"></a><p>[<abbr class="abbrev">RFC4074</abbr>] <span class="authorgroup"><span class="firstname">Y.</span> <span class="surname">Morishita</span> and <span class="firstname">T.</span> <span class="surname">Jinmei</span>. </span><span class="title"><i>Common Misbehaviour Against <acronym class="acronym">DNS</acronym>
+<a name="id2595836"></a><p>[<abbr class="abbrev">RFC4074</abbr>] <span class="authorgroup"><span class="firstname">Y.</span> <span class="surname">Morishita</span> and <span class="firstname">T.</span> <span class="surname">Jinmei</span>. </span><span class="title"><i>Common Misbehaviour Against <acronym class="acronym">DNS</acronym>
                 Queries for IPv6 Addresses</i>. </span><span class="pubdate">May 2005. </span></p>
 </div>
 </div>
 <div class="bibliodiv">
 <h3 class="title">Resource Record Types</h3>
 <div class="biblioentry">
-<a name="id2595876"></a><p>[<abbr class="abbrev">RFC1183</abbr>] <span class="authorgroup"><span class="firstname">C.F.</span> <span class="surname">Everhart</span>, <span class="firstname">L. A.</span> <span class="surname">Mamakos</span>, <span class="firstname">R.</span> <span class="surname">Ullmann</span>, and <span class="firstname">P.</span> <span class="surname">Mockapetris</span>. </span><span class="title"><i>New <acronym class="acronym">DNS</acronym> RR Definitions</i>. </span><span class="pubdate">October 1990. </span></p>
+<a name="id2595882"></a><p>[<abbr class="abbrev">RFC1183</abbr>] <span class="authorgroup"><span class="firstname">C.F.</span> <span class="surname">Everhart</span>, <span class="firstname">L. A.</span> <span class="surname">Mamakos</span>, <span class="firstname">R.</span> <span class="surname">Ullmann</span>, and <span class="firstname">P.</span> <span class="surname">Mockapetris</span>. </span><span class="title"><i>New <acronym class="acronym">DNS</acronym> RR Definitions</i>. </span><span class="pubdate">October 1990. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2596002"></a><p>[<abbr class="abbrev">RFC1706</abbr>] <span class="authorgroup"><span class="firstname">B.</span> <span class="surname">Manning</span> and <span class="firstname">R.</span> <span class="surname">Colella</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> NSAP Resource Records</i>. </span><span class="pubdate">October 1994. </span></p>
+<a name="id2596008"></a><p>[<abbr class="abbrev">RFC1706</abbr>] <span class="authorgroup"><span class="firstname">B.</span> <span class="surname">Manning</span> and <span class="firstname">R.</span> <span class="surname">Colella</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> NSAP Resource Records</i>. </span><span class="pubdate">October 1994. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2596039"></a><p>[<abbr class="abbrev">RFC2168</abbr>] <span class="authorgroup"><span class="firstname">R.</span> <span class="surname">Daniel</span> and <span class="firstname">M.</span> <span class="surname">Mealling</span>. </span><span class="title"><i>Resolution of Uniform Resource Identifiers using
+<a name="id2596045"></a><p>[<abbr class="abbrev">RFC2168</abbr>] <span class="authorgroup"><span class="firstname">R.</span> <span class="surname">Daniel</span> and <span class="firstname">M.</span> <span class="surname">Mealling</span>. </span><span class="title"><i>Resolution of Uniform Resource Identifiers using
                   the Domain Name System</i>. </span><span class="pubdate">June 1997. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2596074"></a><p>[<abbr class="abbrev">RFC1876</abbr>] <span class="authorgroup"><span class="firstname">C.</span> <span class="surname">Davis</span>, <span class="firstname">P.</span> <span class="surname">Vixie</span>, <span class="firstname">T.</span>, and <span class="firstname">I.</span> <span class="surname">Dickinson</span>. </span><span class="title"><i>A Means for Expressing Location Information in the
+<a name="id2596081"></a><p>[<abbr class="abbrev">RFC1876</abbr>] <span class="authorgroup"><span class="firstname">C.</span> <span class="surname">Davis</span>, <span class="firstname">P.</span> <span class="surname">Vixie</span>, <span class="firstname">T.</span>, and <span class="firstname">I.</span> <span class="surname">Dickinson</span>. </span><span class="title"><i>A Means for Expressing Location Information in the
                   Domain
                   Name System</i>. </span><span class="pubdate">January 1996. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2596129"></a><p>[<abbr class="abbrev">RFC2052</abbr>] <span class="authorgroup"><span class="firstname">A.</span> <span class="surname">Gulbrandsen</span> and <span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="title"><i>A <acronym class="acronym">DNS</acronym> RR for Specifying the
+<a name="id2596135"></a><p>[<abbr class="abbrev">RFC2052</abbr>] <span class="authorgroup"><span class="firstname">A.</span> <span class="surname">Gulbrandsen</span> and <span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="title"><i>A <acronym class="acronym">DNS</acronym> RR for Specifying the
                   Location of
                   Services.</i>. </span><span class="pubdate">October 1996. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2596167"></a><p>[<abbr class="abbrev">RFC2163</abbr>] <span class="author"><span class="firstname">A.</span> <span class="surname">Allocchio</span>. </span><span class="title"><i>Using the Internet <acronym class="acronym">DNS</acronym> to
+<a name="id2596173"></a><p>[<abbr class="abbrev">RFC2163</abbr>] <span class="author"><span class="firstname">A.</span> <span class="surname">Allocchio</span>. </span><span class="title"><i>Using the Internet <acronym class="acronym">DNS</acronym> to
                   Distribute MIXER
                   Conformant Global Address Mapping</i>. </span><span class="pubdate">January 1998. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2596193"></a><p>[<abbr class="abbrev">RFC2230</abbr>] <span class="author"><span class="firstname">R.</span> <span class="surname">Atkinson</span>. </span><span class="title"><i>Key Exchange Delegation Record for the <acronym class="acronym">DNS</acronym></i>. </span><span class="pubdate">October 1997. </span></p>
+<a name="id2596199"></a><p>[<abbr class="abbrev">RFC2230</abbr>] <span class="author"><span class="firstname">R.</span> <span class="surname">Atkinson</span>. </span><span class="title"><i>Key Exchange Delegation Record for the <acronym class="acronym">DNS</acronym></i>. </span><span class="pubdate">October 1997. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2596218"></a><p>[<abbr class="abbrev">RFC2536</abbr>] <span class="author"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>DSA KEYs and SIGs in the Domain Name System (DNS)</i>. </span><span class="pubdate">March 1999. </span></p>
+<a name="id2596225"></a><p>[<abbr class="abbrev">RFC2536</abbr>] <span class="author"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>DSA KEYs and SIGs in the Domain Name System (DNS)</i>. </span><span class="pubdate">March 1999. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2596245"></a><p>[<abbr class="abbrev">RFC2537</abbr>] <span class="author"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>RSA/MD5 KEYs and SIGs in the Domain Name System (DNS)</i>. </span><span class="pubdate">March 1999. </span></p>
+<a name="id2596251"></a><p>[<abbr class="abbrev">RFC2537</abbr>] <span class="author"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>RSA/MD5 KEYs and SIGs in the Domain Name System (DNS)</i>. </span><span class="pubdate">March 1999. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2596272"></a><p>[<abbr class="abbrev">RFC2538</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span> and <span class="firstname">O.</span> <span class="surname">Gudmundsson</span>. </span><span class="title"><i>Storing Certificates in the Domain Name System (DNS)</i>. </span><span class="pubdate">March 1999. </span></p>
+<a name="id2596278"></a><p>[<abbr class="abbrev">RFC2538</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span> and <span class="firstname">O.</span> <span class="surname">Gudmundsson</span>. </span><span class="title"><i>Storing Certificates in the Domain Name System (DNS)</i>. </span><span class="pubdate">March 1999. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2596311"></a><p>[<abbr class="abbrev">RFC2539</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>Storage of Diffie-Hellman Keys in the Domain Name System (DNS)</i>. </span><span class="pubdate">March 1999. </span></p>
+<a name="id2596317"></a><p>[<abbr class="abbrev">RFC2539</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>Storage of Diffie-Hellman Keys in the Domain Name System (DNS)</i>. </span><span class="pubdate">March 1999. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2596341"></a><p>[<abbr class="abbrev">RFC2540</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>Detached Domain Name System (DNS) Information</i>. </span><span class="pubdate">March 1999. </span></p>
+<a name="id2596347"></a><p>[<abbr class="abbrev">RFC2540</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>Detached Domain Name System (DNS) Information</i>. </span><span class="pubdate">March 1999. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2596371"></a><p>[<abbr class="abbrev">RFC2782</abbr>] <span class="author"><span class="firstname">A.</span> <span class="surname">Gulbrandsen</span>. </span><span class="author"><span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="author"><span class="firstname">L.</span> <span class="surname">Esibov</span>. </span><span class="title"><i>A DNS RR for specifying the location of services (DNS SRV)</i>. </span><span class="pubdate">February 2000. </span></p>
+<a name="id2596377"></a><p>[<abbr class="abbrev">RFC2782</abbr>] <span class="author"><span class="firstname">A.</span> <span class="surname">Gulbrandsen</span>. </span><span class="author"><span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="author"><span class="firstname">L.</span> <span class="surname">Esibov</span>. </span><span class="title"><i>A DNS RR for specifying the location of services (DNS SRV)</i>. </span><span class="pubdate">February 2000. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2596413"></a><p>[<abbr class="abbrev">RFC2915</abbr>] <span class="author"><span class="firstname">M.</span> <span class="surname">Mealling</span>. </span><span class="author"><span class="firstname">R.</span> <span class="surname">Daniel</span>. </span><span class="title"><i>The Naming Authority Pointer (NAPTR) DNS Resource Record</i>. </span><span class="pubdate">September 2000. </span></p>
+<a name="id2596420"></a><p>[<abbr class="abbrev">RFC2915</abbr>] <span class="author"><span class="firstname">M.</span> <span class="surname">Mealling</span>. </span><span class="author"><span class="firstname">R.</span> <span class="surname">Daniel</span>. </span><span class="title"><i>The Naming Authority Pointer (NAPTR) DNS Resource Record</i>. </span><span class="pubdate">September 2000. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2596446"></a><p>[<abbr class="abbrev">RFC3110</abbr>] <span class="author"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)</i>. </span><span class="pubdate">May 2001. </span></p>
+<a name="id2596453"></a><p>[<abbr class="abbrev">RFC3110</abbr>] <span class="author"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)</i>. </span><span class="pubdate">May 2001. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2596473"></a><p>[<abbr class="abbrev">RFC3123</abbr>] <span class="author"><span class="firstname">P.</span> <span class="surname">Koch</span>. </span><span class="title"><i>A DNS RR Type for Lists of Address Prefixes (APL RR)</i>. </span><span class="pubdate">June 2001. </span></p>
+<a name="id2596480"></a><p>[<abbr class="abbrev">RFC3123</abbr>] <span class="author"><span class="firstname">P.</span> <span class="surname">Koch</span>. </span><span class="title"><i>A DNS RR Type for Lists of Address Prefixes (APL RR)</i>. </span><span class="pubdate">June 2001. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2596497"></a><p>[<abbr class="abbrev">RFC3596</abbr>] <span class="authorgroup"><span class="firstname">S.</span> <span class="surname">Thomson</span>, <span class="firstname">C.</span> <span class="surname">Huitema</span>, <span class="firstname">V.</span> <span class="surname">Ksinant</span>, and <span class="firstname">M.</span> <span class="surname">Souissi</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> Extensions to support IP
+<a name="id2596503"></a><p>[<abbr class="abbrev">RFC3596</abbr>] <span class="authorgroup"><span class="firstname">S.</span> <span class="surname">Thomson</span>, <span class="firstname">C.</span> <span class="surname">Huitema</span>, <span class="firstname">V.</span> <span class="surname">Ksinant</span>, and <span class="firstname">M.</span> <span class="surname">Souissi</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> Extensions to support IP
                   version 6</i>. </span><span class="pubdate">October 2003. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2596554"></a><p>[<abbr class="abbrev">RFC3597</abbr>] <span class="author"><span class="firstname">A.</span> <span class="surname">Gustafsson</span>. </span><span class="title"><i>Handling of Unknown DNS Resource Record (RR) Types</i>. </span><span class="pubdate">September 2003. </span></p>
+<a name="id2596561"></a><p>[<abbr class="abbrev">RFC3597</abbr>] <span class="author"><span class="firstname">A.</span> <span class="surname">Gustafsson</span>. </span><span class="title"><i>Handling of Unknown DNS Resource Record (RR) Types</i>. </span><span class="pubdate">September 2003. </span></p>
 </div>
 </div>
 <div class="bibliodiv">
 <h3 class="title">
 <acronym class="acronym">DNS</acronym> and the Internet</h3>
 <div class="biblioentry">
-<a name="id2596586"></a><p>[<abbr class="abbrev">RFC1101</abbr>] <span class="author"><span class="firstname">P. V.</span> <span class="surname">Mockapetris</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> Encoding of Network Names
+<a name="id2596593"></a><p>[<abbr class="abbrev">RFC1101</abbr>] <span class="author"><span class="firstname">P. V.</span> <span class="surname">Mockapetris</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> Encoding of Network Names
                   and Other Types</i>. </span><span class="pubdate">April 1989. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2596612"></a><p>[<abbr class="abbrev">RFC1123</abbr>] <span class="author"><span class="surname">Braden</span>. </span><span class="title"><i>Requirements for Internet Hosts - Application and
+<a name="id2596618"></a><p>[<abbr class="abbrev">RFC1123</abbr>] <span class="author"><span class="surname">Braden</span>. </span><span class="title"><i>Requirements for Internet Hosts - Application and
                   Support</i>. </span><span class="pubdate">October 1989. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2596634"></a><p>[<abbr class="abbrev">RFC1591</abbr>] <span class="author"><span class="firstname">J.</span> <span class="surname">Postel</span>. </span><span class="title"><i>Domain Name System Structure and Delegation</i>. </span><span class="pubdate">March 1994. </span></p>
+<a name="id2596641"></a><p>[<abbr class="abbrev">RFC1591</abbr>] <span class="author"><span class="firstname">J.</span> <span class="surname">Postel</span>. </span><span class="title"><i>Domain Name System Structure and Delegation</i>. </span><span class="pubdate">March 1994. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2596658"></a><p>[<abbr class="abbrev">RFC2317</abbr>] <span class="authorgroup"><span class="firstname">H.</span> <span class="surname">Eidnes</span>, <span class="firstname">G.</span> <span class="surname">de Groot</span>, and <span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="title"><i>Classless IN-ADDR.ARPA Delegation</i>. </span><span class="pubdate">March 1998. </span></p>
+<a name="id2596664"></a><p>[<abbr class="abbrev">RFC2317</abbr>] <span class="authorgroup"><span class="firstname">H.</span> <span class="surname">Eidnes</span>, <span class="firstname">G.</span> <span class="surname">de Groot</span>, and <span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="title"><i>Classless IN-ADDR.ARPA Delegation</i>. </span><span class="pubdate">March 1998. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2596704"></a><p>[<abbr class="abbrev">RFC2826</abbr>] <span class="authorgroup"><span class="surname">Internet Architecture Board</span>. </span><span class="title"><i>IAB Technical Comment on the Unique DNS Root</i>. </span><span class="pubdate">May 2000. </span></p>
+<a name="id2596710"></a><p>[<abbr class="abbrev">RFC2826</abbr>] <span class="authorgroup"><span class="surname">Internet Architecture Board</span>. </span><span class="title"><i>IAB Technical Comment on the Unique DNS Root</i>. </span><span class="pubdate">May 2000. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2596727"></a><p>[<abbr class="abbrev">RFC2929</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>, <span class="firstname">E.</span> <span class="surname">Brunner-Williams</span>, and <span class="firstname">B.</span> <span class="surname">Manning</span>. </span><span class="title"><i>Domain Name System (DNS) IANA Considerations</i>. </span><span class="pubdate">September 2000. </span></p>
+<a name="id2596733"></a><p>[<abbr class="abbrev">RFC2929</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>, <span class="firstname">E.</span> <span class="surname">Brunner-Williams</span>, and <span class="firstname">B.</span> <span class="surname">Manning</span>. </span><span class="title"><i>Domain Name System (DNS) IANA Considerations</i>. </span><span class="pubdate">September 2000. </span></p>
 </div>
 </div>
 <div class="bibliodiv">
 <h3 class="title">
 <acronym class="acronym">DNS</acronym> Operations</h3>
 <div class="biblioentry">
-<a name="id2596785"></a><p>[<abbr class="abbrev">RFC1033</abbr>] <span class="author"><span class="firstname">M.</span> <span class="surname">Lottor</span>. </span><span class="title"><i>Domain administrators operations guide.</i>. </span><span class="pubdate">November 1987. </span></p>
+<a name="id2596791"></a><p>[<abbr class="abbrev">RFC1033</abbr>] <span class="author"><span class="firstname">M.</span> <span class="surname">Lottor</span>. </span><span class="title"><i>Domain administrators operations guide.</i>. </span><span class="pubdate">November 1987. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2596876"></a><p>[<abbr class="abbrev">RFC1537</abbr>] <span class="author"><span class="firstname">P.</span> <span class="surname">Beertema</span>. </span><span class="title"><i>Common <acronym class="acronym">DNS</acronym> Data File
+<a name="id2596883"></a><p>[<abbr class="abbrev">RFC1537</abbr>] <span class="author"><span class="firstname">P.</span> <span class="surname">Beertema</span>. </span><span class="title"><i>Common <acronym class="acronym">DNS</acronym> Data File
                   Configuration Errors</i>. </span><span class="pubdate">October 1993. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2596903"></a><p>[<abbr class="abbrev">RFC1912</abbr>] <span class="author"><span class="firstname">D.</span> <span class="surname">Barr</span>. </span><span class="title"><i>Common <acronym class="acronym">DNS</acronym> Operational and
+<a name="id2596909"></a><p>[<abbr class="abbrev">RFC1912</abbr>] <span class="author"><span class="firstname">D.</span> <span class="surname">Barr</span>. </span><span class="title"><i>Common <acronym class="acronym">DNS</acronym> Operational and
                   Configuration Errors</i>. </span><span class="pubdate">February 1996. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2596930"></a><p>[<abbr class="abbrev">RFC2010</abbr>] <span class="authorgroup"><span class="firstname">B.</span> <span class="surname">Manning</span> and <span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="title"><i>Operational Criteria for Root Name Servers.</i>. </span><span class="pubdate">October 1996. </span></p>
+<a name="id2596936"></a><p>[<abbr class="abbrev">RFC2010</abbr>] <span class="authorgroup"><span class="firstname">B.</span> <span class="surname">Manning</span> and <span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="title"><i>Operational Criteria for Root Name Servers.</i>. </span><span class="pubdate">October 1996. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2596966"></a><p>[<abbr class="abbrev">RFC2219</abbr>] <span class="authorgroup"><span class="firstname">M.</span> <span class="surname">Hamilton</span> and <span class="firstname">R.</span> <span class="surname">Wright</span>. </span><span class="title"><i>Use of <acronym class="acronym">DNS</acronym> Aliases for
+<a name="id2596972"></a><p>[<abbr class="abbrev">RFC2219</abbr>] <span class="authorgroup"><span class="firstname">M.</span> <span class="surname">Hamilton</span> and <span class="firstname">R.</span> <span class="surname">Wright</span>. </span><span class="title"><i>Use of <acronym class="acronym">DNS</acronym> Aliases for
                   Network Services.</i>. </span><span class="pubdate">October 1997. </span></p>
 </div>
 </div>
 <div class="bibliodiv">
 <h3 class="title">Internationalized Domain Names</h3>
 <div class="biblioentry">
-<a name="id2597012"></a><p>[<abbr class="abbrev">RFC2825</abbr>] <span class="authorgroup"><span class="surname">IAB</span> and <span class="firstname">R.</span> <span class="surname">Daigle</span>. </span><span class="title"><i>A Tangled Web: Issues of I18N, Domain Names,
+<a name="id2597018"></a><p>[<abbr class="abbrev">RFC2825</abbr>] <span class="authorgroup"><span class="surname">IAB</span> and <span class="firstname">R.</span> <span class="surname">Daigle</span>. </span><span class="title"><i>A Tangled Web: Issues of I18N, Domain Names,
                        and the Other Internet protocols</i>. </span><span class="pubdate">May 2000. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2597044"></a><p>[<abbr class="abbrev">RFC3490</abbr>] <span class="authorgroup"><span class="firstname">P.</span> <span class="surname">Faltstrom</span>, <span class="firstname">P.</span> <span class="surname">Hoffman</span>, and <span class="firstname">A.</span> <span class="surname">Costello</span>. </span><span class="title"><i>Internationalizing Domain Names in Applications (IDNA)</i>. </span><span class="pubdate">March 2003. </span></p>
+<a name="id2597050"></a><p>[<abbr class="abbrev">RFC3490</abbr>] <span class="authorgroup"><span class="firstname">P.</span> <span class="surname">Faltstrom</span>, <span class="firstname">P.</span> <span class="surname">Hoffman</span>, and <span class="firstname">A.</span> <span class="surname">Costello</span>. </span><span class="title"><i>Internationalizing Domain Names in Applications (IDNA)</i>. </span><span class="pubdate">March 2003. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2597090"></a><p>[<abbr class="abbrev">RFC3491</abbr>] <span class="authorgroup"><span class="firstname">P.</span> <span class="surname">Hoffman</span> and <span class="firstname">M.</span> <span class="surname">Blanchet</span>. </span><span class="title"><i>Nameprep: A Stringprep Profile for Internationalized Domain Names</i>. </span><span class="pubdate">March 2003. </span></p>
+<a name="id2597096"></a><p>[<abbr class="abbrev">RFC3491</abbr>] <span class="authorgroup"><span class="firstname">P.</span> <span class="surname">Hoffman</span> and <span class="firstname">M.</span> <span class="surname">Blanchet</span>. </span><span class="title"><i>Nameprep: A Stringprep Profile for Internationalized Domain Names</i>. </span><span class="pubdate">March 2003. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2597125"></a><p>[<abbr class="abbrev">RFC3492</abbr>] <span class="authorgroup"><span class="firstname">A.</span> <span class="surname">Costello</span>. </span><span class="title"><i>Punycode: A Bootstring encoding of Unicode
+<a name="id2597131"></a><p>[<abbr class="abbrev">RFC3492</abbr>] <span class="authorgroup"><span class="firstname">A.</span> <span class="surname">Costello</span>. </span><span class="title"><i>Punycode: A Bootstring encoding of Unicode
                        for Internationalized Domain Names in
                        Applications (IDNA)</i>. </span><span class="pubdate">March 2003. </span></p>
 </div>
@@ -487,47 +487,47 @@
                 </p>
 </div>
 <div class="biblioentry">
-<a name="id2597170"></a><p>[<abbr class="abbrev">RFC1464</abbr>] <span class="author"><span class="firstname">R.</span> <span class="surname">Rosenbaum</span>. </span><span class="title"><i>Using the Domain Name System To Store Arbitrary String
+<a name="id2597176"></a><p>[<abbr class="abbrev">RFC1464</abbr>] <span class="author"><span class="firstname">R.</span> <span class="surname">Rosenbaum</span>. </span><span class="title"><i>Using the Domain Name System To Store Arbitrary String
                   Attributes</i>. </span><span class="pubdate">May 1993. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2597192"></a><p>[<abbr class="abbrev">RFC1713</abbr>] <span class="author"><span class="firstname">A.</span> <span class="surname">Romao</span>. </span><span class="title"><i>Tools for <acronym class="acronym">DNS</acronym> Debugging</i>. </span><span class="pubdate">November 1994. </span></p>
+<a name="id2597198"></a><p>[<abbr class="abbrev">RFC1713</abbr>] <span class="author"><span class="firstname">A.</span> <span class="surname">Romao</span>. </span><span class="title"><i>Tools for <acronym class="acronym">DNS</acronym> Debugging</i>. </span><span class="pubdate">November 1994. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2597286"></a><p>[<abbr class="abbrev">RFC1794</abbr>] <span class="author"><span class="firstname">T.</span> <span class="surname">Brisco</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> Support for Load
+<a name="id2597292"></a><p>[<abbr class="abbrev">RFC1794</abbr>] <span class="author"><span class="firstname">T.</span> <span class="surname">Brisco</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> Support for Load
                   Balancing</i>. </span><span class="pubdate">April 1995. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2597312"></a><p>[<abbr class="abbrev">RFC2240</abbr>] <span class="author"><span class="firstname">O.</span> <span class="surname">Vaughan</span>. </span><span class="title"><i>A Legal Basis for Domain Name Allocation</i>. </span><span class="pubdate">November 1997. </span></p>
+<a name="id2597318"></a><p>[<abbr class="abbrev">RFC2240</abbr>] <span class="author"><span class="firstname">O.</span> <span class="surname">Vaughan</span>. </span><span class="title"><i>A Legal Basis for Domain Name Allocation</i>. </span><span class="pubdate">November 1997. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2597335"></a><p>[<abbr class="abbrev">RFC2345</abbr>] <span class="authorgroup"><span class="firstname">J.</span> <span class="surname">Klensin</span>, <span class="firstname">T.</span> <span class="surname">Wolf</span>, and <span class="firstname">G.</span> <span class="surname">Oglesby</span>. </span><span class="title"><i>Domain Names and Company Name Retrieval</i>. </span><span class="pubdate">May 1998. </span></p>
+<a name="id2597341"></a><p>[<abbr class="abbrev">RFC2345</abbr>] <span class="authorgroup"><span class="firstname">J.</span> <span class="surname">Klensin</span>, <span class="firstname">T.</span> <span class="surname">Wolf</span>, and <span class="firstname">G.</span> <span class="surname">Oglesby</span>. </span><span class="title"><i>Domain Names and Company Name Retrieval</i>. </span><span class="pubdate">May 1998. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2597381"></a><p>[<abbr class="abbrev">RFC2352</abbr>] <span class="author"><span class="firstname">O.</span> <span class="surname">Vaughan</span>. </span><span class="title"><i>A Convention For Using Legal Names as Domain Names</i>. </span><span class="pubdate">May 1998. </span></p>
+<a name="id2597387"></a><p>[<abbr class="abbrev">RFC2352</abbr>] <span class="author"><span class="firstname">O.</span> <span class="surname">Vaughan</span>. </span><span class="title"><i>A Convention For Using Legal Names as Domain Names</i>. </span><span class="pubdate">May 1998. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2597404"></a><p>[<abbr class="abbrev">RFC3071</abbr>] <span class="authorgroup"><span class="firstname">J.</span> <span class="surname">Klensin</span>. </span><span class="title"><i>Reflections on the DNS, RFC 1591, and Categories of Domains</i>. </span><span class="pubdate">February 2001. </span></p>
+<a name="id2597411"></a><p>[<abbr class="abbrev">RFC3071</abbr>] <span class="authorgroup"><span class="firstname">J.</span> <span class="surname">Klensin</span>. </span><span class="title"><i>Reflections on the DNS, RFC 1591, and Categories of Domains</i>. </span><span class="pubdate">February 2001. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2597431"></a><p>[<abbr class="abbrev">RFC3258</abbr>] <span class="authorgroup"><span class="firstname">T.</span> <span class="surname">Hardie</span>. </span><span class="title"><i>Distributing Authoritative Name Servers via
+<a name="id2597437"></a><p>[<abbr class="abbrev">RFC3258</abbr>] <span class="authorgroup"><span class="firstname">T.</span> <span class="surname">Hardie</span>. </span><span class="title"><i>Distributing Authoritative Name Servers via
                        Shared Unicast Addresses</i>. </span><span class="pubdate">April 2002. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2597457"></a><p>[<abbr class="abbrev">RFC3901</abbr>] <span class="authorgroup"><span class="firstname">A.</span> <span class="surname">Durand</span> and <span class="firstname">J.</span> <span class="surname">Ihren</span>. </span><span class="title"><i>DNS IPv6 Transport Operational Guidelines</i>. </span><span class="pubdate">September 2004. </span></p>
+<a name="id2597463"></a><p>[<abbr class="abbrev">RFC3901</abbr>] <span class="authorgroup"><span class="firstname">A.</span> <span class="surname">Durand</span> and <span class="firstname">J.</span> <span class="surname">Ihren</span>. </span><span class="title"><i>DNS IPv6 Transport Operational Guidelines</i>. </span><span class="pubdate">September 2004. </span></p>
 </div>
 </div>
 <div class="bibliodiv">
 <h3 class="title">Obsolete and Unimplemented Experimental RFC</h3>
 <div class="biblioentry">
-<a name="id2597500"></a><p>[<abbr class="abbrev">RFC1712</abbr>] <span class="authorgroup"><span class="firstname">C.</span> <span class="surname">Farrell</span>, <span class="firstname">M.</span> <span class="surname">Schulze</span>, <span class="firstname">S.</span> <span class="surname">Pleitner</span>, and <span class="firstname">D.</span> <span class="surname">Baldoni</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> Encoding of Geographical
+<a name="id2597507"></a><p>[<abbr class="abbrev">RFC1712</abbr>] <span class="authorgroup"><span class="firstname">C.</span> <span class="surname">Farrell</span>, <span class="firstname">M.</span> <span class="surname">Schulze</span>, <span class="firstname">S.</span> <span class="surname">Pleitner</span>, and <span class="firstname">D.</span> <span class="surname">Baldoni</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> Encoding of Geographical
                   Location</i>. </span><span class="pubdate">November 1994. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2597558"></a><p>[<abbr class="abbrev">RFC2673</abbr>] <span class="authorgroup"><span class="firstname">M.</span> <span class="surname">Crawford</span>. </span><span class="title"><i>Binary Labels in the Domain Name System</i>. </span><span class="pubdate">August 1999. </span></p>
+<a name="id2597564"></a><p>[<abbr class="abbrev">RFC2673</abbr>] <span class="authorgroup"><span class="firstname">M.</span> <span class="surname">Crawford</span>. </span><span class="title"><i>Binary Labels in the Domain Name System</i>. </span><span class="pubdate">August 1999. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2597585"></a><p>[<abbr class="abbrev">RFC2874</abbr>] <span class="authorgroup"><span class="firstname">M.</span> <span class="surname">Crawford</span> and <span class="firstname">C.</span> <span class="surname">Huitema</span>. </span><span class="title"><i>DNS Extensions to Support IPv6 Address Aggregation
+<a name="id2597591"></a><p>[<abbr class="abbrev">RFC2874</abbr>] <span class="authorgroup"><span class="firstname">M.</span> <span class="surname">Crawford</span> and <span class="firstname">C.</span> <span class="surname">Huitema</span>. </span><span class="title"><i>DNS Extensions to Support IPv6 Address Aggregation
                        and Renumbering</i>. </span><span class="pubdate">July 2000. </span></p>
 </div>
 </div>
@@ -541,39 +541,39 @@
                 </p>
 </div>
 <div class="biblioentry">
-<a name="id2597633"></a><p>[<abbr class="abbrev">RFC2065</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span> and <span class="firstname">C.</span> <span class="surname">Kaufman</span>. </span><span class="title"><i>Domain Name System Security Extensions</i>. </span><span class="pubdate">January 1997. </span></p>
+<a name="id2597639"></a><p>[<abbr class="abbrev">RFC2065</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span> and <span class="firstname">C.</span> <span class="surname">Kaufman</span>. </span><span class="title"><i>Domain Name System Security Extensions</i>. </span><span class="pubdate">January 1997. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2597672"></a><p>[<abbr class="abbrev">RFC2137</abbr>] <span class="author"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>Secure Domain Name System Dynamic Update</i>. </span><span class="pubdate">April 1997. </span></p>
+<a name="id2597678"></a><p>[<abbr class="abbrev">RFC2137</abbr>] <span class="author"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>Secure Domain Name System Dynamic Update</i>. </span><span class="pubdate">April 1997. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2597699"></a><p>[<abbr class="abbrev">RFC2535</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>Domain Name System Security Extensions</i>. </span><span class="pubdate">March 1999. </span></p>
+<a name="id2597705"></a><p>[<abbr class="abbrev">RFC2535</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>Domain Name System Security Extensions</i>. </span><span class="pubdate">March 1999. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2597729"></a><p>[<abbr class="abbrev">RFC3008</abbr>] <span class="authorgroup"><span class="firstname">B.</span> <span class="surname">Wellington</span>. </span><span class="title"><i>Domain Name System Security (DNSSEC)
+<a name="id2597735"></a><p>[<abbr class="abbrev">RFC3008</abbr>] <span class="authorgroup"><span class="firstname">B.</span> <span class="surname">Wellington</span>. </span><span class="title"><i>Domain Name System Security (DNSSEC)
                        Signing Authority</i>. </span><span class="pubdate">November 2000. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2597754"></a><p>[<abbr class="abbrev">RFC3090</abbr>] <span class="authorgroup"><span class="firstname">E.</span> <span class="surname">Lewis</span>. </span><span class="title"><i>DNS Security Extension Clarification on Zone Status</i>. </span><span class="pubdate">March 2001. </span></p>
+<a name="id2597761"></a><p>[<abbr class="abbrev">RFC3090</abbr>] <span class="authorgroup"><span class="firstname">E.</span> <span class="surname">Lewis</span>. </span><span class="title"><i>DNS Security Extension Clarification on Zone Status</i>. </span><span class="pubdate">March 2001. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2597781"></a><p>[<abbr class="abbrev">RFC3445</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Massey</span> and <span class="firstname">S.</span> <span class="surname">Rose</span>. </span><span class="title"><i>Limiting the Scope of the KEY Resource Record (RR)</i>. </span><span class="pubdate">December 2002. </span></p>
+<a name="id2597787"></a><p>[<abbr class="abbrev">RFC3445</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Massey</span> and <span class="firstname">S.</span> <span class="surname">Rose</span>. </span><span class="title"><i>Limiting the Scope of the KEY Resource Record (RR)</i>. </span><span class="pubdate">December 2002. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2597817"></a><p>[<abbr class="abbrev">RFC3655</abbr>] <span class="authorgroup"><span class="firstname">B.</span> <span class="surname">Wellington</span> and <span class="firstname">O.</span> <span class="surname">Gudmundsson</span>. </span><span class="title"><i>Redefinition of DNS Authenticated Data (AD) bit</i>. </span><span class="pubdate">November 2003. </span></p>
+<a name="id2597824"></a><p>[<abbr class="abbrev">RFC3655</abbr>] <span class="authorgroup"><span class="firstname">B.</span> <span class="surname">Wellington</span> and <span class="firstname">O.</span> <span class="surname">Gudmundsson</span>. </span><span class="title"><i>Redefinition of DNS Authenticated Data (AD) bit</i>. </span><span class="pubdate">November 2003. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2597853"></a><p>[<abbr class="abbrev">RFC3658</abbr>] <span class="authorgroup"><span class="firstname">O.</span> <span class="surname">Gudmundsson</span>. </span><span class="title"><i>Delegation Signer (DS) Resource Record (RR)</i>. </span><span class="pubdate">December 2003. </span></p>
+<a name="id2597860"></a><p>[<abbr class="abbrev">RFC3658</abbr>] <span class="authorgroup"><span class="firstname">O.</span> <span class="surname">Gudmundsson</span>. </span><span class="title"><i>Delegation Signer (DS) Resource Record (RR)</i>. </span><span class="pubdate">December 2003. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2597880"></a><p>[<abbr class="abbrev">RFC3755</abbr>] <span class="authorgroup"><span class="firstname">S.</span> <span class="surname">Weiler</span>. </span><span class="title"><i>Legacy Resolver Compatibility for Delegation Signer (DS)</i>. </span><span class="pubdate">May 2004. </span></p>
+<a name="id2597886"></a><p>[<abbr class="abbrev">RFC3755</abbr>] <span class="authorgroup"><span class="firstname">S.</span> <span class="surname">Weiler</span>. </span><span class="title"><i>Legacy Resolver Compatibility for Delegation Signer (DS)</i>. </span><span class="pubdate">May 2004. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2597907"></a><p>[<abbr class="abbrev">RFC3757</abbr>] <span class="authorgroup"><span class="firstname">O.</span> <span class="surname">Kolkman</span>, <span class="firstname">J.</span> <span class="surname">Schlyter</span>, and <span class="firstname">E.</span> <span class="surname">Lewis</span>. </span><span class="title"><i>Domain Name System KEY (DNSKEY) Resource Record
+<a name="id2597913"></a><p>[<abbr class="abbrev">RFC3757</abbr>] <span class="authorgroup"><span class="firstname">O.</span> <span class="surname">Kolkman</span>, <span class="firstname">J.</span> <span class="surname">Schlyter</span>, and <span class="firstname">E.</span> <span class="surname">Lewis</span>. </span><span class="title"><i>Domain Name System KEY (DNSKEY) Resource Record
                       (RR) Secure Entry Point (SEP) Flag</i>. </span><span class="pubdate">April 2004. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2597952"></a><p>[<abbr class="abbrev">RFC3845</abbr>] <span class="authorgroup"><span class="firstname">J.</span> <span class="surname">Schlyter</span>. </span><span class="title"><i>DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format</i>. </span><span class="pubdate">August 2004. </span></p>
+<a name="id2597958"></a><p>[<abbr class="abbrev">RFC3845</abbr>] <span class="authorgroup"><span class="firstname">J.</span> <span class="surname">Schlyter</span>. </span><span class="title"><i>DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format</i>. </span><span class="pubdate">August 2004. </span></p>
 </div>
 </div>
 </div>
@@ -594,14 +594,14 @@
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2597993"></a>Other Documents About <acronym class="acronym">BIND</acronym>
+<a name="id2598000"></a>Other Documents About <acronym class="acronym">BIND</acronym>
 </h3></div></div></div>
 <p></p>
 <div class="bibliography">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2598003"></a>Bibliography</h4></div></div></div>
+<a name="id2598009"></a>Bibliography</h4></div></div></div>
 <div class="biblioentry">
-<a name="id2598005"></a><p><span class="authorgroup"><span class="firstname">Paul</span> <span class="surname">Albitz</span> and <span class="firstname">Cricket</span> <span class="surname">Liu</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> and <acronym class="acronym">BIND</acronym></i>. </span><span class="copyright">Copyright © 1998 Sebastopol, CA: O'Reilly and Associates. </span></p>
+<a name="id2598011"></a><p><span class="authorgroup"><span class="firstname">Paul</span> <span class="surname">Albitz</span> and <span class="firstname">Cricket</span> <span class="surname">Liu</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> and <acronym class="acronym">BIND</acronym></i>. </span><span class="copyright">Copyright © 1998 Sebastopol, CA: O'Reilly and Associates. </span></p>
 </div>
 </div>
 </div>

contrib/bind9/doc/arm/Bv9ARM.ch10.html

@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: Bv9ARM.ch10.html,v 1.2.2.11 2009/07/11 01:31:48 tbox Exp $ -->
+<!-- $Id: Bv9ARM.ch10.html,v 1.2.2.12 2010/02/27 01:33:42 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">

contrib/bind9/doc/arm/Bv9ARM.html

@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: Bv9ARM.html,v 1.85.18.90 2009/09/25 01:33:43 tbox Exp $ -->
+<!-- $Id: Bv9ARM.html,v 1.85.18.92 2010/02/27 01:33:42 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -41,7 +41,7 @@
 <div>
 <div><h1 class="title">
 <a name="id2563174"></a>BIND 9 Administrator Reference Manual</h1></div>
-<div><p class="copyright">Copyright © 2004-2009 Internet Systems Consortium, Inc. ("ISC")</p></div>
+<div><p class="copyright">Copyright © 2004-2010 Internet Systems Consortium, Inc. ("ISC")</p></div>
 <div><p class="copyright">Copyright © 2000-2003 Internet Software Consortium.</p></div>
 </div>
 <hr>
@@ -51,39 +51,39 @@
 <dl>
 <dt><span class="chapter"><a href="Bv9ARM.ch01.html">1. Introduction</a></span></dt>
 <dd><dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2563409">Scope of Document</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564388">Organization of This Document</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564528">Conventions Used in This Document</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564641">The Domain Name System (<acronym class="acronym">DNS</acronym>)</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2563412">Scope of Document</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564391">Organization of This Document</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564531">Conventions Used in This Document</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564712">The Domain Name System (<acronym class="acronym">DNS</acronym>)</a></span></dt>
 <dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2564662">DNS Fundamentals</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2564696">Domains and Domain Names</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567170">Zones</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567246">Authoritative Name Servers</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567419">Caching Name Servers</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567549">Name Servers in Multiple Roles</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2564733">DNS Fundamentals</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2564768">Domains and Domain Names</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567173">Zones</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567250">Authoritative Name Servers</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567422">Caching Name Servers</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567553">Name Servers in Multiple Roles</a></span></dt>
 </dl></dd>
 </dl></dd>
 <dt><span class="chapter"><a href="Bv9ARM.ch02.html">2. <acronym class="acronym">BIND</acronym> Resource Requirements</a></span></dt>
 <dd><dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567584">Hardware requirements</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567610">CPU Requirements</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567623">Memory Requirements</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567854">Name Server Intensive Environment Issues</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567865">Supported Operating Systems</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567587">Hardware requirements</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567613">CPU Requirements</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567626">Memory Requirements</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567721">Name Server Intensive Environment Issues</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567732">Supported Operating Systems</a></span></dt>
 </dl></dd>
 <dt><span class="chapter"><a href="Bv9ARM.ch03.html">3. Name Server Configuration</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="Bv9ARM.ch03.html#sample_configuration">Sample Configurations</a></span></dt>
 <dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2567897">A Caching-only Name Server</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2567913">An Authoritative-only Name Server</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2567764">A Caching-only Name Server</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2567780">An Authoritative-only Name Server</a></span></dt>
 </dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch03.html#id2568004">Load Balancing</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch03.html#id2568426">Name Server Operations</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch03.html#id2568007">Load Balancing</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch03.html#id2568429">Name Server Operations</a></span></dt>
 <dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2568432">Tools for Use With the Name Server Daemon</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2570041">Signals</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2568435">Tools for Use With the Name Server Daemon</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2570044">Signals</a></span></dt>
 </dl></dd>
 </dl></dd>
 <dt><span class="chapter"><a href="Bv9ARM.ch04.html">4. Advanced DNS Features</a></span></dt>
@@ -92,34 +92,34 @@
 <dt><span class="sect1"><a href="Bv9ARM.ch04.html#dynamic_update">Dynamic Update</a></span></dt>
 <dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch04.html#journal">The journal file</a></span></dt></dl></dd>
 <dt><span class="sect1"><a href="Bv9ARM.ch04.html#incremental_zone_transfers">Incremental Zone Transfers (IXFR)</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2570437">Split DNS</a></span></dt>
-<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2570455">Example split DNS setup</a></span></dt></dl></dd>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2570440">Split DNS</a></span></dt>
+<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2570458">Example split DNS setup</a></span></dt></dl></dd>
 <dt><span class="sect1"><a href="Bv9ARM.ch04.html#tsig">TSIG</a></span></dt>
 <dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2570958">Generate Shared Keys for Each Pair of Hosts</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571032">Copying the Shared Secret to Both Machines</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571043">Informing the Servers of the Key's Existence</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571085">Instructing the Server to Use the Key</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571280">TSIG Key Based Access Control</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571328">Errors</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571098">Generate Shared Keys for Each Pair of Hosts</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571172">Copying the Shared Secret to Both Machines</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571182">Informing the Servers of the Key's Existence</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571225">Instructing the Server to Use the Key</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571419">TSIG Key Based Access Control</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571467">Errors</a></span></dt>
 </dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2571410">TKEY</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2571459">SIG(0)</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2571549">TKEY</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2571598">SIG(0)</a></span></dt>
 <dt><span class="sect1"><a href="Bv9ARM.ch04.html#DNSSEC">DNSSEC</a></span></dt>
 <dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2564086">Generating Keys</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2564155">Signing the Zone</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571880">Configuring Servers</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571735">Generating Keys</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571804">Signing the Zone</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571883">Configuring Servers</a></span></dt>
 </dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2572026">IPv6 Support in <acronym class="acronym">BIND</acronym> 9</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2572029">IPv6 Support in <acronym class="acronym">BIND</acronym> 9</a></span></dt>
 <dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572156">Address Lookups Using AAAA Records</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572178">Address to Name Lookups Using Nibble Format</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572160">Address Lookups Using AAAA Records</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572181">Address to Name Lookups Using Nibble Format</a></span></dt>
 </dl></dd>
 </dl></dd>
 <dt><span class="chapter"><a href="Bv9ARM.ch05.html">5. The <acronym class="acronym">BIND</acronym> 9 Lightweight Resolver</a></span></dt>
 <dd><dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch05.html#id2572211">The Lightweight Resolver Library</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch05.html#id2572214">The Lightweight Resolver Library</a></span></dt>
 <dt><span class="sect1"><a href="Bv9ARM.ch05.html#lwresd">Running a Resolver Daemon</a></span></dt>
 </dl></dd>
 <dt><span class="chapter"><a href="Bv9ARM.ch06.html">6. <acronym class="acronym">BIND</acronym> 9 Configuration Reference</a></span></dt>
@@ -127,83 +127,83 @@
 <dt><span class="sect1"><a href="Bv9ARM.ch06.html#configuration_file_elements">Configuration File Elements</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="Bv9ARM.ch06.html#address_match_lists">Address Match Lists</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2573560">Comment Syntax</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2573563">Comment Syntax</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="Bv9ARM.ch06.html#Configuration_File_Grammar">Configuration File Grammar</a></span></dt>
 <dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574164"><span><strong class="command">acl</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574167"><span><strong class="command">acl</strong></span> Statement Grammar</a></span></dt>
 <dt><span class="sect2"><a href="Bv9ARM.ch06.html#acl"><span><strong class="command">acl</strong></span> Statement Definition and
           Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574422"><span><strong class="command">controls</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574425"><span><strong class="command">controls</strong></span> Statement Grammar</a></span></dt>
 <dt><span class="sect2"><a href="Bv9ARM.ch06.html#controls_statement_definition_and_usage"><span><strong class="command">controls</strong></span> Statement Definition and
           Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574851"><span><strong class="command">include</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574868"><span><strong class="command">include</strong></span> Statement Definition and
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574854"><span><strong class="command">include</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574871"><span><strong class="command">include</strong></span> Statement Definition and
           Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574891"><span><strong class="command">key</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574915"><span><strong class="command">key</strong></span> Statement Definition and Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575005"><span><strong class="command">logging</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575200"><span><strong class="command">logging</strong></span> Statement Definition and
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574894"><span><strong class="command">key</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574918"><span><strong class="command">key</strong></span> Statement Definition and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575009"><span><strong class="command">logging</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575203"><span><strong class="command">logging</strong></span> Statement Definition and
           Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577096"><span><strong class="command">lwres</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577238"><span><strong class="command">lwres</strong></span> Statement Definition and Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577302"><span><strong class="command">masters</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577346"><span><strong class="command">masters</strong></span> Statement Definition and
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577099"><span><strong class="command">lwres</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577241"><span><strong class="command">lwres</strong></span> Statement Definition and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577305"><span><strong class="command">masters</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577349"><span><strong class="command">masters</strong></span> Statement Definition and
           Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577361"><span><strong class="command">options</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577364"><span><strong class="command">options</strong></span> Statement Grammar</a></span></dt>
 <dt><span class="sect2"><a href="Bv9ARM.ch06.html#options"><span><strong class="command">options</strong></span> Statement Definition and
           Usage</a></span></dt>
 <dt><span class="sect2"><a href="Bv9ARM.ch06.html#server_statement_grammar"><span><strong class="command">server</strong></span> Statement Grammar</a></span></dt>
 <dt><span class="sect2"><a href="Bv9ARM.ch06.html#server_statement_definition_and_usage"><span><strong class="command">server</strong></span> Statement Definition and
             Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2586451"><span><strong class="command">trusted-keys</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2586502"><span><strong class="command">trusted-keys</strong></span> Statement Definition
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2586321"><span><strong class="command">trusted-keys</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2586372"><span><strong class="command">trusted-keys</strong></span> Statement Definition
             and Usage</a></span></dt>
 <dt><span class="sect2"><a href="Bv9ARM.ch06.html#view_statement_grammar"><span><strong class="command">view</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2586652"><span><strong class="command">view</strong></span> Statement Definition and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2586590"><span><strong class="command">view</strong></span> Statement Definition and Usage</a></span></dt>
 <dt><span class="sect2"><a href="Bv9ARM.ch06.html#zone_statement_grammar"><span><strong class="command">zone</strong></span>
             Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2587989"><span><strong class="command">zone</strong></span> Statement Definition and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2587995"><span><strong class="command">zone</strong></span> Statement Definition and Usage</a></span></dt>
 </dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch06.html#id2590251">Zone File</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch06.html#id2590189">Zone File</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="Bv9ARM.ch06.html#types_of_resource_records_and_when_to_use_them">Types of Resource Records and When to Use Them</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2592275">Discussion of MX Records</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2592281">Discussion of MX Records</a></span></dt>
 <dt><span class="sect2"><a href="Bv9ARM.ch06.html#Setting_TTLs">Setting TTLs</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2592890">Inverse Mapping in IPv4</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2593085">Other Zone File Directives</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2593342"><acronym class="acronym">BIND</acronym> Master File Extension: the  <span><strong class="command">$GENERATE</strong></span> Directive</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2592965">Inverse Mapping in IPv4</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2593092">Other Zone File Directives</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2593349"><acronym class="acronym">BIND</acronym> Master File Extension: the  <span><strong class="command">$GENERATE</strong></span> Directive</a></span></dt>
 <dt><span class="sect2"><a href="Bv9ARM.ch06.html#zonefile_format">Additional File Formats</a></span></dt>
 </dl></dd>
 </dl></dd>
 <dt><span class="chapter"><a href="Bv9ARM.ch07.html">7. <acronym class="acronym">BIND</acronym> 9 Security Considerations</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="Bv9ARM.ch07.html#Access_Control_Lists">Access Control Lists</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch07.html#id2593952"><span><strong class="command">Chroot</strong></span> and <span><strong class="command">Setuid</strong></span></a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch07.html#id2593958"><span><strong class="command">Chroot</strong></span> and <span><strong class="command">Setuid</strong></span></a></span></dt>
 <dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2594033">The <span><strong class="command">chroot</strong></span> Environment</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2594092">Using the <span><strong class="command">setuid</strong></span> Function</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2594039">The <span><strong class="command">chroot</strong></span> Environment</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2594099">Using the <span><strong class="command">setuid</strong></span> Function</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="Bv9ARM.ch07.html#dynamic_update_security">Dynamic Update Security</a></span></dt>
 </dl></dd>
 <dt><span class="chapter"><a href="Bv9ARM.ch08.html">8. Troubleshooting</a></span></dt>
 <dd><dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2594241">Common Problems</a></span></dt>
-<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch08.html#id2594246">It's not working; how can I figure out what's wrong?</a></span></dt></dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2594258">Incrementing and Changing the Serial Number</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2594343">Where Can I Get Help?</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2594247">Common Problems</a></span></dt>
+<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch08.html#id2594252">It's not working; how can I figure out what's wrong?</a></span></dt></dl></dd>
+<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2594264">Incrementing and Changing the Serial Number</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2594281">Where Can I Get Help?</a></span></dt>
 </dl></dd>
 <dt><span class="appendix"><a href="Bv9ARM.ch09.html">A. Appendices</a></span></dt>
 <dd><dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch09.html#id2594405">Acknowledgments</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch09.html#id2594480">Acknowledgments</a></span></dt>
 <dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch09.html#historical_dns_information">A Brief History of the <acronym class="acronym">DNS</acronym> and <acronym class="acronym">BIND</acronym></a></span></dt></dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch09.html#id2594645">General <acronym class="acronym">DNS</acronym> Reference Information</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch09.html#id2594651">General <acronym class="acronym">DNS</acronym> Reference Information</a></span></dt>
 <dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch09.html#ipv6addresses">IPv6 addresses (AAAA)</a></span></dt></dl></dd>
 <dt><span class="sect1"><a href="Bv9ARM.ch09.html#bibliography">Bibliography (and Suggested Reading)</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="Bv9ARM.ch09.html#rfcs">Request for Comments (RFCs)</a></span></dt>
 <dt><span class="sect2"><a href="Bv9ARM.ch09.html#internet_drafts">Internet Drafts</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch09.html#id2597993">Other Documents About <acronym class="acronym">BIND</acronym></a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch09.html#id2598000">Other Documents About <acronym class="acronym">BIND</acronym></a></span></dt>
 </dl></dd>
 </dl></dd>
 <dt><span class="reference"><a href="Bv9ARM.ch10.html">I. Manual pages</a></span></dt>

contrib/bind9/doc/arm/man.dig.html

@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: man.dig.html,v 1.2.2.73 2009/09/25 01:33:41 tbox Exp $ -->
+<!-- $Id: man.dig.html,v 1.2.2.75 2010/02/27 01:33:43 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -52,7 +52,7 @@
 <div class="cmdsynopsis"><p><code class="command">dig</code>  [global-queryopt...] [query...]</p></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2563811"></a><h2>DESCRIPTION</h2>
+<a name="id2563885"></a><h2>DESCRIPTION</h2>
 <p><span><strong class="command">dig</strong></span>
       (domain information groper) is a flexible tool
       for interrogating DNS name servers.  It performs DNS lookups and
@@ -98,7 +98,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2571483"></a><h2>SIMPLE USAGE</h2>
+<a name="id2570739"></a><h2>SIMPLE USAGE</h2>
 <p>
       A typical invocation of <span><strong class="command">dig</strong></span> looks like:
       </p>
@@ -144,7 +144,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2571594"></a><h2>OPTIONS</h2>
+<a name="id2570850"></a><h2>OPTIONS</h2>
 <p>
       The <code class="option">-b</code> option sets the source IP address of the query
       to <em class="parameter"><code>address</code></em>.  This must be a valid
@@ -248,7 +248,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2625116"></a><h2>QUERY OPTIONS</h2>
+<a name="id2625123"></a><h2>QUERY OPTIONS</h2>
 <p><span><strong class="command">dig</strong></span>
       provides a number of query options which affect
       the way in which lookups are made and the results displayed.  Some of
@@ -569,7 +569,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2626171"></a><h2>MULTIPLE QUERIES</h2>
+<a name="id2626178"></a><h2>MULTIPLE QUERIES</h2>
 <p>
       The BIND 9 implementation of <span><strong class="command">dig </strong></span>
       supports
@@ -615,7 +615,7 @@ dig +qr www.isc.org any -x 127.0.0.1 isc.org ns +noqr
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2626325"></a><h2>IDN SUPPORT</h2>
+<a name="id2626331"></a><h2>IDN SUPPORT</h2>
 <p>
       If <span><strong class="command">dig</strong></span> has been built with IDN (internationalized
       domain name) support, it can accept and display non-ASCII domain names.
@@ -629,14 +629,14 @@ dig +qr www.isc.org any -x 127.0.0.1 isc.org ns +noqr
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2626354"></a><h2>FILES</h2>
+<a name="id2626428"></a><h2>FILES</h2>
 <p><code class="filename">/etc/resolv.conf</code>
     </p>
 <p><code class="filename">${HOME}/.digrc</code>
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2626443"></a><h2>SEE ALSO</h2>
+<a name="id2626450"></a><h2>SEE ALSO</h2>
 <p><span class="citerefentry"><span class="refentrytitle">host</span>(1)</span>,
       <span class="citerefentry"><span class="refentrytitle">named</span>(8)</span>,
       <span class="citerefentry"><span class="refentrytitle">dnssec-keygen</span>(8)</span>,
@@ -644,7 +644,7 @@ dig +qr www.isc.org any -x 127.0.0.1 isc.org ns +noqr
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2626481"></a><h2>BUGS</h2>
+<a name="id2626487"></a><h2>BUGS</h2>
 <p>
       There are probably too many query options.
     </p>

contrib/bind9/doc/arm/man.dnssec-keygen.html

@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: man.dnssec-keygen.html,v 1.2.2.74 2009/09/25 01:33:44 tbox Exp $ -->
+<!-- $Id: man.dnssec-keygen.html,v 1.2.2.76 2010/02/27 01:33:42 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -50,7 +50,7 @@
 <div class="cmdsynopsis"><p><code class="command">dnssec-keygen</code>  {-a <em class="replaceable"><code>algorithm</code></em>} {-b <em class="replaceable"><code>keysize</code></em>} {-n <em class="replaceable"><code>nametype</code></em>} [<code class="option">-c <em class="replaceable"><code>class</code></em></code>] [<code class="option">-e</code>] [<code class="option">-f <em class="replaceable"><code>flag</code></em></code>] [<code class="option">-g <em class="replaceable"><code>generator</code></em></code>] [<code class="option">-h</code>] [<code class="option">-k</code>] [<code class="option">-p <em class="replaceable"><code>protocol</code></em></code>] [<code class="option">-r <em class="replaceable"><code>randomdev</code></em></code>] [<code class="option">-s <em class="replaceable"><code>strength</code></em></code>] [<code class="option">-t <em class="replaceable"><code>type</code></em></code>] [<code class="option">-v <em class="replaceable"><code>level</code></em></code>] {name}</p></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2598979"></a><h2>DESCRIPTION</h2>
+<a name="id2598985"></a><h2>DESCRIPTION</h2>
 <p><span><strong class="command">dnssec-keygen</strong></span>
       generates keys for DNSSEC (Secure DNS), as defined in RFC 2535
       and RFC 4034.  It can also generate keys for use with
@@ -58,7 +58,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2598993"></a><h2>OPTIONS</h2>
+<a name="id2598999"></a><h2>OPTIONS</h2>
 <div class="variablelist"><dl>
 <dt><span class="term">-a <em class="replaceable"><code>algorithm</code></em></span></dt>
 <dd>
@@ -166,7 +166,7 @@
 </dl></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2599473"></a><h2>GENERATED KEYS</h2>
+<a name="id2599479"></a><h2>GENERATED KEYS</h2>
 <p>
       When <span><strong class="command">dnssec-keygen</strong></span> completes
       successfully,
@@ -212,7 +212,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2599580"></a><h2>EXAMPLE</h2>
+<a name="id2599587"></a><h2>EXAMPLE</h2>
 <p>
       To generate a 768-bit DSA key for the domain
       <strong class="userinput"><code>example.com</code></strong>, the following command would be
@@ -233,7 +233,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2601548"></a><h2>SEE ALSO</h2>
+<a name="id2601486"></a><h2>SEE ALSO</h2>
 <p><span class="citerefentry"><span class="refentrytitle">dnssec-signzone</span>(8)</span>,
       <em class="citetitle">BIND 9 Administrator Reference Manual</em>,
       <em class="citetitle">RFC 2539</em>,
@@ -242,7 +242,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2601579"></a><h2>AUTHOR</h2>
+<a name="id2601517"></a><h2>AUTHOR</h2>
 <p><span class="corpauthor">Internet Systems Consortium</span>
     </p>
 </div>

contrib/bind9/doc/arm/man.dnssec-signzone.html

@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: man.dnssec-signzone.html,v 1.2.2.72 2009/09/25 01:33:44 tbox Exp $ -->
+<!-- $Id: man.dnssec-signzone.html,v 1.2.2.74 2010/02/27 01:33:43 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -50,7 +50,7 @@
 <div class="cmdsynopsis"><p><code class="command">dnssec-signzone</code>  [<code class="option">-a</code>] [<code class="option">-c <em class="replaceable"><code>class</code></em></code>] [<code class="option">-d <em class="replaceable"><code>directory</code></em></code>] [<code class="option">-e <em class="replaceable"><code>end-time</code></em></code>] [<code class="option">-f <em class="replaceable"><code>output-file</code></em></code>] [<code class="option">-g</code>] [<code class="option">-h</code>] [<code class="option">-k <em class="replaceable"><code>key</code></em></code>] [<code class="option">-l <em class="replaceable"><code>domain</code></em></code>] [<code class="option">-i <em class="replaceable"><code>interval</code></em></code>] [<code class="option">-I <em class="replaceable"><code>input-format</code></em></code>] [<code class="option">-j <em class="replaceable"><code>jitter</code></em></code>] [<code class="option">-N <em class="replaceable"><code>soa-serial-format</code></em></code>] [<code class="option">-o <em class="replaceable"><code>origin</code></em></code>] [<code class="option">-O <em class="replaceable"><code>output-format</code></em></code>] [<code class="option">-p</code>] [<code class="option">-r <em class="replaceable"><code>randomdev</code></em></code>] [<code class="option">-s <em class="replaceable"><code>start-time</code></em></code>] [<code class="option">-t</code>] [<code class="option">-v <em class="replaceable"><code>level</code></em></code>] [<code class="option">-z</code>] {zonefile} [key...]</p></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2600453"></a><h2>DESCRIPTION</h2>
+<a name="id2600869"></a><h2>DESCRIPTION</h2>
 <p><span><strong class="command">dnssec-signzone</strong></span>
       signs a zone.  It generates
       NSEC and RRSIG records and produces a signed version of the
@@ -61,7 +61,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2600472"></a><h2>OPTIONS</h2>
+<a name="id2600888"></a><h2>OPTIONS</h2>
 <div class="variablelist"><dl>
 <dt><span class="term">-a</span></dt>
 <dd><p>
@@ -259,7 +259,7 @@
 </dl></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2655020"></a><h2>EXAMPLE</h2>
+<a name="id2654958"></a><h2>EXAMPLE</h2>
 <p>
       The following command signs the <strong class="userinput"><code>example.com</code></strong>
       zone with the DSA key generated by <span><strong class="command">dnssec-keygen</strong></span>
@@ -288,14 +288,14 @@ db.example.com.signed
 %</pre>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2655093"></a><h2>SEE ALSO</h2>
+<a name="id2655031"></a><h2>SEE ALSO</h2>
 <p><span class="citerefentry"><span class="refentrytitle">dnssec-keygen</span>(8)</span>,
       <em class="citetitle">BIND 9 Administrator Reference Manual</em>,
       <em class="citetitle">RFC 4033</em>.
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2655117"></a><h2>AUTHOR</h2>
+<a name="id2655056"></a><h2>AUTHOR</h2>
 <p><span class="corpauthor">Internet Systems Consortium</span>
     </p>
 </div>

contrib/bind9/doc/arm/man.host.html

@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: man.host.html,v 1.2.2.71 2009/09/25 01:33:41 tbox Exp $ -->
+<!-- $Id: man.host.html,v 1.2.2.73 2010/02/27 01:33:43 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -50,7 +50,7 @@
 <div class="cmdsynopsis"><p><code class="command">host</code>  [<code class="option">-aCdlnrsTwv</code>] [<code class="option">-c <em class="replaceable"><code>class</code></em></code>] [<code class="option">-N <em class="replaceable"><code>ndots</code></em></code>] [<code class="option">-R <em class="replaceable"><code>number</code></em></code>] [<code class="option">-t <em class="replaceable"><code>type</code></em></code>] [<code class="option">-W <em class="replaceable"><code>wait</code></em></code>] [<code class="option">-m <em class="replaceable"><code>flag</code></em></code>] [<code class="option">-4</code>] [<code class="option">-6</code>] {name} [server]</p></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2598285"></a><h2>DESCRIPTION</h2>
+<a name="id2598292"></a><h2>DESCRIPTION</h2>
 <p><span><strong class="command">host</strong></span>
       is a simple utility for performing DNS lookups.
       It is normally used to convert names to IP addresses and vice versa.
@@ -202,7 +202,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2598800"></a><h2>IDN SUPPORT</h2>
+<a name="id2598806"></a><h2>IDN SUPPORT</h2>
 <p>
       If <span><strong class="command">host</strong></span> has been built with IDN (internationalized
       domain name) support, it can accept and display non-ASCII domain names. 
@@ -216,12 +216,12 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2598828"></a><h2>FILES</h2>
+<a name="id2598835"></a><h2>FILES</h2>
 <p><code class="filename">/etc/resolv.conf</code>
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2598842"></a><h2>SEE ALSO</h2>
+<a name="id2600419"></a><h2>SEE ALSO</h2>
 <p><span class="citerefentry"><span class="refentrytitle">dig</span>(1)</span>,
       <span class="citerefentry"><span class="refentrytitle">named</span>(8)</span>.
     </p>

contrib/bind9/doc/arm/man.named-checkconf.html

@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: man.named-checkconf.html,v 1.2.2.74 2009/09/25 01:33:44 tbox Exp $ -->
+<!-- $Id: man.named-checkconf.html,v 1.2.2.76 2010/02/27 01:33:43 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -50,14 +50,14 @@
 <div class="cmdsynopsis"><p><code class="command">named-checkconf</code>  [<code class="option">-v</code>] [<code class="option">-j</code>] [<code class="option">-t <em class="replaceable"><code>directory</code></em></code>] {filename} [<code class="option">-z</code>]</p></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2600138"></a><h2>DESCRIPTION</h2>
+<a name="id2601851"></a><h2>DESCRIPTION</h2>
 <p><span><strong class="command">named-checkconf</strong></span>
       checks the syntax, but not the semantics, of a named
       configuration file.
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2601040"></a><h2>OPTIONS</h2>
+<a name="id2601865"></a><h2>OPTIONS</h2>
 <div class="variablelist"><dl>
 <dt><span class="term">-t <em class="replaceable"><code>directory</code></em></span></dt>
 <dd><p>
@@ -88,21 +88,21 @@
 </dl></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2601142"></a><h2>RETURN VALUES</h2>
+<a name="id2601968"></a><h2>RETURN VALUES</h2>
 <p><span><strong class="command">named-checkconf</strong></span>
       returns an exit status of 1 if
       errors were detected and 0 otherwise.
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2601156"></a><h2>SEE ALSO</h2>
+<a name="id2601981"></a><h2>SEE ALSO</h2>
 <p><span class="citerefentry"><span class="refentrytitle">named</span>(8)</span>,
       <span class="citerefentry"><span class="refentrytitle">named-checkzone</span>(8)</span>,
       <em class="citetitle">BIND 9 Administrator Reference Manual</em>.
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2601186"></a><h2>AUTHOR</h2>
+<a name="id2602011"></a><h2>AUTHOR</h2>
 <p><span class="corpauthor">Internet Systems Consortium</span>
     </p>
 </div>

contrib/bind9/doc/arm/man.named-checkzone.html

@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: man.named-checkzone.html,v 1.2.2.78 2009/09/25 01:33:40 tbox Exp $ -->
+<!-- $Id: man.named-checkzone.html,v 1.2.2.80 2010/02/27 01:33:43 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -51,7 +51,7 @@
 <div class="cmdsynopsis"><p><code class="command">named-compilezone</code>  [<code class="option">-d</code>] [<code class="option">-j</code>] [<code class="option">-q</code>] [<code class="option">-v</code>] [<code class="option">-c <em class="replaceable"><code>class</code></em></code>] [<code class="option">-C <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-f <em class="replaceable"><code>format</code></em></code>] [<code class="option">-F <em class="replaceable"><code>format</code></em></code>] [<code class="option">-i <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-k <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-m <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-n <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-o <em class="replaceable"><code>filename</code></em></code>] [<code class="option">-s <em class="replaceable"><code>style</code></em></code>] [<code class="option">-t <em class="replaceable"><code>directory</code></em></code>] [<code class="option">-w <em class="replaceable"><code>directory</code></em></code>] [<code class="option">-D</code>] [<code class="option">-W <em class="replaceable"><code>mode</code></em></code>] {zonename} {filename}</p></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2602458"></a><h2>DESCRIPTION</h2>
+<a name="id2603216"></a><h2>DESCRIPTION</h2>
 <p><span><strong class="command">named-checkzone</strong></span>
       checks the syntax and integrity of a zone file.  It performs the
       same checks as <span><strong class="command">named</strong></span> does when loading a
@@ -71,7 +71,7 @@
      </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2602508"></a><h2>OPTIONS</h2>
+<a name="id2603266"></a><h2>OPTIONS</h2>
 <div class="variablelist"><dl>
 <dt><span class="term">-d</span></dt>
 <dd><p>
@@ -251,14 +251,14 @@
 </dl></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2655786"></a><h2>RETURN VALUES</h2>
+<a name="id2656817"></a><h2>RETURN VALUES</h2>
 <p><span><strong class="command">named-checkzone</strong></span>
       returns an exit status of 1 if
       errors were detected and 0 otherwise.
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2655800"></a><h2>SEE ALSO</h2>
+<a name="id2656830"></a><h2>SEE ALSO</h2>
 <p><span class="citerefentry"><span class="refentrytitle">named</span>(8)</span>,
       <span class="citerefentry"><span class="refentrytitle">named-checkconf</span>(8)</span>,
       <em class="citetitle">RFC 1035</em>,
@@ -266,7 +266,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2655833"></a><h2>AUTHOR</h2>
+<a name="id2656864"></a><h2>AUTHOR</h2>
 <p><span class="corpauthor">Internet Systems Consortium</span>
     </p>
 </div>

contrib/bind9/doc/arm/man.named.html

@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: man.named.html,v 1.2.2.80 2009/09/25 01:33:40 tbox Exp $ -->
+<!-- $Id: man.named.html,v 1.2.2.82 2010/02/27 01:33:45 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -50,7 +50,7 @@
 <div class="cmdsynopsis"><p><code class="command">named</code>  [<code class="option">-4</code>] [<code class="option">-6</code>] [<code class="option">-c <em class="replaceable"><code>config-file</code></em></code>] [<code class="option">-d <em class="replaceable"><code>debug-level</code></em></code>] [<code class="option">-f</code>] [<code class="option">-g</code>] [<code class="option">-m <em class="replaceable"><code>flag</code></em></code>] [<code class="option">-n <em class="replaceable"><code>#cpus</code></em></code>] [<code class="option">-p <em class="replaceable"><code>port</code></em></code>] [<code class="option">-s</code>] [<code class="option">-S <em class="replaceable"><code>#max-socks</code></em></code>] [<code class="option">-t <em class="replaceable"><code>directory</code></em></code>] [<code class="option">-u <em class="replaceable"><code>user</code></em></code>] [<code class="option">-v</code>] [<code class="option">-x <em class="replaceable"><code>cache-file</code></em></code>]</p></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2603363"></a><h2>DESCRIPTION</h2>
+<a name="id2603984"></a><h2>DESCRIPTION</h2>
 <p><span><strong class="command">named</strong></span>
       is a Domain Name System (DNS) server,
       part of the BIND 9 distribution from ISC.  For more
@@ -65,7 +65,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2603394"></a><h2>OPTIONS</h2>
+<a name="id2604014"></a><h2>OPTIONS</h2>
 <div class="variablelist"><dl>
 <dt><span class="term">-4</span></dt>
 <dd><p>
@@ -234,7 +234,7 @@
 </dl></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2605824"></a><h2>SIGNALS</h2>
+<a name="id2605898"></a><h2>SIGNALS</h2>
 <p>
       In routine operation, signals should not be used to control
       the nameserver; <span><strong class="command">rndc</strong></span> should be used
@@ -255,7 +255,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2605874"></a><h2>CONFIGURATION</h2>
+<a name="id2605948"></a><h2>CONFIGURATION</h2>
 <p>
       The <span><strong class="command">named</strong></span> configuration file is too complex
       to describe in detail here.  A complete description is provided
@@ -264,7 +264,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2606098"></a><h2>FILES</h2>
+<a name="id2605968"></a><h2>FILES</h2>
 <div class="variablelist"><dl>
 <dt><span class="term"><code class="filename">/etc/named.conf</code></span></dt>
 <dd><p>
@@ -277,7 +277,7 @@
 </dl></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2606141"></a><h2>SEE ALSO</h2>
+<a name="id2606011"></a><h2>SEE ALSO</h2>
 <p><em class="citetitle">RFC 1033</em>,
       <em class="citetitle">RFC 1034</em>,
       <em class="citetitle">RFC 1035</em>,
@@ -290,7 +290,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2606212"></a><h2>AUTHOR</h2>
+<a name="id2606082"></a><h2>AUTHOR</h2>
 <p><span class="corpauthor">Internet Systems Consortium</span>
     </p>
 </div>

contrib/bind9/doc/arm/man.rndc-confgen.html

@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: man.rndc-confgen.html,v 1.2.2.84 2009/09/25 01:33:43 tbox Exp $ -->
+<!-- $Id: man.rndc-confgen.html,v 1.2.2.86 2010/02/27 01:33:45 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -48,7 +48,7 @@
 <div class="cmdsynopsis"><p><code class="command">rndc-confgen</code>  [<code class="option">-a</code>] [<code class="option">-b <em class="replaceable"><code>keysize</code></em></code>] [<code class="option">-c <em class="replaceable"><code>keyfile</code></em></code>] [<code class="option">-h</code>] [<code class="option">-k <em class="replaceable"><code>keyname</code></em></code>] [<code class="option">-p <em class="replaceable"><code>port</code></em></code>] [<code class="option">-r <em class="replaceable"><code>randomfile</code></em></code>] [<code class="option">-s <em class="replaceable"><code>address</code></em></code>] [<code class="option">-t <em class="replaceable"><code>chrootdir</code></em></code>] [<code class="option">-u <em class="replaceable"><code>user</code></em></code>]</p></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2606467"></a><h2>DESCRIPTION</h2>
+<a name="id2606678"></a><h2>DESCRIPTION</h2>
 <p><span><strong class="command">rndc-confgen</strong></span>
       generates configuration files
       for <span><strong class="command">rndc</strong></span>.  It can be used as a
@@ -64,7 +64,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2606601"></a><h2>OPTIONS</h2>
+<a name="id2606812"></a><h2>OPTIONS</h2>
 <div class="variablelist"><dl>
 <dt><span class="term">-a</span></dt>
 <dd>
@@ -171,7 +171,7 @@
 </dl></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2607056"></a><h2>EXAMPLES</h2>
+<a name="id2607267"></a><h2>EXAMPLES</h2>
 <p>
       To allow <span><strong class="command">rndc</strong></span> to be used with
       no manual configuration, run
@@ -188,7 +188,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2618990"></a><h2>SEE ALSO</h2>
+<a name="id2627803"></a><h2>SEE ALSO</h2>
 <p><span class="citerefentry"><span class="refentrytitle">rndc</span>(8)</span>,
       <span class="citerefentry"><span class="refentrytitle">rndc.conf</span>(5)</span>,
       <span class="citerefentry"><span class="refentrytitle">named</span>(8)</span>,
@@ -196,7 +196,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2619029"></a><h2>AUTHOR</h2>
+<a name="id2627842"></a><h2>AUTHOR</h2>
 <p><span class="corpauthor">Internet Systems Consortium</span>
     </p>
 </div>

contrib/bind9/doc/arm/man.rndc.conf.html

@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: man.rndc.conf.html,v 1.2.2.83 2009/09/25 01:33:40 tbox Exp $ -->
+<!-- $Id: man.rndc.conf.html,v 1.2.2.85 2010/02/27 01:33:45 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -50,7 +50,7 @@
 <div class="cmdsynopsis"><p><code class="command">rndc.conf</code> </p></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2603049"></a><h2>DESCRIPTION</h2>
+<a name="id2600666"></a><h2>DESCRIPTION</h2>
 <p><code class="filename">rndc.conf</code> is the configuration file
       for <span><strong class="command">rndc</strong></span>, the BIND 9 name server control
       utility.  This file has a similar structure and syntax to
@@ -135,7 +135,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2605201"></a><h2>EXAMPLE</h2>
+<a name="id2605480"></a><h2>EXAMPLE</h2>
 <pre class="programlisting">
       options {
         default-server  localhost;
@@ -209,7 +209,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2605390"></a><h2>NAME SERVER CONFIGURATION</h2>
+<a name="id2606284"></a><h2>NAME SERVER CONFIGURATION</h2>
 <p>
       The name server must be configured to accept rndc connections and
       to recognize the key specified in the <code class="filename">rndc.conf</code>
@@ -219,7 +219,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2605416"></a><h2>SEE ALSO</h2>
+<a name="id2606310"></a><h2>SEE ALSO</h2>
 <p><span class="citerefentry"><span class="refentrytitle">rndc</span>(8)</span>,
       <span class="citerefentry"><span class="refentrytitle">rndc-confgen</span>(8)</span>,
       <span class="citerefentry"><span class="refentrytitle">mmencode</span>(1)</span>,
@@ -227,7 +227,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2605454"></a><h2>AUTHOR</h2>
+<a name="id2606348"></a><h2>AUTHOR</h2>
 <p><span class="corpauthor">Internet Systems Consortium</span>
     </p>
 </div>

contrib/bind9/doc/arm/man.rndc.html

@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: man.rndc.html,v 1.2.2.82 2009/09/25 01:33:40 tbox Exp $ -->
+<!-- $Id: man.rndc.html,v 1.2.2.84 2010/02/27 01:33:45 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -50,7 +50,7 @@
 <div class="cmdsynopsis"><p><code class="command">rndc</code>  [<code class="option">-b <em class="replaceable"><code>source-address</code></em></code>] [<code class="option">-c <em class="replaceable"><code>config-file</code></em></code>] [<code class="option">-k <em class="replaceable"><code>key-file</code></em></code>] [<code class="option">-s <em class="replaceable"><code>server</code></em></code>] [<code class="option">-p <em class="replaceable"><code>port</code></em></code>] [<code class="option">-V</code>] [<code class="option">-y <em class="replaceable"><code>key_id</code></em></code>] {command}</p></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2604521"></a><h2>DESCRIPTION</h2>
+<a name="id2604801"></a><h2>DESCRIPTION</h2>
 <p><span><strong class="command">rndc</strong></span>
       controls the operation of a name
       server.  It supersedes the <span><strong class="command">ndc</strong></span> utility
@@ -79,7 +79,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2604571"></a><h2>OPTIONS</h2>
+<a name="id2604919"></a><h2>OPTIONS</h2>
 <div class="variablelist"><dl>
 <dt><span class="term">-b <em class="replaceable"><code>source-address</code></em></span></dt>
 <dd><p>
@@ -151,7 +151,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2604865"></a><h2>LIMITATIONS</h2>
+<a name="id2605144"></a><h2>LIMITATIONS</h2>
 <p><span><strong class="command">rndc</strong></span>
       does not yet support all the commands of
       the BIND 8 <span><strong class="command">ndc</strong></span> utility.
@@ -165,7 +165,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2604896"></a><h2>SEE ALSO</h2>
+<a name="id2605175"></a><h2>SEE ALSO</h2>
 <p><span class="citerefentry"><span class="refentrytitle">rndc.conf</span>(5)</span>,
       <span class="citerefentry"><span class="refentrytitle">rndc-confgen</span>(8)</span>,
       <span class="citerefentry"><span class="refentrytitle">named</span>(8)</span>,
@@ -175,7 +175,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2604951"></a><h2>AUTHOR</h2>
+<a name="id2605230"></a><h2>AUTHOR</h2>
 <p><span class="corpauthor">Internet Systems Consortium</span>
     </p>
 </div>

contrib/bind9/doc/draft/draft-ietf-6man-text-addr-representation-07.txt

@@ -3,13 +3,27 @@
 
 IPv6 Maintenance Working Group                               S. Kawamura
 Internet-Draft                                         NEC BIGLOBE, Ltd.
-Intended status: Informational                              M. Kawashima
-Expires: April 21, 2010                         NEC AccessTechnica, Ltd.
-                                                        October 18, 2009
+Updates: 4291 (if approved)                                 M. Kawashima
+Intended status: Standards Track                NEC AccessTechnica, Ltd.
+Expires: August 29, 2010                               February 25, 2010
 
 
          A Recommendation for IPv6 Address Text Representation
-              draft-ietf-6man-text-addr-representation-01
+              draft-ietf-6man-text-addr-representation-07
+
+Abstract
+
+   As IPv6 deployment increases there will be a dramatic increase in the
+   need to use IPv6 addresses in text.  While the IPv6 address
+   architecture in RFC 4291 section 2.2 describes a flexible model for
+   text representation of an IPv6 address this flexibility has been
+   causing problems for operators, system engineers, and users.  This
+   document defines a canonical textual representation format.  It does
+   not define a format for internal storage, such as within an
+   application or database.  It is expected that the canonical format is
+   followed by humans and systems when representing IPv6 addresses as
+   text, but all implementations must accept and be able to handle any
+   legitimate RFC 4291 format.
 
 Status of this Memo
 
@@ -32,41 +46,71 @@ Status of this Memo
    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html.
 
-   This Internet-Draft will expire on April 21, 2010.
+   This Internet-Draft will expire on August 29, 2010.
 
 Copyright Notice
 
-   Copyright (c) 2009 IETF Trust and the persons identified as the
+
+
+Kawamura & Kawashima     Expires August 29, 2010                [Page 1]
+
+Internet-Draft          IPv6 Text Representation           February 2010
+
+
+   Copyright (c) 2010 IETF Trust and the persons identified as the
    document authors.  All rights reserved.
 
    This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents in effect on the date of
-   publication of this document (http://trustee.ietf.org/license-info).
-   Please review these documents carefully, as they describe your rights
-   and restrictions with respect to this document.
-
-Abstract
-
-   As IPv6 network grows, there will be more engineers and also non-
-   engineers who will have the need to use an IPv6 address in text.
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the BSD License.
 
 
 
-Kawamura & Kawashima     Expires April 21, 2010                 [Page 1]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kawamura & Kawashima     Expires August 29, 2010                [Page 2]
 
-Internet-Draft          IPv6 Text Representation            October 2009
-
-
-   While the IPv6 address architecture RFC 4291 section 2.2 depicts a
-   flexible model for text representation of an IPv6 address, this
-   flexibility has been causing problems for operators, system
-   engineers, and users.  This document will describe the problems that
-   a flexible text representation has been causing.  This document also
-   recommends a canonical representation format that best avoids
-   confusion.  It is expected that the canonical format is followed by
-   humans and systems when representing IPv6 addresses as text, but all
-   implementations must accept and be able to handle any legitimate
-   RFC4291 format.
+Internet-Draft          IPv6 Text Representation           February 2010
 
 
 Table of Contents
@@ -86,87 +130,43 @@ Table of Contents
      3.2.  Parsing and Modifying  . . . . . . . . . . . . . . . . . .  7
        3.2.1.  General Summary  . . . . . . . . . . . . . . . . . . .  7
        3.2.2.  Logging  . . . . . . . . . . . . . . . . . . . . . . .  7
-       3.2.3.  Auditing: Case 1 . . . . . . . . . . . . . . . . . . .  8
+       3.2.3.  Auditing: Case 1 . . . . . . . . . . . . . . . . . . .  7
        3.2.4.  Auditing: Case 2 . . . . . . . . . . . . . . . . . . .  8
        3.2.5.  Verification . . . . . . . . . . . . . . . . . . . . .  8
        3.2.6.  Unexpected Modifying . . . . . . . . . . . . . . . . .  8
      3.3.  Operating  . . . . . . . . . . . . . . . . . . . . . . . .  8
        3.3.1.  General Summary  . . . . . . . . . . . . . . . . . . .  8
-       3.3.2.  Customer Calls . . . . . . . . . . . . . . . . . . . .  9
+       3.3.2.  Customer Calls . . . . . . . . . . . . . . . . . . . .  8
        3.3.3.  Abuse  . . . . . . . . . . . . . . . . . . . . . . . .  9
      3.4.  Other Minor Problems . . . . . . . . . . . . . . . . . . .  9
        3.4.1.  Changing Platforms . . . . . . . . . . . . . . . . . .  9
        3.4.2.  Preference in Documentation  . . . . . . . . . . . . .  9
-       3.4.3.  Legibility . . . . . . . . . . . . . . . . . . . . . . 10
-   4.  A Recommendation for IPv6 Text Representation  . . . . . . . . 10
+       3.4.3.  Legibility . . . . . . . . . . . . . . . . . . . . . .  9
+   4.  A Recommendation for IPv6 Text Representation  . . . . . . . .  9
      4.1.  Handling Leading Zeros in a 16 Bit Field . . . . . . . . . 10
      4.2.  "::" Usage . . . . . . . . . . . . . . . . . . . . . . . . 10
        4.2.1.  Shorten As Much As Possible  . . . . . . . . . . . . . 10
        4.2.2.  Handling One 16 Bit 0 Field  . . . . . . . . . . . . . 10
        4.2.3.  Choice in Placement of "::"  . . . . . . . . . . . . . 10
-     4.3.  Lower Case . . . . . . . . . . . . . . . . . . . . . . . . 11
-
-
-
-Kawamura & Kawashima     Expires April 21, 2010                 [Page 2]
-
-Internet-Draft          IPv6 Text Representation            October 2009
-
-
-   5.  Text Representation of Special Addresses . . . . . . . . . . . 11
+     4.3.  Lower Case . . . . . . . . . . . . . . . . . . . . . . . . 10
+   5.  Text Representation of Special Addresses . . . . . . . . . . . 10
    6.  Notes on Combining IPv6 Addresses with Port Numbers  . . . . . 11
-   7.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 12
+   7.  Prefix Representation  . . . . . . . . . . . . . . . . . . . . 12
    8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
    9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
    10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
-   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
-     11.1. Normative References . . . . . . . . . . . . . . . . . . . 13
+   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
+     11.1. Normative References . . . . . . . . . . . . . . . . . . . 12
      11.2. Informative References . . . . . . . . . . . . . . . . . . 13
    Appendix A.  For Developers  . . . . . . . . . . . . . . . . . . . 13
-   Appendix B.  Prefix Issues . . . . . . . . . . . . . . . . . . . . 13
    Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
 
 
 
 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kawamura & Kawashima     Expires April 21, 2010                 [Page 3]
+Kawamura & Kawashima     Expires August 29, 2010                [Page 3]
 
-Internet-Draft          IPv6 Text Representation            October 2009
+Internet-Draft          IPv6 Text Representation           February 2010
 
 
 1.  Introduction
@@ -190,11 +190,11 @@ Internet-Draft          IPv6 Text Representation            October 2009
 
       2001:DB8:0:0:1::1
 
-   All the above point to the same IPv6 address.  This flexibility has
-   caused many problems for operators, systems engineers, and customers.
-   The problems will be noted in Section 3.  Also, a canonical
-   representation format to avoid problems will be introduced in
-   Section 4.
+   All of the above examples represent the same IPv6 address.  This
+   flexibility has caused many problems for operators, systems
+   engineers, and customers.  The problems are noted in Section 3.
+   Also, a canonical representation format to avoid problems is
+   introduced in Section 4.
 
 1.1.  Requirements Language
 
@@ -213,16 +213,16 @@ Internet-Draft          IPv6 Text Representation            October 2009
       'It is not necessary to write the leading zeros in an individual
       field.'
 
-   In other words, it is also not necessary to omit leading zeros.  This
+   Conversely it is also not necessary to omit leading zeros.  This
    means that, it is possible to select from such as the following
    example.  The final 16 bit field is different, but all these
-   addresses mean the same.
+   addresses represent the same address.
 
 
 
-Kawamura & Kawashima     Expires April 21, 2010                 [Page 4]
+Kawamura & Kawashima     Expires August 29, 2010                [Page 4]
 
-Internet-Draft          IPv6 Text Representation            October 2009
+Internet-Draft          IPv6 Text Representation           February 2010
 
 
       2001:db8:aaaa:bbbb:cccc:dddd:eeee:0001
@@ -245,8 +245,8 @@ Internet-Draft          IPv6 Text Representation            October 2009
 
       2001:db8:aaaa:bbbb:cccc:dddd:0:1
 
-   In case where there are more than one zero fields, there is a choice
-   of how many fields can be shortened.  Examples follow.
+   In case where there is more than one zero fields, there is a choice
+   of how many fields can be shortened.
 
       2001:db8:0:0:0::1
 
@@ -260,8 +260,8 @@ Internet-Draft          IPv6 Text Representation            October 2009
 
       'The "::" can only appear once in an address.'
 
-   This gives a choice on where, in a single address to compress the
-   zero.  Examples are shown below.
+   This gives a choice on where in a single address to compress the
+   zero.
 
       2001:db8::aaaa:0:0:1
 
@@ -269,16 +269,16 @@ Internet-Draft          IPv6 Text Representation            October 2009
 
 2.3.  Uppercase or Lowercase
 
-   [RFC4291] does not mention about preference of uppercase or
-   lowercase.  Various flavors are shown below.
+   [RFC4291] does not mention any preference of uppercase or lowercase.
 
 
 
 
 
-Kawamura & Kawashima     Expires April 21, 2010                 [Page 5]
+
+Kawamura & Kawashima     Expires August 29, 2010                [Page 5]
 
-Internet-Draft          IPv6 Text Representation            October 2009
+Internet-Draft          IPv6 Text Representation           February 2010
 
 
       2001:db8:aaaa:bbbb:cccc:dddd:eeee:aaaa
@@ -327,49 +327,45 @@ Internet-Draft          IPv6 Text Representation            October 2009
    record is set to a database, one will likely check the output to see
    if the entry is correct.  If an entity was recorded as 2001:db8::/48,
    but the whois output showed 2001:0db8:0000::/48, most non-engineers
-   would think that their input was wrong, and will likely retry several
+   would think that their input was wrong and will likely retry several
    times or make a frustrated call to the database hostmaster.  If there
 
 
 
-Kawamura & Kawashima     Expires April 21, 2010                 [Page 6]
+Kawamura & Kawashima     Expires August 29, 2010                [Page 6]
 
-Internet-Draft          IPv6 Text Representation            October 2009
+Internet-Draft          IPv6 Text Representation           February 2010
 
 
    was a need to register the same address on different systems, and
    each system showed a different text representation, this would
    confuse people even more.  Although this document focuses on
-   addresses rather than prefixes, this is worth mentioning since
+   addresses rather than prefixes, this is worth mentioning since the
    problems encountered are mostly equal.
 
 3.1.4.  Searching for an Address in a Network Diagram
 
-   Network diagrams and blue-prints contain IP addresses as allocated to
-   system devices.  In times of trouble shooting, there may be a need to
-   search through a diagram to find the point of failure (for example,
-   if a traceroute stopped at 2001:db8::1, one would search the diagram
-   for that address).  This is a technique quite often in use in
-   enterprise networks and managed services.  Again, the different
-   flavors of text representation will result in a time-consuming
-   search, leading to longer MTTR in times of trouble.
+   Network diagrams and blueprints often show what IP addresses are
+   assigned to a system devices.  In times of trouble shooting there may
+   be a need to search through a diagram to find the point of failure
+   (for example, if a traceroute stopped at 2001:db8::1, one would
+   search the diagram for that address).  This is a technique quite
+   often in use in enterprise networks and managed services.  Again, the
+   different flavors of text representation will result in a time-
+   consuming search leading to longer MTTR in times of trouble.
 
 3.2.  Parsing and Modifying
 
 3.2.1.  General Summary
 
-   With all the possible text representation ways, each application must
-   include a module, object, link, etc. to a function that will parse
-   IPv6 addresses in a manner that no matter how it is represented, they
-   will mean the same address.  This is not too much a problem if the
-   output is to be just 'read' or 'managed' by a network engineer.
-   However, many system engineers who integrate complex computer systems
-   to corporate customers will have difficulties finding that their
-   favorite tool will not have this function, or will encounter
-   difficulties such as having to rewrite their macro's or scripts for
-   their customers.  It must be noted that each additional line of a
-   program will result in increased development fees that will be
-   charged to the customers.
+   With all the possible methods of text representation each application
+   must include a module, object, link, etc. to a function that will
+   parse IPv6 addresses in a manner that no matter how it is
+   represented, they will mean the same address.  Many system engineers
+   who integrate complex computer systems for corporate customers will
+   have difficulties finding that their favorite tool will not have this
+   function, or will encounter difficulties such as having to rewrite
+   their macros or scripts for their customers.
 
 3.2.2.  Logging
 
@@ -377,60 +373,57 @@ Internet-Draft          IPv6 Text Representation            October 2009
    address in full (such as 2001:0db8:0000:0000:1111:2222:3333:4444),
    the output would be highly unreadable compared to the IPv4 output.
    The address would have to be parsed and reformed to make it useful
-   for human reading.  This will result in additional code on the
-   applications which will result in extra fees charged to the
-   customers.  Sometimes, logging for critical systems is done by
+   for human reading.  Sometimes logging for critical systems is done by
    mirroring the same traffic to two different systems.  Care must be
-   taken that no matter what the log output is, the logs should be
+   taken so that no matter what the log output is the logs should be
    parsed so they will mean the same.
 
-
-
-
-
-Kawamura & Kawashima     Expires April 21, 2010                 [Page 7]
-
-Internet-Draft          IPv6 Text Representation            October 2009
-
-
 3.2.3.  Auditing: Case 1
 
    When a router or any other network appliance machine configuration is
    audited, there are many methods to compare the configuration
-   information of a node.  Sometimes, auditing will be done by just
-   comparing the changes made each day.  In this case, if configuration
+   information of a node.  Sometimes auditing will be done by just
+   comparing the changes made each day.  In this case if configuration
    was done such that 2001:db8::1 was changed to 2001:0db8:0000:0000:
+
+
+
+Kawamura & Kawashima     Expires August 29, 2010                [Page 7]
+
+Internet-Draft          IPv6 Text Representation           February 2010
+
+
    0000:0000:0000:0001 just because the new engineer on the block felt
-   it was better, a simple diff will tell you that a different address
-   was configured.  If this was done on a wide scale network, people
-   will be focusing on 'why the extra zeros were put in' instead of
-   doing any real auditing.  Lots of tools are just plain 'diff's that
-   do not take into account address representation rules.
+   it was better, a simple diff will show that a different address was
+   configured.  If this was done on a wide scale network people will be
+   focusing on 'why the extra zeros were put in' instead of doing any
+   real auditing.  Lots of tools are just plain diffs that do not take
+   into account address representation rules.
 
 3.2.4.  Auditing: Case 2
 
    Node configurations will be matched against an information system
-   that manages IP addresses.  If output notation is different, there
-   will need to be a script that is implemented to cover for this.  An
-   SNMP GET of an interface address and text representation in a humanly
-   written text file is highly unlikely to match on first try.
+   that manages IP addresses.  If output notation is different there
+   will need to be a script that is implemented to cover for this.  The
+   result of an SNMP GET operation, converted to text and compared to a
+   textual address written by a human is highly unlikely to match on the
+   first try.
 
 3.2.5.  Verification
 
    Some protocols require certain data fields to be verified.  One
-   example of this is X.509 certificates.  If an IPv6 address was
-   embedded in one of the fields in a certificate, and the verification
-   was done by just a simple textual comparison, the certificate may be
-   maistakenly shown as being invalid due to a difference in text
-   representation methods.
+   example of this is X.509 certificates.  If an IPv6 address field in a
+   certificate was incorrectly verified by converting it to text and
+   making a simple textual comparison to some other address, the
+   certificate may be mistakenly shown as being invalid due to a
+   difference in text representation methods.
 
 3.2.6.  Unexpected Modifying
 
    Sometimes, a system will take an address and modify it as a
    convenience.  For example, a system may take an input of
-   2001:0db8:0::1 and make the output 2001:db8::1 (which is seen in some
-   RIR databases).  If the zeros were input for a reason, the outcome
-   may be somewhat unexpected.
+   2001:0db8:0::1 and make the output 2001:db8::1.  If the zeros were
+   input for a reason, the outcome may be somewhat unexpected.
 
 3.3.  Operating
 
@@ -438,34 +431,32 @@ Internet-Draft          IPv6 Text Representation            October 2009
 
    When an operator sets an IPv6 address of a system as 2001:db8:0:0:1:
    0:0:1, the system may take the address and show the configuration
-   result as 2001:DB8::1:0:0:1.  A distinguished engineer will know that
-   the right address is set, but an operator, or a customer that is
-   communicating with the operator to solve a problem, is usually not as
-
-
-
-Kawamura & Kawashima     Expires April 21, 2010                 [Page 8]
-
-Internet-Draft          IPv6 Text Representation            October 2009
-
-
-   distinguished as we would like.  Again, the extra load in checking
-   that the IP address is the same as was intended, will result in fees
-   that will be charged to the customers.
+   result as 2001:DB8::1:0:0:1.  Someone familiar with IPv6 address
+   representation will know that the right address is set, but not
+   everyone may understand this.
 
 3.3.2.  Customer Calls
 
    When a customer calls to inquire about a suspected outage, IPv6
    address representation should be handled with care.  Not all
    customers are engineers nor have the same skill in IPv6 technology.
-   The NOC will have to take extra steps to humanly parse the address to
-   avoid having to explain to the customers that 2001:db8:0:1::1 is the
-   same as 2001:db8::1:0:0:0:1.  This is one thing that will never
-   happen in IPv4 because IPv4 address cannot be abbreviated.
+   The network operations center will have to take extra steps to
+
+
+
+Kawamura & Kawashima     Expires August 29, 2010                [Page 8]
+
+Internet-Draft          IPv6 Text Representation           February 2010
+
+
+   humanly parse the address to avoid having to explain to the customers
+   that 2001:db8:0:1::1 is the same as 2001:db8::1:0:0:0:1.  This is one
+   thing that will never happen in IPv4 because IPv4 address cannot be
+   abbreviated.
 
 3.3.3.  Abuse
 
-   Network abuse is reported along with the abusing IP address.  This
+   Network abuse reports generally include the abusing IP address.  This
    'reporting' could take any shape or form of the flexible model.  A
    team that handles network abuse must be able to tell the difference
    between a 2001:db8::1:0:1 and 2001:db8:1::0:1.  Mistakes in the
@@ -485,26 +476,14 @@ Internet-Draft          IPv6 Text Representation            October 2009
    the same code may not work as expected due to the difference in IPv6
    address text representation.  Usually, a change in a platform (e.g.
    Unix to Windows, Cisco to Juniper) will result in a major change of
-   code, but flexibility in address representation will increase the
-   work load which will again, result in fees that will be charged to
-   the customers, and also longer down time of systems.
+   code anyway, but flexibility in address representation will increase
+   the work load.
 
 3.4.2.  Preference in Documentation
 
-   A document that is edited by more than one author, may become harder
+   A document that is edited by more than one author may become harder
    to read.
 
-
-
-
-
-
-
-Kawamura & Kawashima     Expires April 21, 2010                 [Page 9]
-
-Internet-Draft          IPv6 Text Representation            October 2009
-
-
 3.4.3.  Legibility
 
    Capital case D and 0 can be quite often misread.  Capital B and 8 can
@@ -517,70 +496,89 @@ Internet-Draft          IPv6 Text Representation            October 2009
    addresses is presented in this section.  The recommendation in this
    document is one that, complies fully with [RFC4291], is implemented
    by various operating systems, and is human friendly.  The
-   recommendation in this document SHOULD be followed by humans and
-   systems when generating an address to represent as text, but all
-   implementations MUST accept any legitimate [RFC4291] format.
+   recommendation in this section SHOULD be followed by systems when
+
+
+
+Kawamura & Kawashima     Expires August 29, 2010                [Page 9]
+
+Internet-Draft          IPv6 Text Representation           February 2010
+
+
+   generating an address to represent as text, but all implementations
+   MUST accept and be able to handle any legitimate [RFC4291] format.
+   It is advised that humans also follow these recommendations when
+   spelling an address.
 
 4.1.  Handling Leading Zeros in a 16 Bit Field
 
-   Leading zeros should be chopped for human legibility and easier
-   searching.  Also, a single 16 bit 0000 field should be represented as
-   just 0.  Place holder zeros are often cause of misreading.
+   Leading zeros MUST be suppressed.  For example 2001:0db8::0001 is not
+   acceptable and must be represented as 2001:db8::1.  A single 16 bit
+   0000 field MUST be represented as 0.
 
 4.2.  "::" Usage
 
 4.2.1.  Shorten As Much As Possible
 
-   The use of "::" should be used to its maximum capability (i.e. 2001:
-   db8::0:1 is not considered as clean representation).
+   The use of symbol "::" MUST be used to its maximum capability.  For
+   example, 2001:db8::0:1 is not acceptable, because the symbol "::"
+   could have been used to produce a shorter representation 2001:db8::1.
 
 4.2.2.  Handling One 16 Bit 0 Field
 
-   "::" should not be used to shorten just one 16 bit 0 field for it
-   would tend to mislead that there are more than one 16 bit field that
-   is shortened.
+   The symbol "::" MUST NOT be used to shorten just one 16 bit 0 field.
+   For example, the representation 2001:db8:0:1:1:1:1:1 is correct, but
+   2001:db8::1:1:1:1:1 is not correct.
 
 4.2.3.  Choice in Placement of "::"
 
    When there is an alternative choice in the placement of a "::", the
-   longest run of consecutive 16 bit 0 fields should be shortened (i.e.
-   latter is shortened in 2001:0:0:1:0:0:0:1).  When the length of the
-   consecutive 16 bit 0 fields are equal (i.e. 2001:db8:0:0:1:0:0:1),
-   the former is shortened.  This is consistent with many current
-   implementations.  One idea to avoid any confusion, is for the
-   operator to not use 16 bit field 0 in the first 64 bits.  By nature
-   IPv6 addresses are usually assigned or allocated to end-users as
-   longer than 32 bits (typically 48 bits or longer).
-
-
-
-
-
-Kawamura & Kawashima     Expires April 21, 2010                [Page 10]
-
-Internet-Draft          IPv6 Text Representation            October 2009
-
+   longest run of consecutive 16 bit 0 fields MUST be shortened (i.e.
+   the sequence with three consecutive zero fields is shortened in 2001:
+   0:0:1:0:0:0:1).  When the length of the consecutive 16 bit 0 fields
+   are equal (i.e. 2001:db8:0:0:1:0:0:1), the first sequence of zero
+   bits MUST be shortened.  For example 2001:db8::1:0:0:1 is correct
+   representation.
 
 4.3.  Lower Case
 
-   Recent implementations tend to represent IPv6 address as lower case.
-   It is better to use lower case to avoid problems such as described in
-   section 3.3.3 and 3.4.3.
+   The characters "a", "b", "c", "d", "e", "f" in an IPv6 address MUST
+   be represented in lower case.
 
 
 5.  Text Representation of Special Addresses
 
    Addresses such as IPv4-Mapped IPv6 addresses, ISATAP [RFC5214], and
-   IPv4-translated addresses [RFC2765] have IPv4 addresses embedded in
-   the low-order 32 bits of the address.  These addresses have special
-   representation that may mix hexadecimal and decimal notations.  In
-   cases where there is a choice of whether to express the address as
-   fully hexadecimal or hexadecimal and decimal mixed, and if the
-   address type can be distinguished as having IPv4 addresses embedded
-   in the lower 32 bits solely from the 128bits of the address field
-   itself, mixed notation is the better choice.  However, there may be
-   situations where hexadecimal representation is chosen to meet certain
-   needs.  Addressing those needs is out of the scope of this document.
+   IPv4-translatable addresses [I-D.ietf-behave-address-format] have
+   IPv4 addresses embedded in the low-order 32 bits of the address.
+   These addresses have special representation that may mix hexadecimal
+   and dot decimal notations.  The decimal notation may be used only for
+
+
+
+Kawamura & Kawashima     Expires August 29, 2010               [Page 10]
+
+Internet-Draft          IPv6 Text Representation           February 2010
+
+
+   the last 32 bits of the address.  For these addresses, mixed notation
+   is RECOMMENDED if the following condition is met: The address can be
+   distinguished as having IPv4 addresses embedded in the lower 32 bits
+   solely from the address field through the use of a well known prefix.
+   Such prefixes are defined in [RFC4291] and [RFC2765] at the time of
+   writing.  If it is known by some external method that a given prefix
+   is used to embed IPv4, it MAY be represented as mixed notation.
+   Tools that provide options to specify prefixes that are (or are not)
+   to be represented as mixed notation may be useful.
+
+   There is a trade-off here where a recommendation to achieve exact
+   match in a search (no dot decimals whatsoever) and recommendation to
+   help the readability of an addresses (dot decimal whenever possible)
+   does not result in the same solution.  The above recommendation is
+   aimed at fixing the representation as much as possible while leaving
+   the opportunity for future well known prefixes to be represented in a
+   human friendly manner as tools adjust to newly assigned prefixes.
+
    The text representation method noted in Section 4 should be applied
    for the leading hexadecimal part (i.e. ::ffff:192.0.2.1 instead of
    0:0:0:0:0:ffff:192.0.2.1).
@@ -589,8 +587,8 @@ Internet-Draft          IPv6 Text Representation            October 2009
 6.  Notes on Combining IPv6 Addresses with Port Numbers
 
    When IPv6 addresses and port numbers are represented in text combined
-   together, there seems to be many different ways to do so.  Examples
-   are shown below.
+   together, there are many different ways to do so.  Examples are shown
+   below.
 
    o  [2001:db8::1]:80
 
@@ -606,45 +604,36 @@ Internet-Draft          IPv6 Text Representation            October 2009
 
    The situation is not much different in IPv4, but the most ambiguous
    case with IPv6 is the second bullet.  This is due to the "::"usage in
-   IPv6 addresses.  This style is not recommended for its ambiguity.
-   The [] style as expressed in [RFC3986] is recommended.  Other styles
-   are acceptable when cross-platform portability does not become an
+   IPv6 addresses.  This style is NOT RECOMMENDED for its ambiguity.
+   The [] style as expressed in [RFC3986] SHOULD be employed, and is the
+   default unless otherwise specified.  Other styles are acceptable when
+   there is exactly one style for the given context and cross-platform
+   portability does not become an issue.  For URIs containing IPv6
 
 
 
-Kawamura & Kawashima     Expires April 21, 2010                [Page 11]
+Kawamura & Kawashima     Expires August 29, 2010               [Page 11]
 
-Internet-Draft          IPv6 Text Representation            October 2009
+Internet-Draft          IPv6 Text Representation           February 2010
 
 
-   issue.
+   address literals, [RFC3986] MUST be followed, as well as the rules in
+   this document.
 
 
-7.  Conclusion
+7.  Prefix Representation
 
-   The recommended format of text representing an IPv6 address is
-   summarized as follows.
-
-      (1) omit leading zeros in a 16 bit field
-
-      (2) when using "::", shorten consecutive zero fields to their
-      maximum extent (leave no zero fields behind).
-
-      (3) "::" used where shortens address the most
-
-      (4) "::" used in the former part in case of a tie breaker
-
-      (5) do not shorten one 16 bit 0 field, but always shorten when
-      there are two or more consecutive 16 bit 0 fields
-
-      (6) use lower case
-
-   Hints for developers are written in the Appendix section.
+   Problems with prefixes are just the same as problems encountered with
+   addresses.  The text representation method of IPv6 prefixes should be
+   no different from that of IPv6 addresses.
 
 
 8.  Security Considerations
 
-   None.
+   This document notes some examples where IPv6 addresses are compared
+   in text format.  The example on Section 3.2.5 is one that may cause a
+   security risk if used for access control.  The common practice of
+   comparing X.509 data is done in binary format.
 
 
 9.  IANA Considerations
@@ -659,18 +648,10 @@ Internet-Draft          IPv6 Text Representation            October 2009
    starting this document.  We also would like to thank Brian Carpenter,
    Akira Kato, Juergen Schoenwaelder, Antonio Querubin, Dave Thaler,
    Brian Haley, Suresh Krishnan, Jerry Huang, Roman Donchenko, Heikki
-   Vatiainen for their input.  Also a very special thanks to Ron Bonica,
-   Fred Baker, Brian Haberman, Robert Hinden, Jari Arkko, and Kurt
-   Lindqvist for their support in bringing this document to the light of
-   IETF working groups.
-
-
-
-
-
-Kawamura & Kawashima     Expires April 21, 2010                [Page 12]
-
-Internet-Draft          IPv6 Text Representation            October 2009
+   Vatiainen ,Dan Wing, and Doug Barton for their input.  Also a very
+   special thanks to Ron Bonica, Fred Baker, Brian Haberman, Robert
+   Hinden, Jari Arkko, and Kurt Lindqvist for their support in bringing
+   this document to the light of IETF working groups.
 
 
 11.  References
@@ -680,17 +661,31 @@ Internet-Draft          IPv6 Text Representation            October 2009
    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.
 
+   [RFC2765]  Nordmark, E., "Stateless IP/ICMP Translation Algorithm
+              (SIIT)", RFC 2765, February 2000.
+
+   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+
+
+
+Kawamura & Kawashima     Expires August 29, 2010               [Page 12]
+
+Internet-Draft          IPv6 Text Representation           February 2010
+
+
+              Resource Identifier (URI): Generic Syntax", STD 66,
+              RFC 3986, January 2005.
+
    [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
               Architecture", RFC 4291, February 2006.
 
 11.2.  Informative References
 
-   [RFC2765]  Nordmark, E., "Stateless IP/ICMP Translation Algorithm
-              (SIIT)", RFC 2765, February 2000.
-
-   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
-              Resource Identifier (URI): Generic Syntax", STD 66,
-              RFC 3986, January 2005.
+   [I-D.ietf-behave-address-format]
+              Huitema, C., Bao, C., Bagnulo, M., Boucadair, M., and X.
+              Li, "IPv6 Addressing of IPv4/IPv6 Translators",
+              draft-ietf-behave-address-format-04 (work in progress),
+              January 2010.
 
    [RFC4038]  Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E.
               Castro, "Application Aspects of IPv6 Transition",
@@ -711,24 +706,6 @@ Appendix A.  For Developers
    be called directly.  See [RFC4038] for details.
 
 
-Appendix B.  Prefix Issues
-
-   Problems with prefixes are just the same as problems encountered with
-   addresses.  Text representation method of IPv6 prefixes should be no
-   different from that of IPv6 addresses.
-
-
-
-
-
-
-
-
-Kawamura & Kawashima     Expires April 21, 2010                [Page 13]
-
-Internet-Draft          IPv6 Text Representation            October 2009
-
-
 Authors' Addresses
 
    Seiichi Kawamura
@@ -741,6 +718,17 @@ Authors' Addresses
    Email: [email protected]
 
 
+
+
+
+
+
+
+Kawamura & Kawashima     Expires August 29, 2010               [Page 13]
+
+Internet-Draft          IPv6 Text Representation           February 2010
+
+
    Masanobu Kawashima
    NEC AccessTechnica, Ltd.
    800, Shimomata
@@ -780,6 +768,18 @@ Authors' Addresses
 
 
 
-Kawamura & Kawashima     Expires April 21, 2010                [Page 14]
+
+
+
+
+
+
+
+
+
+
+
+
+Kawamura & Kawashima     Expires August 29, 2010               [Page 14]
 
 

contrib/bind9/doc/draft/draft-ietf-dnsext-dns-tcp-requirements-03.txt

@@ -3,14 +3,14 @@
 
 DNSEXT                                                         R. Bellis
 Internet-Draft                                                Nominet UK
-Updates: 1035, 1123                                      January 6, 2010
+Updates: 1035, 1123                                       March 22, 2010
 (if approved)
 Intended status: Standards Track
-Expires: July 10, 2010
+Expires: September 23, 2010
 
 
           DNS Transport over TCP - Implementation Requirements
-               draft-ietf-dnsext-dns-tcp-requirements-02
+               draft-ietf-dnsext-dns-tcp-requirements-03
 
 Abstract
 
@@ -38,7 +38,7 @@ Status of this Memo
    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html.
 
-   This Internet-Draft will expire on July 10, 2010.
+   This Internet-Draft will expire on September 23, 2010.
 
 Copyright Notice
 
@@ -52,9 +52,9 @@ Copyright Notice
 
 
 
-Bellis                    Expires July 10, 2010                 [Page 1]
+Bellis                 Expires September 23, 2010               [Page 1]
 
-Internet-Draft                DNS over TCP                  January 2010
+Internet-Draft                DNS over TCP                    March 2010
 
 
    carefully, as they describe your rights and restrictions with respect
@@ -82,9 +82,11 @@ Table of Contents
 
    8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
 
-   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
-     9.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
-     9.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
+   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
+
+   10. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
+     10.1.  Normative References . . . . . . . . . . . . . . . . . . . 7
+     10.2.  Informative References . . . . . . . . . . . . . . . . . . 7
 
    Appendix A.  Change Log . . . . . . . . . . . . . . . . . . . . . . 8
 
@@ -106,19 +108,17 @@ Table of Contents
 
 
 
-
-
-Bellis                    Expires July 10, 2010                 [Page 2]
+Bellis                 Expires September 23, 2010               [Page 2]
 
-Internet-Draft                DNS over TCP                  January 2010
+Internet-Draft                DNS over TCP                    March 2010
 
 
 1.  Introduction
 
-   Most DNS [RFC1035] transactions take place over UDP [RFC0792].  The
-   TCP [RFC0793] is used for zone transfers and for the transfer of
-   other packets which exceed the protocol's original 512 byte packet-
-   size limit.
+   Most DNS [RFC1035] transactions take place over UDP [RFC0768].  TCP
+   [RFC0793] is always used for zone transfers and is often used for
+   messages whose sizes exceed the DNS protocol's original 512 byte
+   limit.
 
    Section 6.1.3.2 of [RFC1123] states:
 
@@ -141,7 +141,7 @@ Internet-Draft                DNS over TCP                  January 2010
    Whilst this document makes no specific recommendations to operators
    of DNS servers, it should be noted that failure to support TCP (or
    blocking of DNS over TCP at the network layer) may result in
-   resolution failure and application-level timeouts.
+   resolution failure and/or application-level timeouts.
 
 
 2.  Terminology used in this document
@@ -154,9 +154,9 @@ Internet-Draft                DNS over TCP                  January 2010
 3.  Discussion
 
    In the absence of EDNS0 (see below) the normal behaviour of any DNS
-   server needing to send a UDP response that exceeds that 512 byte
+   server needing to send a UDP response that would exceed the 512 byte
    limit is for the server to truncate the response so that it fits
-   within the 512 byte limit and set the TC flag in the response header.
+   within that limit and then set the TC flag in the response header.
    When the client receives such a response it takes the TC flag as an
    indication that it should retry over TCP instead.
 
@@ -164,9 +164,9 @@ Internet-Draft                DNS over TCP                  January 2010
 
 
 
-Bellis                    Expires July 10, 2010                 [Page 3]
+Bellis                 Expires September 23, 2010               [Page 3]
 
-Internet-Draft                DNS over TCP                  January 2010
+Internet-Draft                DNS over TCP                    March 2010
 
 
 
@@ -180,12 +180,12 @@ Internet-Draft                DNS over TCP                  January 2010
    Existing deployments of DNSSEC [RFC4033] have shown that truncation
    at the 512 byte boundary is now commonplace.  For example an NXDOMAIN
    (RCODE == 3) response from a DNSSEC signed zone using NSEC3 [RFC5155]
-   is almost invariably longer than 512 bytes.
+   is almost invariably larger than 512 bytes.
 
    Since the original core specifications for DNS were written, the
    Extension Mechanisms for DNS (EDNS0 [RFC2671]) have been introduced.
    These extensions can be used to indicate that the client is prepared
-   to receive UDP responses longer than 512 bytes.  An EDNS0 compatible
+   to receive UDP responses larger than 512 bytes.  An EDNS0 compatible
    server receiving a request from an EDNS0 compatible client may send
    UDP packets up to that client's announced buffer size without
    truncation.
@@ -193,9 +193,9 @@ Internet-Draft                DNS over TCP                  January 2010
    However, transport of UDP packets that exceed the size of the path
    MTU causes IP packet fragmentation, which has been found to be
    unreliable in some circumstances.  Many firewalls routinely block
-   fragmented IP packets, and some implementations lack the software
-   logic necessary to reassemble a fragmented datagram.  Worse still,
-   some devices deliberately refuse to handle DNS packets containing
+   fragmented IP packets, and some do not implement the algorithms
+   necessary to reassemble fragmented packets.  Worse still, some
+   network devices deliberately refuse to handle DNS packets containing
    EDNS0 options.  Other issues relating to UDP transport and packet
    size are discussed in [RFC5625].
 
@@ -210,28 +210,28 @@ Internet-Draft                DNS over TCP                  January 2010
 
 4.  Transport Protocol Selection
 
-   All DNS implementations MUST support both UDP and TCP transport.
+   All general purpose DNS implementations MUST support both UDP and TCP
+   transport.
 
-   o  Authoritative resolver implementations MUST support TCP so that
-      they may serve any long responses that they are configured to
-      serve.
+   o  Authoritative server implementations MUST support TCP so that they
+      do not limit the size of responses.
 
 
 
 
 
-Bellis                    Expires July 10, 2010                 [Page 4]
+Bellis                 Expires September 23, 2010               [Page 4]
 
-Internet-Draft                DNS over TCP                  January 2010
+Internet-Draft                DNS over TCP                    March 2010
 
 
-   o  A recursive resolver or forwarder MUST support TCP so that it does
-      not prevent long responses from a TCP-capable server from reaching
-      its TCP-capable clients.
-   o  A general purpose stub resolver implementation (e.g. an operating
-      system's DNS resolution library) MUST support TCP since to do
-      otherwise would limit its interoperability with its own clients
-      and with upstream servers.
+   o  Recursive resolver (or forwarder) implementations MUST support TCP
+      so that the do not prevent large responses from a TCP-capable
+      server from reaching its TCP-capable clients.
+   o  Stub resolver implementations (e.g. an operating system's DNS
+      resolution library) MUST support TCP since to do otherwise would
+      limit their interoperability with their own clients and with
+      upstream servers.
 
    An exception may be made for proprietary stub resolver
    implementations.  These MAY omit support for TCP if operating in an
@@ -256,7 +256,11 @@ Internet-Draft                DNS over TCP                  January 2010
 
       If the server needs to close a dormant connection to reclaim
       resources, it should wait until the connection has been idle for a
-      period on the order of two minutes.
+      period on the order of two minutes.  In particular, the server
+      should allow the SOA and AXFR request sequence (which begins a
+      refresh operation) to be made on a single connection.  Since the
+      server would be unable to answer queries anyway, a unilateral
+      close or reset may be used instead of a graceful close.
 
    Other more modern protocols (e.g.  HTTP [RFC2616]) have support for
    persistent TCP connections and operational experience has shown that
@@ -264,30 +268,28 @@ Internet-Draft                DNS over TCP                  January 2010
    under heavy load.  Intentionally opening many connections and leaving
    them dormant can trivially create a "denial of service" attack.
 
-   This document therefore RECOMMENDS that the application-level idle
-   period should be of the order of TBD seconds.
-
-   Servers MAY allow dormant connections to remain open for longer
-   periods, but for the avoidance of doubt persistent DNS connections
-   should generally be considered to be as much for the server's benefit
-   as for the client's.  Therefore if the server needs to unilaterally
-   close a dormant TCP connection it MUST be free to do so whenever
-   required.
+   This document therefore RECOMMENDS that the default application-level
+   idle period should be of the order of seconds, but does not specify
+   any particular value.  In practise the idle period may vary
+   dynamically, and servers MAY allow dormant connections to remain open
+   for longer periods as resources permit.
 
 
 
-Bellis                    Expires July 10, 2010                 [Page 5]
+Bellis                 Expires September 23, 2010               [Page 5]
 
-Internet-Draft                DNS over TCP                  January 2010
+Internet-Draft                DNS over TCP                    March 2010
 
 
-   To mitigate the risk of unintentional server overload DNS clients
+   To mitigate the risk of unintentional server overload, DNS clients
    MUST take care to minimize the number of concurrent TCP connections
-   made to any individual server.
+   made to any individual server.  Similarly servers MAY impose limits
+   on the number of concurrent TCP connections being handled for any
+   particular client.
 
-   Further recommendations for the tuning of TCP parameters to allow
-   higher throughput or improved resiliency against denial of service
-   attacks are outside the scope of this document.
+   Further recommendations for the tuning of TCP stacks to allow higher
+   throughput or improved resiliency against denial of service attacks
+   are outside the scope of this document.
 
 
 6.  Response re-ordering
@@ -309,45 +311,55 @@ Internet-Draft                DNS over TCP                  January 2010
 7.  Security Considerations
 
    Some DNS server operators have expressed concern that wider use of
-   DNS over TCP will expose them to a higher risk of "denial of service"
+   DNS over TCP will expose them to a higher risk of denial of service
    (DoS) attacks.
 
-   Whilst there is a theoretically higher risk of such attacks against
-   TCP-enabled servers, techniques for the mitigation of DoS attacks at
-   the network level have improved substantially since DNS was first
-   designed.
+   Although there is a higher risk of such attacks against TCP-enabled
+   servers, techniques for the mitigation of DoS attacks at the network
+   level have improved substantially since DNS was first designed.
 
-   The vast majority of TLD authority servers and all but one of the
-   root name servers already support TCP and the author knows of no
+   At the time of writing the vast majority of TLD authority servers and
+   all of the root name servers support TCP and the author knows of no
    evidence to suggest that TCP-based DoS attacks against existing DNS
    infrastructure are commonplace.
 
+   That notwithstanding, readers are advised to familiarise themselves
+   with [CPNI-TCP].
+
    Operators of recursive servers should ensure that they only accept
    connections from expected clients, and do not accept them from
-   unknown sources.  In the case of UDP traffic this will protect
+   unknown sources.  In the case of UDP traffic this will help protect
+
+
+
+Bellis                 Expires September 23, 2010               [Page 6]
+
+Internet-Draft                DNS over TCP                    March 2010
+
+
    against reflector attacks [RFC5358] and in the case of TCP traffic it
    will prevent an unknown client from exhausting the server's limits on
    the number of concurrent connections.
 
 
-
-
-Bellis                    Expires July 10, 2010                 [Page 6]
-
-Internet-Draft                DNS over TCP                  January 2010
-
-
 8.  IANA Considerations
 
    This document requests no IANA actions.
 
 
-9.  References
+9.  Acknowledgements
 
-9.1.  Normative References
+   The author would like to thank the document reviewers from the DNSEXT
+   Working Group, and in particular George Barwood, Alex Bligh, Alfred
+   Hoenes, Fernando Gont, Jim Reid, Paul Vixie and Nicholas Weaver.
 
-   [RFC0792]  Postel, J., "Internet Control Message Protocol", STD 5,
-              RFC 792, September 1981.
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+              August 1980.
 
    [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
               RFC 793, September 1981.
@@ -364,10 +376,23 @@ Internet-Draft                DNS over TCP                  January 2010
    [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
               RFC 2671, August 1999.
 
-9.2.  Informative References
+10.2.  Informative References
+
+   [CPNI-TCP]
+              CPNI, "Security Assessment of the Transmission Control
+              Protocol (TCP)", 2009, <http://www.cpni.gov.uk/Docs/
+              tn-03-09-security-assessment-TCP.pdf>.
 
    [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
               Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
+
+
+
+Bellis                 Expires September 23, 2010               [Page 7]
+
+Internet-Draft                DNS over TCP                    March 2010
+
+
               Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
 
    [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
@@ -386,17 +411,18 @@ Internet-Draft                DNS over TCP                  January 2010
               BCP 152, RFC 5625, August 2009.
 
 
-
-
-Bellis                    Expires July 10, 2010                 [Page 7]
-
-Internet-Draft                DNS over TCP                  January 2010
-
-
 Appendix A.  Change Log
 
    NB: to be removed by the RFC Editor before publication.
 
+   draft-ietf-dnsext-dns-tcp-requirements-03
+      Editorial nits from WGLC
+      Clarification on "general purpose"
+      Fixed ref to UDP (RFC 768)
+      Included more S.4.2.2 text from RFC 1035 and removed some from
+      this draft relating to connection resets.
+      s/long/large/ for packet sizes
+
    draft-ietf-dnsext-dns-tcp-requirements-02
       Change of title - more focus on implementation and not operation
       Re-write of some of the security section
@@ -411,6 +437,18 @@ Appendix A.  Change Log
       Initial draft
 
 
+
+
+
+
+
+
+
+Bellis                 Expires September 23, 2010               [Page 8]
+
+Internet-Draft                DNS over TCP                    March 2010
+
+
 Author's Address
 
    Ray Bellis
@@ -444,5 +482,23 @@ Author's Address
 
 
 
-Bellis                    Expires July 10, 2010                 [Page 8]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bellis                 Expires September 23, 2010               [Page 9]
 

contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-12.txt

@@ -5,60 +5,56 @@ Network Working Group                                          S. Weiler
 Internet-Draft                                              SPARTA, Inc.
 Updates: 4033, 4034, 4035, 5155                                D. Blacka
 (if approved)                                             VeriSign, Inc.
-Intended status: Standards Track                       September 5, 2009
-Expires: March 9, 2010
+Intended status: Standards Track                       November 10, 2010
+Expires: May 14, 2011
 
 
          Clarifications and Implementation Notes for DNSSECbis
-                draft-ietf-dnsext-dnssec-bis-updates-09
+                draft-ietf-dnsext-dnssec-bis-updates-12
+
+Abstract
+
+   This document is a collection of technical clarifications to the
+   DNSSECbis document set.  It is meant to serve as a resource to
+   implementors as well as a repository of DNSSECbis errata.
 
 Status of this Memo
 
-   This Internet-Draft is submitted to IETF in full conformance with the
+   This Internet-Draft is submitted in full conformance with the
    provisions of BCP 78 and BCP 79.
 
    Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
+   Task Force (IETF).  Note that other groups may also distribute
+   working documents as Internet-Drafts.  The list of current Internet-
+   Drafts is at http://datatracker.ietf.org/drafts/current/.
 
    Internet-Drafts are draft documents valid for a maximum of six months
    and may be updated, replaced, or obsoleted by other documents at any
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."
 
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on March 9, 2010.
+   This Internet-Draft will expire on May 14, 2011.
 
 Copyright Notice
 
-   Copyright (c) 2009 IETF Trust and the persons identified as the
+   Copyright (c) 2010 IETF Trust and the persons identified as the
    document authors.  All rights reserved.
 
    This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents in effect on the date of
-   publication of this document (http://trustee.ietf.org/license-info).
-   Please review these documents carefully, as they describe your rights
-   and restrictions with respect to this document.
-
-Abstract
-
-   This document is a collection of technical clarifications to the
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
 
 
 
-Weiler & Blacka           Expires March 9, 2010                 [Page 1]
+Weiler & Blacka           Expires May 14, 2011                  [Page 1]
 
-Internet-Draft       DNSSECbis Implementation Notes       September 2009
-
-
-   DNSSECbis document set.  It is meant to serve as a resource to
-   implementors as well as a repository of DNSSECbis errata.
+Internet-Draft       DNSSECbis Implementation Notes        November 2010
 
 
 Table of Contents
@@ -68,34 +64,40 @@ Table of Contents
      1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
    2.  Important Additions to DNSSSECbis  . . . . . . . . . . . . . .  3
      2.1.  NSEC3 Support  . . . . . . . . . . . . . . . . . . . . . .  3
-     2.2.  SHA-256 Support  . . . . . . . . . . . . . . . . . . . . .  3
-   3.  Security Concerns  . . . . . . . . . . . . . . . . . . . . . .  4
-     3.1.  Clarifications on Non-Existence Proofs . . . . . . . . . .  4
-     3.2.  Validating Responses to an ANY Query . . . . . . . . . . .  4
-     3.3.  Check for CNAME  . . . . . . . . . . . . . . . . . . . . .  5
-     3.4.  Insecure Delegation Proofs . . . . . . . . . . . . . . . .  5
-   4.  Interoperability Concerns  . . . . . . . . . . . . . . . . . .  5
-     4.1.  Errors in Canonical Form Type Code List  . . . . . . . . .  5
-     4.2.  Unknown DS Message Digest Algorithms . . . . . . . . . . .  5
-     4.3.  Private Algorithms . . . . . . . . . . . . . . . . . . . .  6
-     4.4.  Caution About Local Policy and Multiple RRSIGs . . . . . .  7
-     4.5.  Key Tag Calculation  . . . . . . . . . . . . . . . . . . .  7
-     4.6.  Setting the DO Bit on Replies  . . . . . . . . . . . . . .  7
-     4.7.  Setting the AD bit on Replies  . . . . . . . . . . . . . .  7
-     4.8.  Setting the CD bit on Requests . . . . . . . . . . . . . .  8
-     4.9.  Nested Trust Anchors . . . . . . . . . . . . . . . . . . .  8
-   5.  Minor Corrections and Clarifications . . . . . . . . . . . . .  8
-     5.1.  Finding Zone Cuts  . . . . . . . . . . . . . . . . . . . .  8
-     5.2.  Clarifications on DNSKEY Usage . . . . . . . . . . . . . .  9
-     5.3.  Errors in Examples . . . . . . . . . . . . . . . . . . . .  9
-     5.4.  Errors in RFC 5155 . . . . . . . . . . . . . . . . . . . .  9
-   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
-   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
-   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
-     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
-     8.2.  Informative References . . . . . . . . . . . . . . . . . . 11
-   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 11
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
+     2.2.  SHA-2 Support  . . . . . . . . . . . . . . . . . . . . . .  4
+   3.  Scaling Concerns . . . . . . . . . . . . . . . . . . . . . . .  4
+     3.1.  Implement a BAD cache  . . . . . . . . . . . . . . . . . .  4
+   4.  Security Concerns  . . . . . . . . . . . . . . . . . . . . . .  4
+     4.1.  Clarifications on Non-Existence Proofs . . . . . . . . . .  4
+     4.2.  Validating Responses to an ANY Query . . . . . . . . . . .  5
+     4.3.  Check for CNAME  . . . . . . . . . . . . . . . . . . . . .  5
+     4.4.  Insecure Delegation Proofs . . . . . . . . . . . . . . . .  5
+   5.  Interoperability Concerns  . . . . . . . . . . . . . . . . . .  5
+     5.1.  Errors in Canonical Form Type Code List  . . . . . . . . .  6
+     5.2.  Unknown DS Message Digest Algorithms . . . . . . . . . . .  6
+     5.3.  Private Algorithms . . . . . . . . . . . . . . . . . . . .  6
+     5.4.  Caution About Local Policy and Multiple RRSIGs . . . . . .  7
+     5.5.  Key Tag Calculation  . . . . . . . . . . . . . . . . . . .  7
+     5.6.  Setting the DO Bit on Replies  . . . . . . . . . . . . . .  8
+     5.7.  Setting the AD Bit on Queries  . . . . . . . . . . . . . .  8
+     5.8.  Setting the AD Bit on Replies  . . . . . . . . . . . . . .  8
+     5.9.  Handling Queries With the CD Bit Set . . . . . . . . . . .  8
+     5.10. Nested Trust Anchors . . . . . . . . . . . . . . . . . . .  9
+       5.10.1.  Closest Encloser  . . . . . . . . . . . . . . . . . .  9
+       5.10.2.  Accept Any Success  . . . . . . . . . . . . . . . . .  9
+       5.10.3.  Preference Based on Source  . . . . . . . . . . . . . 10
+   6.  Minor Corrections and Clarifications . . . . . . . . . . . . . 10
+     6.1.  Finding Zone Cuts  . . . . . . . . . . . . . . . . . . . . 10
+     6.2.  Clarifications on DNSKEY Usage . . . . . . . . . . . . . . 11
+     6.3.  Errors in Examples . . . . . . . . . . . . . . . . . . . . 11
+     6.4.  Errors in RFC 5155 . . . . . . . . . . . . . . . . . . . . 11
+   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
+   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
+   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
+     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
+     9.2.  Informative References . . . . . . . . . . . . . . . . . . 13
+   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 13
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
 
 
 
@@ -106,18 +108,18 @@ Table of Contents
 
 
 
-
-
-Weiler & Blacka           Expires March 9, 2010                 [Page 2]
+Weiler & Blacka           Expires May 14, 2011                  [Page 2]
 
-Internet-Draft       DNSSECbis Implementation Notes       September 2009
+Internet-Draft       DNSSECbis Implementation Notes        November 2010
 
 
 1.  Introduction and Terminology
 
    This document lists some additions, clarifications and corrections to
    the core DNSSECbis specification, as originally described in
-   [RFC4033], [RFC4034], and [RFC4035].
+   [RFC4033], [RFC4034], and [RFC4035], and later amended by [RFC5155].
+   (See section Section 2 for more recent additions to that core
+   document set.)
 
    It is intended to serve as a resource for implementors and as a
    repository of items that need to be addressed when advancing the
@@ -139,8 +141,9 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009
 
 2.  Important Additions to DNSSSECbis
 
-   This section updates the set of core DNSSEC protocol documents
-   originally specified in Section 10 of [RFC4033].
+   This section lists some documents that should be considered core
+   DNSSEC protocol documents in addition to those originally specified
+   in Section 10 of [RFC4033].
 
 2.1.  NSEC3 Support
 
@@ -154,32 +157,48 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009
    [RFC5155] should be considered part of the DNS Security Document
    Family as described by [RFC4033], Section 10.
 
-2.2.  SHA-256 Support
-
-   [RFC4509] describes the use of SHA-256 as a digest algorithm for use
-   with Delegation Signer (DS) RRs.  [I-D.ietf-dnsext-dnssec-rsasha256]
-   describes the use of the RSASHA256 algorithm for use in DNSKEY and
-   RRSIG RRs.  Validator implementations are strongly encouraged to
-   include support for this algorithm for DS, DNSKEY, and RRSIG records.
+   Note that the algorithm identifiers defined in RFC5155 (DSA-NSEC3-
+   SHA1 and RSASHA1-NSEC3-SHA1) and RFC5702 (RSASHA256 and RSASHA512)
+   signal that a zone MAY be using NSEC3, rather than NSEC.  The zone
+   MAY indeed be using either and validators supporting these algorithms
 
 
 
-Weiler & Blacka           Expires March 9, 2010                 [Page 3]
+Weiler & Blacka           Expires May 14, 2011                  [Page 3]
 
-Internet-Draft       DNSSECbis Implementation Notes       September 2009
+Internet-Draft       DNSSECbis Implementation Notes        November 2010
 
 
-   Both [RFC4509] and [I-D.ietf-dnsext-dnssec-rsasha256] should also be
-   considered part of the DNS Security Document Family as described by
-   [RFC4033], Section 10.
+   MUST support both NSEC3 and NSEC responses.
+
+2.2.  SHA-2 Support
+
+   [RFC4509] describes the use of SHA-256 as a digest algorithm in
+   Delegation Signer (DS) RRs.  [RFC5702] describes the use of the
+   RSASHA256 and RSASHA512 algorithms in DNSKEY and RRSIG RRs.
+   Validator implementations are strongly encouraged to include support
+   for these algorithms for DS, DNSKEY, and RRSIG records.
+
+   Both [RFC4509] and [RFC5702] should also be considered part of the
+   DNS Security Document Family as described by [RFC4033], Section 10.
 
 
-3.  Security Concerns
+3.  Scaling Concerns
+
+3.1.  Implement a BAD cache
+
+   Section 4.7 of RFC4035 permits security-aware resolvers to implement
+   a BAD cache.  Because of scaling concerns not discussed in this
+   document, that guidance has changed: security-aware resolvers SHOULD
+   implement a BAD cache, as described in RFC4035.
+
+
+4.  Security Concerns
 
    This section provides clarifications that, if overlooked, could lead
    to security issues.
 
-3.1.  Clarifications on Non-Existence Proofs
+4.1.  Clarifications on Non-Existence Proofs
 
    [RFC4035] Section 5.4 under-specifies the algorithm for checking non-
    existence proofs.  In particular, the algorithm as presented would
@@ -198,6 +217,14 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009
    that (original) owner name other than DS RRs, and all RRs below that
    owner name regardless of type.
 
+
+
+
+Weiler & Blacka           Expires May 14, 2011                  [Page 4]
+
+Internet-Draft       DNSSECbis Implementation Notes        November 2010
+
+
    Similarly, the algorithm would also allow an NSEC RR at the same
    owner name as a DNAME RR, or an NSEC3 RR at the same original owner
    name as a DNAME, to prove the non-existence of names beneath that
@@ -205,7 +232,7 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009
    to assume the non-existence of any subdomain of that NSEC/NSEC3 RR's
    (original) owner name.
 
-3.2.  Validating Responses to an ANY Query
+4.2.  Validating Responses to an ANY Query
 
    [RFC4035] does not address how to validate responses when QTYPE=*.
    As described in Section 6.2.2 of [RFC1034], a proper response to
@@ -217,19 +244,11 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009
    QNAME and QCLASS MUST be validated.  If any of those RRsets fail
    validation, the answer is considered Bogus.  If there are no RRsets
    matching QNAME and QCLASS, that fact MUST be validated according to
-
-
-
-Weiler & Blacka           Expires March 9, 2010                 [Page 4]
-
-Internet-Draft       DNSSECbis Implementation Notes       September 2009
-
-
    the rules in [RFC4035] Section 5.4 (as clarified in this document).
    To be clear, a validator must not expect to receive all records at
    the QNAME in response to QTYPE=*.
 
-3.3.  Check for CNAME
+4.3.  Check for CNAME
 
    Section 5 of [RFC4035] says little about validating responses based
    on (or that should be based on) CNAMEs.  When validating a NOERROR/
@@ -238,7 +257,7 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009
    type.  Without this check, an attacker could successfully transform a
    positive CNAME response into a NOERROR/NODATA response.
 
-3.4.  Insecure Delegation Proofs
+4.4.  Insecure Delegation Proofs
 
    [RFC4035] Section 5.2 specifies that a validator, when proving a
    delegation is not secure, needs to check for the absence of the DS
@@ -251,9 +270,18 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009
    not signed.
 
 
-4.  Interoperability Concerns
+5.  Interoperability Concerns
 
-4.1.  Errors in Canonical Form Type Code List
+
+
+
+
+Weiler & Blacka           Expires May 14, 2011                  [Page 5]
+
+Internet-Draft       DNSSECbis Implementation Notes        November 2010
+
+
+5.1.  Errors in Canonical Form Type Code List
 
    When canonicalizing DNS names, DNS names in the RDATA section of NSEC
    and RRSIG resource records are not downcased.
@@ -268,19 +296,11 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009
    Since HINFO records contain no domain names, they are not subject to
    downcasing.
 
-4.2.  Unknown DS Message Digest Algorithms
+5.2.  Unknown DS Message Digest Algorithms
 
    Section 5.2 of [RFC4035] includes rules for how to handle delegations
    to zones that are signed with entirely unsupported public key
    algorithms, as indicated by the key algorithms shown in those zone's
-
-
-
-Weiler & Blacka           Expires March 9, 2010                 [Page 5]
-
-Internet-Draft       DNSSECbis Implementation Notes       September 2009
-
-
    DS RRsets.  It does not explicitly address how to handle DS records
    that use unsupported message digest algorithms.  In brief, DS records
    using unknown or unsupported message digest algorithms MUST be
@@ -305,10 +325,18 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009
    disregards any DS records using unknown or unsupported message digest
    algorithms.
 
-4.3.  Private Algorithms
+5.3.  Private Algorithms
 
    As discussed above, section 5.2 of [RFC4035] requires that validators
    make decisions about the security status of zones based on the public
+
+
+
+Weiler & Blacka           Expires May 14, 2011                  [Page 6]
+
+Internet-Draft       DNSSECbis Implementation Notes        November 2010
+
+
    key algorithms shown in the DS records for those zones.  In the case
    of private algorithms, as described in [RFC4034] Appendix A.1.1, the
    eight-bit algorithm field in the DS RR is not conclusive about what
@@ -319,7 +347,7 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009
    needed.  In the remaining cases, the security status of the zone
    depends on whether or not the resolver supports any of the private
    algorithms in use (provided that these DS records use supported hash
-   functions, as discussed in Section 4.2).  In these cases, the
+   functions, as discussed in Section 5.2).  In these cases, the
    resolver MUST retrieve the corresponding DNSKEY for each private
    algorithm DS record and examine the public key field to determine the
    algorithm in use.  The security-aware resolver MUST ensure that the
@@ -329,17 +357,9 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009
    discussed in [RFC4035].
 
    This clarification facilitates the broader use of private algorithms,
-
-
-
-Weiler & Blacka           Expires March 9, 2010                 [Page 6]
-
-Internet-Draft       DNSSECbis Implementation Notes       September 2009
-
-
    as suggested by [RFC4955].
 
-4.4.  Caution About Local Policy and Multiple RRSIGs
+5.4.  Caution About Local Policy and Multiple RRSIGs
 
    When multiple RRSIGs cover a given RRset, [RFC4035] Section 5.3.3
    suggests that "the local resolver security policy determines whether
@@ -358,25 +378,38 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009
    method described in section 4.2.1.2 of [RFC4641] might not work
    reliably.
 
-4.5.  Key Tag Calculation
+5.5.  Key Tag Calculation
 
    [RFC4034] Appendix B.1 incorrectly defines the Key Tag field
    calculation for algorithm 1.  It correctly says that the Key Tag is
    the most significant 16 of the least significant 24 bits of the
    public key modulus.  However, [RFC4034] then goes on to incorrectly
    say that this is 4th to last and 3rd to last octets of the public key
+
+
+
+Weiler & Blacka           Expires May 14, 2011                  [Page 7]
+
+Internet-Draft       DNSSECbis Implementation Notes        November 2010
+
+
    modulus.  It is, in fact, the 3rd to last and 2nd to last octets.
 
-4.6.  Setting the DO Bit on Replies
+5.6.  Setting the DO Bit on Replies
 
-   [RFC4035] does not provide any instructions to servers as to how to
-   set the DO bit.  Some authoritative server implementations have
-   chosen to copy the DO bit settings from the incoming query to the
-   outgoing response.  Others have chosen to never set the DO bit in
-   responses.  Either behavior is permitted.  To be clear, in replies to
-   queries with the DO-bit set servers may or may not set the DO bit.
+   As stated in [RFC3225], the DO bit of the query MUST be copied in the
+   response.  At least one implementation has done something different,
+   so it may be wise for resolvers to be liberal in what they accept.
 
-4.7.  Setting the AD bit on Replies
+5.7.  Setting the AD Bit on Queries
+
+   The use of the AD bit in the query was previously undefined.  This
+   document defines it as a signal indicating that the requester
+   understands and is interested in the value of the AD bit in the
+   response.  This allows a requestor to indicate that it understands
+   the AD bit without also requesting DNSSEC data via the DO bit.
+
+5.8.  Setting the AD Bit on Replies
 
    Section 3.2.3 of [RFC4035] describes under which conditions a
    validating resolver should set or clear the AD bit in a response.  In
@@ -385,27 +418,38 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009
    conditions listed in RFC 4035, section 3.2.3, and the request
    contained either a set DO bit or a set AD bit.
 
+5.9.  Handling Queries With the CD Bit Set
+
+   When processing a request with the CD bit set, a resolver SHOULD
+   attempt to return all responsive data, even data that has failed
+   DNSSEC validation.  RFC4035 section 3.2.2 requires a resolver
+   processing a request with the CD bit set to set the CD bit on its
+   upstream queries.
+
+   The guidance in RFC4035 is ambiguous about what to do when a cached
+   response was obtained with the CD bit not set.  In the typical case,
+   no new query is required, nor does the cache need to track the state
+   of the CD bit used to make a given query.  The problem arises when
+   the cached response is a server failure (RCODE 2), which may indicate
+   that the requested data failed DNSSEC validation at an upstream
+   validating resolver.  (RFC2308 permits caching of server failures for
+   up to five minutes.)  In these cases, a new query with the CD bit set
+   is required.
+
+   For efficiency, a validator SHOULD set the CD bit on upstream queries
+   when it has a trust anchor at or above the QNAME (and thus can
+   reasonably expect to be able to validate the response).
 
 
 
-Weiler & Blacka           Expires March 9, 2010                 [Page 7]
+
+
+Weiler & Blacka           Expires May 14, 2011                  [Page 8]
 
-Internet-Draft       DNSSECbis Implementation Notes       September 2009
+Internet-Draft       DNSSECbis Implementation Notes        November 2010
 
 
-   Note that the use of the AD bit in the query was previously
-   undefined.  This document defines it as a signal indicating that the
-   requester understands and is interested in the value of the AD bit in
-   the response.  This allows a requestor to indicate that it
-   understands the AD bit without also requesting DNSSEC data via the DO
-   bit.
-
-4.8.  Setting the CD bit on Requests
-
-   When processing a request with the CD bit set, the resolver MUST set
-   the CD bit on its upstream queries.
-
-4.9.  Nested Trust Anchors
+5.10.  Nested Trust Anchors
 
    A DNSSEC validator may be configured such that, for a given response,
    more than one trust anchor could be used to validate the chain of
@@ -414,18 +458,91 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009
    When the validator is asked to validate a response to
    "www.sub.zone.example.", either trust anchor could apply.
 
-   When presented with this situation, DNSSEC validators SHOULD try all
-   applicable trust anchors until one succeeds.
+   When presented with this situation, DNSSEC validators have a choice
+   of which trust anchor(s) to use.  Which to use is a matter of
+   implementation choice.  It is possible and perhaps advisable to
+   expose the choice of policy as a configuration option.  The rest of
+   this section discusses some possible policies.  As a default, we
+   suggest that validators implement the "Accept Any Success" policy
+   described below in Section 5.10.2 while exposing other policies as
+   configuration options.
 
-   There are some scenarios where different behaviors, such as choosing
-   the trust anchor closest to the QNAME of the response, may be
-   desired.  A DNSSEC validator MAY enable such behaviors as
-   configurable overrides.
+5.10.1.  Closest Encloser
+
+   One policy is to choose the trust anchor closest to the QNAME of the
+   response.  In our example, that would be the "zone.example." trust
+   anchor.
+
+   This policy has the advantage of allowing the operator to trivially
+   override a parent zone's trust anchor with one that the operator can
+   validate in a stronger way, perhaps because the resolver operator is
+   affiliated with the zone in question.  This policy also minimizes the
+   number of public key operations needed, which may be of benefit in
+   resource-constrained environments.
+
+   This policy has the disadvantage of possibly giving the user some
+   unexpected and unnecessary validation failures when sub-zone trust
+   anchors are neglected.  As a concrete example, consider a validator
+   that configured a trust anchor for "zone.example." in 2009 and one
+   for "example." in 2011.  In 2012, "zone.example." rolls its KSK and
+   updates its DS records, but the validator operator doesn't update its
+   trust anchor.  With the "closest encloser" policy, the validator gets
+   validation failures.
+
+5.10.2.  Accept Any Success
+
+   Another policy is to try all applicable trust anchors until one gives
+   a validation result of Secure, in which case the final validation
+   result is Secure.  If and only if all applicable trust anchors give a
+   result of Insecure, the final validation result is Insecure.  If one
+   or more trust anchors lead to a Bogus result and there is no Secure
+   result, then the final validation result is Bogus.
 
 
-5.  Minor Corrections and Clarifications
 
-5.1.  Finding Zone Cuts
+Weiler & Blacka           Expires May 14, 2011                  [Page 9]
+
+Internet-Draft       DNSSECbis Implementation Notes        November 2010
+
+
+   This has the advantage of causing the fewer validation failures,
+   which may deliver a better user experience.  If one trust anchor is
+   out of date (as in our above example), the user may still be able to
+   get a Secure validation result (and see DNS responses).
+
+   This policy has the disadvantage of making the validator subject to
+   compromise of the weakest of these trust anchors while making its
+   relatively painless to keep old trust anchors configured in
+   perpetuity.
+
+5.10.3.  Preference Based on Source
+
+   When the trust anchors have come from different sources (e.g.
+   automated updates ([RFC5011]), one or more DLV registries
+   ([RFC5074]), and manually configured), a validator may wish to choose
+   between them based on the perceived reliability of those sources.
+   The order of precedence might be exposed as a configuration option.
+
+   For example, a validator might choose to prefer trust anchors found
+   in a DLV registry over those manually configured on the theory that
+   the manually configured ones will not be as aggressively maintained.
+
+   Conversely, a validator might choose to prefer manually configured
+   trust anchors over those obtained from a DLV registry on the theory
+   that the manually configured ones have been more carefully
+   authenticated.
+
+   Or the validator might do something more complicated: prefer a sub-
+   set of manually configured trust anchors (based on a configuration
+   option), then trust anchors that have been updated using the RFC5011
+   mechanism, then trust anchors from one DLV registry, then trust
+   anchors from a different DLV registry, then the rest of the manually
+   configured trust anchors.
+
+
+6.  Minor Corrections and Clarifications
+
+6.1.  Finding Zone Cuts
 
    Appendix C.8 of [RFC4035] discusses sending DS queries to the servers
    for a parent zone.  To do that, a resolver may first need to apply
@@ -436,20 +553,17 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009
    and in some situations the resolver may also need to apply special
    rules to locate the name servers for the parent zone if the resolver
    does not already have the parent's NS RRset.  Section 4.2 of
+
+
+
+Weiler & Blacka           Expires May 14, 2011                 [Page 10]
+
+Internet-Draft       DNSSECbis Implementation Notes        November 2010
+
+
    [RFC4035] specifies a mechanism for doing that.
 
-
-
-
-
-
-
-Weiler & Blacka           Expires March 9, 2010                 [Page 8]
-
-Internet-Draft       DNSSECbis Implementation Notes       September 2009
-
-
-5.2.  Clarifications on DNSKEY Usage
+6.2.  Clarifications on DNSKEY Usage
 
    Questions of the form "can I use a different DNSKEY for signing this
    RRset" have occasionally arisen.
@@ -473,7 +587,7 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009
    possible to use a single DNSKEY, with or without the SEP bit set, to
    sign the entire zone, including the DNSKEY RRset itself.
 
-5.3.  Errors in Examples
+6.3.  Errors in Examples
 
    The text in [RFC4035] Section C.1 refers to the examples in B.1 as
    "x.w.example.com" while B.1 uses "x.w.example".  This is painfully
@@ -488,23 +602,25 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009
    the reference to "a.z.w.w.example" should instead be "a.z.w.example",
    as in the previous line.
 
-5.4.  Errors in RFC 5155
+6.4.  Errors in RFC 5155
 
    A NSEC3 record that matches an Empty Non-Terminal effectively has no
    type associated with it.  This NSEC3 record has an empty type bit
    map.  Section 3.2.1 of [RFC5155] contains the statement:
 
+
+
+
+
+Weiler & Blacka           Expires May 14, 2011                 [Page 11]
+
+Internet-Draft       DNSSECbis Implementation Notes        November 2010
+
+
       Blocks with no types present MUST NOT be included.
 
    However, the same section contains a regular expression:
 
-
-
-Weiler & Blacka           Expires March 9, 2010                 [Page 9]
-
-Internet-Draft       DNSSECbis Implementation Notes       September 2009
-
-
       Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+
 
    The plus sign in the regular expression indicates that there is one
@@ -516,51 +632,49 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009
       Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )*
 
 
-6.  IANA Considerations
+7.  IANA Considerations
 
    This document specifies no IANA Actions.
 
 
-7.  Security Considerations
+8.  Security Considerations
 
    This document adds two cryptographic features to the core DNSSEC
    protocol.  Additionally, it addresses some ambiguities and omissions
    in the core DNSSEC documents that, if not recognized and addressed in
    implementations, could lead to security failures.  In particular, the
-   validation algorithm clarifications in Section 3 are critical for
+   validation algorithm clarifications in Section 4 are critical for
    preserving the security properties DNSSEC offers.  Furthermore,
-   failure to address some of the interoperability concerns in Section 4
+   failure to address some of the interoperability concerns in Section 5
    could limit the ability to later change or expand DNSSEC, including
    adding new algorithms.
 
 
-8.  References
+9.  References
 
-8.1.  Normative References
-
-   [I-D.ietf-dnsext-dnssec-rsasha256]
-              Jansen, J., "Use of SHA-2 algorithms with RSA in DNSKEY
-              and RRSIG Resource Records for DNSSEC",
-              draft-ietf-dnsext-dnssec-rsasha256-14 (work in progress),
-              June 2009.
+9.1.  Normative References
 
    [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
-              RFC 1034, STD 13, November 1987.
+              STD 13, RFC 1034, November 1987.
 
    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", RFC 2119, BCP 14, March 1997.
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3225]  Conrad, D., "Indicating Resolver Support of DNSSEC",
+              RFC 3225, December 2001.
 
    [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
               Rose, "DNS Security Introduction and Requirements",
-              RFC 4033, March 2005.
 
 
 
-Weiler & Blacka           Expires March 9, 2010                [Page 10]
+Weiler & Blacka           Expires May 14, 2011                 [Page 12]
 
-Internet-Draft       DNSSECbis Implementation Notes       September 2009
+Internet-Draft       DNSSECbis Implementation Notes        November 2010
 
 
+              RFC 4033, March 2005.
+
    [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
               Rose, "Resource Records for the DNS Security Extensions",
               RFC 4034, March 2005.
@@ -576,7 +690,11 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009
               Security (DNSSEC) Hashed Authenticated Denial of
               Existence", RFC 5155, March 2008.
 
-8.2.  Informative References
+   [RFC5702]  Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY
+              and RRSIG Resource Records for DNSSEC", RFC 5702,
+              October 2009.
+
+9.2.  Informative References
 
    [RFC3755]  Weiler, S., "Legacy Resolver Compatibility for Delegation
               Signer (DS)", RFC 3755, May 2004.
@@ -587,6 +705,12 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009
    [RFC4955]  Blacka, D., "DNS Security (DNSSEC) Experiments", RFC 4955,
               July 2007.
 
+   [RFC5011]  StJohns, M., "Automated Updates of DNS Security (DNSSEC)
+              Trust Anchors", RFC 5011, September 2007.
+
+   [RFC5074]  Weiler, S., "DNSSEC Lookaside Validation (DLV)", RFC 5074,
+              November 2007.
+
 
 Appendix A.  Acknowledgments
 
@@ -597,32 +721,33 @@ Appendix A.  Acknowledgments
    finding errors and omissions in the DNSSECbis document set, have
    provided text suitable for inclusion in this document.
 
+
+
+
+Weiler & Blacka           Expires May 14, 2011                 [Page 13]
+
+Internet-Draft       DNSSECbis Implementation Notes        November 2010
+
+
    The lack of specificity about handling private algorithms, as
-   described in Section 4.3, and the lack of specificity in handling ANY
-   queries, as described in Section 3.2, were discovered by David
+   described in Section 5.3, and the lack of specificity in handling ANY
+   queries, as described in Section 4.2, were discovered by David
    Blacka.
 
    The error in algorithm 1 key tag calculation, as described in
-   Section 4.5, was found by Abhijit Hayatnagarkar.  Donald Eastlake
-   contributed text for Section 4.5.
+   Section 5.5, was found by Abhijit Hayatnagarkar.  Donald Eastlake
+   contributed text for Section 5.5.
 
-   The bug relating to delegation NSEC RR's in Section 3.1 was found by
+   The bug relating to delegation NSEC RR's in Section 4.1 was found by
    Roy Badami.  Roy Arends found the related problem with DNAME.
 
-
-
-
-Weiler & Blacka           Expires March 9, 2010                [Page 11]
-
-Internet-Draft       DNSSECbis Implementation Notes       September 2009
-
-
    The errors in the [RFC4035] examples were found by Roy Arends, who
-   also contributed text for Section 5.3 of this document.
+   also contributed text for Section 6.3 of this document.
 
-   The editors would like to thank Ed Lewis, Danny Mayer, Olafur
-   Gudmundsson, Suzanne Woolf, and Scott Rose for their substantive
-   comments on the text of this document.
+   The editors would like to thank Alfred Hoenes, Ed Lewis, Danny Mayer,
+   Olafur Gudmundsson, Suzanne Woolf, Rickard Bellgrim, Mike St. Johns,
+   and Scott Rose for their substantive comments on the text of this
+   document.
 
 
 Authors' Addresses
@@ -655,18 +780,6 @@ Authors' Addresses
 
 
 
-
-
-
-
-
-
-
-
-
-
-
-
-
-Weiler & Blacka           Expires March 9, 2010                [Page 12]
+Weiler & Blacka           Expires May 14, 2011                 [Page 14]
 
+

contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-gost-05.txt

@@ -1,448 +0,0 @@
-DNS Extensions working group                             V.Dolmatov, Ed.  
-Internet-Draft                                            Cryptocom Ltd.    
-Intended status: Standards Track                      November 30, 2009
-Expires: May 30, 2010                                 
-
-
- Use of GOST signature algorithms in DNSKEY and RRSIG Resource Records
-                               for DNSSEC
-                 draft-ietf-dnsext-dnssec-gost-05
-
-Status of this Memo
-
-   This Internet-Draft is submitted to IETF in full conformance with the
-   provisions of BCP 78 and BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on May  10 2010.
-
-Copyright Notice
-
-   Copyright (c) 2009 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents in effect on the date of
-   publication of this document (http://trustee.ietf.org/license-info).
-   Please review these documents carefully, as they describe your rights
-   and restrictions with respect to this document.
-
-Abstract
-
-   This document describes how to produce signature and hash using 
-   GOST algorithms [DRAFT1, DRAFT2, DRAFT3] for DNSKEY, RRSIG and DS
-   resource records for use in the Domain Name System Security 
-   Extensions (DNSSEC, RFC 4033, RFC 4034, and RFC 4035).
-
-V.Dolmatov              Expires May  30, 2010               [Page 1]
-
-Table of Contents
-
-   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
-   2.  DNSKEY Resource Records . . . . . . . . . . . . . . . . . . . . 3
-     2.1.  Using a public key with existing cryptographic libraries. . 3
-     2.2.  GOST DNSKEY RR Example  . . . . . . . . . . . . . . . . . . 3
-   3.  RRSIG Resource Records  . . . . . . . . . . . . . . . . . . . . 4
-     3.1 RRSIG RR Example  . . . . . . . . . . . . . . . . . . . . . . 4
-   4.  DS Resource Records . . . . . . . . . . . . . . . . . . . . . . 5
-     4.1 DS RR Example . . . . . . . . . . . . . . . . . . . . . . . . 5
-   5.  Deployment Considerations . . . . . . . . . . . . . . . . . . . 5
-     5.1.  Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . . 5
-     5.2.  Signature Sizes . . . . . . . . . . . . . . . . . . . . . . 5
-     5.3.  Digest Sizes  . . . . . . . . . . . . . . . . . . . . . . . 5
-   6.  Implementation Considerations . . . . . . . . . . . . . . . . . 5
-     6.1.  Support for GOST signatures . . . . . . . . . . . . . . . . 5
-     6.2.  Support for NSEC3 Denial of Existence . . . . . . . . . . . 5
-     6.3.  Byte order  . . . . . . . . . . . . . . . . . . . . . . . . 5
-   7. Security consideration . . . . . . . . . . . . . . . . . . . . . 5
-   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
-   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
-   10.  References   . . . . . . . . . . . . . . . . . . . . . . . . . 6
-     10.1.  Normative References . . . . . . . . . . . . . . . . . . . 6
-     10.2.  Informative References . . . . . . . . . . . . . . . . . . 7
-   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9
-
-1.  Introduction
-
-   The Domain Name System (DNS) is the global hierarchical distributed
-   database for Internet Naming.  The DNS has been extended to use
-   cryptographic keys and digital signatures for the verification of the
-   authenticity and integrity of its data.  RFC 4033 [RFC4033], RFC 4034
-   [RFC4034], and RFC 4035 [RFC4035] describe these DNS Security
-   Extensions, called DNSSEC.
-
-   RFC 4034 describes how to store DNSKEY and RRSIG resource records,
-   and specifies a list of cryptographic algorithms to use.  This
-   document extends that list with the signature and hash algorithms 
-   GOST [GOST3410, GOST3411],
-   and specifies how to store DNSKEY data and how to produce
-   RRSIG resource records with these hash algorithms.
-
-   Familiarity with DNSSEC  and GOST signature and hash
-   algorithms is assumed in this document.
-
-   The term "GOST" is not officially defined, but is usually used to
-   refer to the collection of the Russian cryptographic algorithms
-   GOST R 34.10-2001, GOST R 34.11-94, GOST 28147-89. 
-   Since GOST 28147-89 is not used in DNSSEC, "GOST" will only refer to
-   the GOST R 34.10-2001 and GOST R 34.11-94 in this document.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-V.Dolmatov              Expires May  30, 2010                [Page 2]
-
-2.  DNSKEY Resource Records
-
-   The format of the DNSKEY RR can be found in RFC 4034 [RFC4034].
-
-   GOST R 34.10-2001 public keys are stored with the algorithm number 
-   {TBA1}.
-      
-   The wire format of the public key is compatible with 
-   RFC 4491 [RFC4491]:
-
-   According to [GOST3410], a public key is a point on the elliptic
-   curve Q = (x,y).
-
-   The wire representation of a public key MUST contain 66 octets, 
-   where the first octet designates public key parameters, the second
-   octet designates digest parameters next 32 octets contain the 
-   little-endian representation of x and the second 32 octets contain
-   the little-endian representation of y. 
-   This corresponds to the binary representation of (<y>256||<x>256) 
-   from [GOST3410], ch.  5.3.
-
-   The only valid value for both parameters octets is 0.
-   Other parameters octets values are reserved for future use.
-   
-   Corresponding public key parameters are those identified by
-   id-GostR3410-2001-CryptoPro-A-ParamSet (1.2.643.2.2.35.1) [RFC4357],
-   and the digest parameters are those identified by
-   id-GostR3411-94-CryptoProParamSet (1.2.643.2.2.30.1) [RFC4357].
-
-2.1.  Using a public key with existing cryptographic libraries
-
-   Existing GOST-aware cryptographic libraries at the time of this 
-   document writing are capable to read GOST public keys via a generic
-   X509 API if the key is encoded according to RFC 4491 [RFC4491],
-   section 2.3.2.
-
-   To make this encoding from the wire format of a GOST public key 
-   with the parameters used in this document, prepend the last 64 octets
-   of key data (in other words, substitute first two parameter octets)
-   with the following 37-byte sequence:
-
-   0x30 0x63 0x30 0x1c 0x06 0x06 0x2a 0x85 0x03 0x02 0x02 0x13 0x30 
-   0x12 0x06 0x07 0x2a 0x85 0x03 0x02 0x02 0x23 0x01 0x06 0x07 0x2a
-   0x85 0x03 0x02 0x02 0x1e 0x01 0x03 0x43 0x00 0x04 0x40
-  
-2.2.  GOST DNSKEY RR Example
-
-   Given a private key with the following value (the value of GostAsn1
-   field is split here into two lines to simplify reading; in the 
-   private key file it must be in one line):
-
-   Private-key-format: v1.2
-   Algorithm: {TBA1} (GOST)
-   GostAsn1: MEUCAQAwHAYGKoUDAgITMBIGByqFAwICIwEGByqFAwICHgEEIgQgV/S
-             2FXdMtzKJBehZvjF4lVSx6m66TwqSe/MFwKSH/3E=
-
-V.Dolmatov              Expires May  30, 2010                [Page 3]
-
-   The following DNSKEY RR stores a DNS zone key for example.net
- 
-   example.net. 86400 IN DNSKEY 256 3 {TBA1} (
-                                AADMrbi2vAs4hklTmmzGE3WWNtJ8Dll0u0jq
-                                tGRbNKeJguZQj/9EpGWmQK9hekPiPlzH2Ph6
-                                yB7i836EfzmJo5LP
-                                ) ; key id = 15820
-
-3.  RRSIG Resource Records
-
-   The value of the signature field in the RRSIG RR follows RFC 4490
-   [RFC4490] and is calculated as follows.  The values for the RDATA 
-   fields that precede the signature data are specified 
-   in RFC 4034 [RFC4034].
-
-   hash = GOSTR3411(data)
-
-   where "data" is the wire format data of the resource record set 
-   that is signed, as specified in RFC 4034 [RFC4034].
-   
-   Hash MUST be calculated with GOST R 34.11-94 parameters identified
-   by id-GostR3411-94-CryptoProParamSet [RFC4357].
-
-   Signature is calculated from the hash according to the 
-   GOST R 34.10-2001 standard and its wire format is compatible with 
-   RFC 4490 [RFC4490].
-
-   Quoting RFC 4490:
-
-   "The signature algorithm GOST R 34.10-2001 generates a digital
-   signature in the form of two 256-bit numbers, r and s.  Its octet
-   string representation consists of 64 octets, where the first 32
-   octets contain the big-endian representation of s and the second 32
-   octets contain the big-endian representation of r."
-
-3.1. RRSIG RR Example
-
-   With the private key from section 2.2 sign the following RRSet, 
-   consisting of one A record:
-
-   www.example.net. 3600 IN A 192.0.2.1
-
-   Setting the inception date to 2000-01-01 00:00:00 UTC and the 
-   expiration date to 2030-01-01 00:00:00 UTC, the following signature
-   should be created (assuming {TBA1}==249 until proper code is 
-   assigned by IANA)
-
-   www.example.net. 3600 IN RRSIG A {TBA1} 3 3600 20300101000000 (
-                                  20000101000000 15820 example.net.
-                                  2MIsZWtEx6pcfQrdl376B8sFg0qxsR8XMHpl
-                                  jHh+V6U7Qte7WwI4C3Z1nFMRVf//C9rO2dGB
-                                  rdp+C7wVoOHBqA== )
- 
-V.Dolmatov              Expires May  30, 2010                [Page 4]
-
-  Note: Several GOST signatures calculated for the same message text 
-   differ because of using of a random element is used in signature 
-   generation process.
-
-4.  DS Resource Records
-
-   GOST R 34.11-94 digest algorithm is denoted in DS RRs by the digest
-   type {TBA2}.The wire format of a digest value is compatible with 
-   RFC4490 [RFC4490], that is digest is in little-endian representation. 
-
-
-   The digest MUST always be calculated with GOST R 34.11-94 parameters
-   identified by id-GostR3411-94-CryptoProParamSet [RFC4357].
-
-4.1. DS RR Example
-
-   For key signing key (assuming {TBA1}==249 until proper code is 
-   assigned by IANA)
-
-   example.net. 86400   DNSKEY  257 3 {TBA1} (
-                                AAADr5vmKVdXo780hSRU1YZYWuMZUbEe9R7C
-                                RRLc7Wj2osDXv2XbCnIpTUx8dVLnLKmDBquu
-                                9tCz5oSsZl0cL0R2
-                                ) ; key id = 21649
-
-   The DS RR will be
-
-   example.net. 3600 IN DS 21649 {TBA1} {TBA2} (
-             A8146F448569F30B91255BA8E98DE14B18569A524C49593ADCA4103A
-             A44649C6 )
-
-5.  Deployment Considerations
-
-5.1.  Key Sizes
-
-   According to RFC4357 [RFC4357], the key size of GOST public keys
-   MUST be 512 bits.
-
-5.2.  Signature Sizes
-
-   According to the GOST signature algorithm specification [GOST3410],
-   the size of a GOST signature is 512 bits.
-
-5.3.  Digest Sizes
-
-   According to the GOST R 34.11-94 [GOST3411], the size of a GOST 
-   digest is 256 bits.
-
-6.  Implementation Considerations
-
-6.1.  Support for GOST signatures
-
-   DNSSEC aware implementations SHOULD be able to support RRSIG and
-   DNSKEY resource records created with the GOST algorithms as
-   defined in this document.
-
-V.Dolmatov              Expires May  30, 2010                [Page 5]
-
-6.2.  Support for NSEC3 Denial of Existence
-
-    Any DNSSEC-GOST implementation is required to have either NSEC or
-    NSEC3 support.
-
-6.3  Byte order
-
-    Due to the fact that all existing industry implementations of GOST
-    cryptographic libraries are returning GOST blobs in little-endian 
-    format and in order to avoid the necessity for DNSSEC developers 
-    to handle different cryptographic algorithms differently, it was
-    chosen to send these blobs on the wire "as is" without 
-    transformation of endianness.
-
-7.  Security considerations
-
-    Currently, the cryptographic resistance of the GOST 34.10-2001 
-    digital signature algorithm is estimated as 2**128 operations
-    of multiple elliptic curve point computations on prime modulus
-    of order 2**256.
-
-
-    Currently, the cryptographic resistance of GOST 34.11-94 hash
-    algorithm is estimated as 2**128 operations of computations of a
-    step hash function. (There is known method to reduce this 
-    estimate to 2**105 operations, but it demands padding the 
-    colliding message with 1024 random bit blocks each of 256 bit
-    length, thus it cannot be used in any practical implementation).
-
-8.  IANA Considerations
-
-   This document updates the IANA registry "DNS Security Algorithm 
-   Numbers [RFC4034]"
-   (http://www.iana.org/assignments/dns-sec-alg-numbers).  
-   The following entries are added to the registry:
-                                     Zone    Trans.
-   Value  Algorithm         Mnemonic Signing Sec.  References   Status
-   {TBA1} GOST R 34.10-2001 GOST     Y       *     (this memo)  OPTIONAL
-
-   This document updates the RFC 4034 Digest Types assignment
-   (section A.2)by adding the value and status for the GOST R 34.11-94
-   algorithm:
-
-   Value   Algorithm        Status
-   {TBA2}  GOST R 34.11-94  OPTIONAL
-
-9. Acknowledgments
-
-   This document is a minor extension to RFC 4034 [RFC4034].  Also, we
-   tried to follow the documents RFC 3110 [RFC3110], RFC 4509 [RFC4509],
-   and RFC 4357 [RFC4357] for consistency. The authors of and 
-   contributors to these documents are gratefully acknowledged for 
-   their hard work.
-
-V.Dolmatov              Expires May  30, 2010                [Page 6]
-
-   The following people provided additional feedback and text: Dmitry 
-   Burkov, Jaap Akkerhuis, Olafur Gundmundsson, Jelte Jansen 
-   and Wouter Wijngaards.
-
-
-10.  References
-
-10.1.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", RFC 2119, March 1997.
-
-   [RFC3110]  Eastlake D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain
-              Name System (DNS)", RFC 3110, May 2001.
-
-   [RFC4033]  Arends R., Austein R., Larson M., Massey D., and S.
-              Rose, "DNS Security Introduction and Requirements",
-              RFC 4033, March 2005.
-
-   [RFC4034]  Arends R., Austein R., Larson M., Massey D., and S.
-              Rose, "Resource Records for the DNS Security Extensions",
-              RFC 4034, March 2005.
-
-   [RFC4035]  Arends R., Austein R., Larson M., Massey D., and S.
-              Rose, "Protocol Modifications for the DNS Security
-              Extensions", RFC 4035, March 2005.
-
-   [GOST3410] "Information technology.  Cryptographic data security.
-              Signature and verification processes of [electronic]
-              digital signature.", GOST R 34.10-2001, Gosudarstvennyi
-              Standard of Russian Federation, Government Committee of
-              the Russia for Standards, 2001.  (In Russian)
-
-   [GOST3411] "Information technology.  Cryptographic Data Security.
-              Hashing function.", GOST R 34.11-94, Gosudarstvennyi
-              Standard of Russian Federation, Government Committee of
-              the Russia for Standards, 1994.  (In Russian)
-
-   [RFC4357] Popov V., Kurepkin I., and S. Leontiev, "Additional
-             Cryptographic Algorithms for Use with GOST 28147-89,
-             GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94
-             Algorithms", RFC 4357, January 2006.
-
-   [RFC4490] S. Leontiev and G. Chudov, "Using the GOST 28147-89, 
-             GOST R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001 
-             Algorithms with Cryptographic Message Syntax (CMS)",
-             RFC 4490, May 2006.
-
-   [RFC4491] S. Leontiev and D. Shefanovski, "Using the GOST 
-             R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 
-             Algorithms with the Internet X.509 Public Key 
-             Infrastructure Certificate and CRL Profile", RFC 4491,
-             May 2006. 
-
-V.Dolmatov              Expires May  30, 2010               [Page 7]
-
-
-10.2.  Informative References
-
-   [RFC4509]  Hardaker W., "Use of SHA-256 in DNSSEC Delegation Signer
-              (DS) Resource Records (RRs)", RFC 4509, May 2006.
-
-   [DRAFT1]   Dolmatov V., Kabelev D., Ustinov I., Vyshensky S.,
-              "GOST R 34.10-2001 digital signature algorithm"
-              draft-dolmatov-cryptocom-gost34102001-06, 11.10.09
-              work in progress.
-
-
-   [DRAFT2]   Dolmatov V., Kabelev D., Ustinov I., Vyshensky S.,
-              "GOST R 34.11-94 Hash function algorithm"
-              draft-dolmatov-cryptocom-gost341194-04, 11.10.09
-              work in progress.
-
-   [DRAFT3]   Dolmatov V., Kabelev D., Ustinov I., Emelyanova I.,
-              "GOST 28147-89 encryption, decryption and MAC algorithms"
-              draft-dolmatov-cryptocom-gost2814789-04, 11.10.09
-              work in progress.
-
-V.Dolmatov              Expires May  30, 2010                [Page 8]
-
-
-Authors' Addresses
-
-
-Vasily Dolmatov, Ed.
-Cryptocom Ltd.
-Kedrova 14, bld.2
-Moscow, 117218, Russian Federation
-
-EMail: [email protected]
-
-Artem Chuprina
-Cryptocom Ltd.
-Kedrova 14, bld.2
-Moscow, 117218, Russian Federation
-
-EMail: [email protected]
-
-Igor Ustinov
-Cryptocom Ltd.
-Kedrova 14, bld.2
-Moscow, 117218, Russian Federation
-
-EMail: [email protected]
-
-V.Dolmatov              Expires May  30, 2010                [Page 9]
-
-
-
-
-

contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-registry-fixes-06.txt

@@ -0,0 +1,448 @@
+
+
+
+DNS Extensions Working Group                                     S. Rose
+Internet-Draft                                                      NIST
+Updates: 2536, 2539, 3110, 4034,                         August 11, 2010
+4398, 5155, 5702, 5933
+(if approved)
+Intended status: Standards Track
+Expires: February 12, 2011
+
+
+  Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm IANA
+                                Registry
+               draft-ietf-dnsext-dnssec-registry-fixes-06
+
+Abstract
+
+   The DNS Security Extensions (DNSSEC) requires the use of
+   cryptographic algorithm suites for generating digital signatures over
+   DNS data.  There is currently an IANA registry for these algorithms
+   that is incomplete in that it lacks the implementation status of each
+   algorithm.  This document provides an applicability statement on
+   algorithm status for DNSSEC implementations.  This document replaces
+   that registry table with a new IANA registry table for Domain Name
+   System Security (DNSSEC) Algorithm Numbers which lists each
+   algorithm's status based on the current reference.  If that status is
+   not defined in the original specification, this document assigns a
+   status.
+
+Status of This Memo
+
+   This Internet-Draft is submitted to IETF in full conformance with the
+   provisions of BCP 78 and BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+
+
+
+Rose                    Expires February 12, 2011               [Page 1]
+
+Internet-Draft             IANA Registry Fixes               August 2010
+
+
+   This Internet-Draft will expire on February 12, 2011.
+
+Copyright Notice
+
+   Copyright (c) 2010 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the BSD License.
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
+     1.1.  Requirements Language . . . . . . . . . . . . . . . . . . . 3
+
+   2.  The DNS Security Algorithm Number Subregistry . . . . . . . . . 3
+     2.1.  Individual Changes  . . . . . . . . . . . . . . . . . . . . 3
+     2.2.  Domain Name System (DNS) Security Algorithm Number
+           Registry Table  . . . . . . . . . . . . . . . . . . . . . . 5
+     2.3.  Specifying New Algorithms and Updating Status of
+           Existing Entries  . . . . . . . . . . . . . . . . . . . . . 6
+
+   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
+
+   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
+
+   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
+     5.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
+     5.2.  Informative References  . . . . . . . . . . . . . . . . . . 8
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rose                    Expires February 12, 2011               [Page 2]
+
+Internet-Draft             IANA Registry Fixes               August 2010
+
+
+1.  Introduction
+
+   The Domain Name System (DNS) Security Extensions (DNSSEC) [RFC4033],
+   [RFC4034], and [RFC4035] uses digital signatures over DNS data to
+   provide source authentication and integrity protection.  DNSSEC uses
+   an IANA registry to allocate codes for digital signature algorithms
+   (consisting of a cryptographic algorithm and one-way hash function).
+
+   The original list of algorithm status is found in [RFC4034].  Other
+   DNSSEC documents have added new algorithms or changed the status of
+   algorithms in the registry.  However, currently implementors must
+   read through all the documents in order to discover the current
+   status of each algorithm in the registry.
+
+   This document replaces the current IANA registry for Domain Name
+   System Security (DNSSEC) Algorithm Numbers with a newly defined
+   registry table.  This new table (Section 2.2 below) contains a column
+   that will list the current status of each digital signature algorithm
+   in the registry at the time of writing and assigns status for some
+   algorithms used with DNSSEC that did not have an identified status in
+   their specification.  This document updates the following: [RFC2536],
+   [RFC2539], [RFC3110], [RFC4034], [RFC4398], [RFC5155], [RFC5702], and
+   [RFC5933].
+
+1.1.  Requirements Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+2.  The DNS Security Algorithm Number Subregistry
+
+   The DNS Security Algorithm Number subregistry (part of the Domain
+   Name System (DNS) Security Number registry) will be replaced with the
+   table below.  This table contains a column that contains the current
+   implementation requirements of the given algorithm.
+
+   There are additional differences to entries that are described in
+   sub-section 2.1.  The overall new registry table is in sub-section
+   2.2.  The values for the status were obtained from [RFC4034] with
+   updates for algorithms specified after the original DNSSEC
+   specification.  If no status was listed in the original
+   specification, this document assigns one.
+
+2.1.  Individual Changes
+
+   This document changes three entries in the Domain Name System
+   Security (DNSSEC) Algorithm Registry.  They are:
+
+
+
+Rose                    Expires February 12, 2011               [Page 3]
+
+Internet-Draft             IANA Registry Fixes               August 2010
+
+
+   The description for assignment number 4 is changed to "Reserved until
+   2020".
+
+   The description for assignment number 9 is changed to "Reserved until
+   2020".
+
+   The description for assignment number 11 is changed to "Reserved
+   until 2020".
+
+   Registry entries 13-251 remains Unassigned.
+
+   The status of RSASHA1-NSEC3-SHA1 and DSA-NSEC3-SHA1 are set to
+   RECOMMENDED and OPTIONAL respectively.  The difference is due to the
+   fact that RSA/SHA-1 is REQUIRED and DSA/SHA-1 is only OPTIONAL.  The
+   status of RSA/SHA-256 and RSA/SHA-512 are set to RECOMMENDED as it is
+   believed that these algorithms will replace older algorithms (e.g.
+   RSA/SHA-1) that have a perceived weakness in their hash algorithm
+   (SHA-1).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rose                    Expires February 12, 2011               [Page 4]
+
+Internet-Draft             IANA Registry Fixes               August 2010
+
+
+2.2.  Domain Name System (DNS) Security Algorithm Number Registry Table
+
+   The Domain Name System (DNS) Security Algorithm Number registry is
+   hereby specified as follows:
+
+                                  Zone  Transaction
+Number  Description    Mnemonic   Sign  Sign     Status       Reference
+------  -----------     ------    ----  -----  ------------   ---------
+  0      Reserved                                             [RFC4398]
+  1      RSA/MD5         RSAMD5     N     Y     MUST NOT      [RFC4034],
+                                                IMPLEMENT     [RFC3110]
+                                                             (this memo)
+  2      Diffie-Hellman   DH        N     Y                   [RFC2539]
+                                                             (this memo)
+  3      DSA/SHA-1       DSASHA1    Y     Y                   [RFC2536],
+                                                              [RFC4034],
+                                                             FIPS 186-3,
+                                                             FIPS 180-3
+                                                             (this memo)
+  4      Reserved until   ECC                                (this memo)
+         2020
+  5      RSA/SHA-1       RSASHA1    Y     Y     REQUIRED      [RFC4034]
+                                                             (this memo)
+  6      DSA-NSEC3-SHA1  DSA-NSEC3  Y     Y                   [RFC5155]
+                         -SHA1                               (this memo)
+  7      RSASHA1-NSEC3   RSASHA1-   Y     Y    RECOMMENDED    [RFC5155]
+         -SHA1           NSEC3-                              (this memo)
+                         SHA1
+  8      RSA/SHA-256     RSASHA256  Y     *    RECOMMENDED     [RFC5702]
+                                                             (this memo)
+  9      Reserved until                                      (this memo)
+         2020
+ 10      RSA/SHA-512     RSASHA512  Y     *    RECOMMENDED    [RFC5702]
+                                                             (this memo)
+ 11      Reserved until                                      (this memo)
+         2020
+ 12      GOST R          GOST-ECC   Y     *                   [RFC5933]
+         34.10-2001                                          (this memo)
+13-251   Unassigned
+ 252     Reserved for    INDIRECT   N     N                   [RFC4034]
+         Indirect keys                                       (this memo)
+ 253     private         PRIVATE    Y     Y                   [RFC4034]
+         algorithm                                           (this memo)
+ 254     private         PRIVATEOID Y     Y                   [RFC4034]
+         algorithm OID                                       (this memo)
+ 255     Reserved
+
+
+
+
+
+Rose                    Expires February 12, 2011               [Page 5]
+
+Internet-Draft             IANA Registry Fixes               August 2010
+
+
+2.3.  Specifying New Algorithms and Updating Status of Existing Entries
+
+   [I-D.ietf-dnsext-dnssec-alg-allocation] establishes a parallel
+   procedure for obtaining an algorithm number for new algorithms other
+   than a standards track document.  Algorithms entered into the
+   registry using that procedure do not have a listed status.
+   Specifications that follow this path do not need to obsolete or
+   update this document.
+
+   Adding a newly specified algorithm to the registry with a status
+   SHALL entail obsoleting this document and replacing the registry
+   table (with the new algorithm entry).  Altering the status column
+   value of any existing algorithm in the registry SHALL entail
+   obsoleting this document and replacing the registry table.
+
+   This document cannot be updated, only made obsolete and replaced by a
+   successor document.
+
+3.  IANA Considerations
+
+   This document replaces the Domain Name System (DNS) Security
+   Algorithm Numbers registry.  The new registry table is in Section
+   2.2.
+
+   The original Domain Name System (DNS) Security Algorithm Number
+   registry is available at http://www.iana.org/assignments/
+   dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml.
+
+4.  Security Considerations
+
+   This document replaces the Domain Name System (DNS) Security
+   Algorithm Numbers registry.  It is not meant to be a discussion on
+   algorithm superiority.  No new security considerations are raised in
+   this document.
+
+5.  References
+
+5.1.  Normative References
+
+   [I-D.ietf-dnsext-dnssec-alg-allocation]  Hoffman, P., "Cryptographic
+                                            Algorithm Identifier
+                                            Allocation for DNSSEC", draf
+                                            t-ietf-dnsext-dnssec-alg-
+                                            allocation-03 (work in
+                                            progress), March 2010.
+
+   [RFC2119]                                Bradner, S., "Key words for
+                                            use in RFCs to Indicate
+
+
+
+Rose                    Expires February 12, 2011               [Page 6]
+
+Internet-Draft             IANA Registry Fixes               August 2010
+
+
+                                            Requirement Levels", BCP 14,
+                                            RFC 2119, March 1997.
+
+   [RFC2536]                                Eastlake, D., "DSA KEYs and
+                                            SIGs in the Domain Name
+                                            System (DNS)", RFC 2536,
+                                            March 1999.
+
+   [RFC2539]                                Eastlake, D., "Storage of
+                                            Diffie-Hellman Keys in the
+                                            Domain Name System (DNS)",
+                                            RFC 2539, March 1999.
+
+   [RFC3110]                                Eastlake, D., "RSA/SHA-1
+                                            SIGs and RSA KEYs in the
+                                            Domain Name System (DNS)",
+                                            RFC 3110, May 2001.
+
+   [RFC4033]                                Arends, R., Austein, R.,
+                                            Larson, M., Massey, D., and
+                                            S. Rose, "DNS Security
+                                            Introduction and
+                                            Requirements", RFC 4033,
+                                            March 2005.
+
+   [RFC4034]                                Arends, R., Austein, R.,
+                                            Larson, M., Massey, D., and
+                                            S. Rose, "Resource Records
+                                            for the DNS Security
+                                            Extensions", RFC 4034,
+                                            March 2005.
+
+   [RFC4035]                                Arends, R., Austein, R.,
+                                            Larson, M., Massey, D., and
+                                            S. Rose, "Protocol
+                                            Modifications for the DNS
+                                            Security Extensions",
+                                            RFC 4035, March 2005.
+
+   [RFC4398]                                Josefsson, S., "Storing
+                                            Certificates in the Domain
+                                            Name System (DNS)",
+                                            RFC 4398, March 2006.
+
+   [RFC5155]                                Laurie, B., Sisson, G.,
+                                            Arends, R., and D. Blacka,
+                                            "DNS Security (DNSSEC)
+                                            Hashed Authenticated Denial
+
+
+
+Rose                    Expires February 12, 2011               [Page 7]
+
+Internet-Draft             IANA Registry Fixes               August 2010
+
+
+                                            of Existence", RFC 5155,
+                                            March 2008.
+
+   [RFC5702]                                Jansen, J., "Use of SHA-2
+                                            Algorithms with RSA in
+                                            DNSKEY and RRSIG Resource
+                                            Records for DNSSEC",
+                                            RFC 5702, October 2009.
+
+   [RFC5933]                                Dolmatov, V., Chuprina, A.,
+                                            and I. Ustinov, "Use of GOST
+                                            Signature Algorithms in
+                                            DNSKEY and RRSIG Resource
+                                            Records for DNSSEC",
+                                            RFC 5933, July 2010.
+
+5.2.  Informative References
+
+   [FIPS.180-3.2008]                        National Institute of
+                                            Standards and Technology,
+                                            "Secure Hash Standard",
+                                            FIPS PUB 180-3,
+                                            October 2008, <http://
+                                            csrc.nist.gov/publications/
+                                            fips/fips180-3/
+                                            fips180-3.pdf>.
+
+   [FIPS.186-3.2009]                        National Institute of
+                                            Standards and Technology,
+                                            "Digital Signature
+                                            Standard", FIPS PUB 186-3,
+                                            June 2009, <http://
+                                            csrc.nist.gov/publications/
+                                            fips/fips186-3/
+                                            fips_186-3.pdf>.
+
+Author's Address
+
+   Scott Rose
+   NIST
+   100 Bureau Dr.
+   Gaithersburg, MD  20899
+   USA
+
+   Phone: +1-301-975-8439
+   EMail: [email protected]
+
+
+
+
+
+Rose                    Expires February 12, 2011               [Page 8]
+

contrib/bind9/doc/draft/draft-ietf-dnsext-rfc2672bis-dname-19.txt

@@ -5,13 +5,13 @@ DNS Extensions Working Group                                     S. Rose
 Internet-Draft                                                      NIST
 Obsoletes: 2672 (if approved)                              W. Wijngaards
 Updates: 3363,4294                                            NLnet Labs
-(if approved)                                          November 12, 2009
+(if approved)                                             April 20, 2010
 Intended status: Standards Track
-Expires: May 16, 2010
+Expires: October 22, 2010
 
 
                  Update to DNAME Redirection in the DNS
-                 draft-ietf-dnsext-rfc2672bis-dname-18
+                 draft-ietf-dnsext-rfc2672bis-dname-19
 
 Abstract
 
@@ -48,18 +48,18 @@ Status of This Memo
    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html.
 
-   This Internet-Draft will expire on May 16, 2010.
+   This Internet-Draft will expire on October 22, 2010.
 
 
 
-Rose & Wijngaards         Expires May 16, 2010                  [Page 1]
+Rose & Wijngaards       Expires October 22, 2010                [Page 1]
 
-Internet-Draft              DNAME Redirection              November 2009
+Internet-Draft              DNAME Redirection                 April 2010
 
 
 Copyright Notice
 
-   Copyright (c) 2009 IETF Trust and the persons identified as the
+   Copyright (c) 2010 IETF Trust and the persons identified as the
    document authors.  All rights reserved.
 
    This document is subject to BCP 78 and the IETF Trust's Legal
@@ -108,9 +108,9 @@ Copyright Notice
 
 
 
-Rose & Wijngaards         Expires May 16, 2010                  [Page 2]
+Rose & Wijngaards       Expires October 22, 2010                [Page 2]
 
-Internet-Draft              DNAME Redirection              November 2009
+Internet-Draft              DNAME Redirection                 April 2010
 
 
 Table of Contents
@@ -120,40 +120,40 @@ Table of Contents
    2.  The DNAME Resource Record  . . . . . . . . . . . . . . . . . .  4
      2.1.  Format . . . . . . . . . . . . . . . . . . . . . . . . . .  4
      2.2.  The DNAME Substitution . . . . . . . . . . . . . . . . . .  5
-     2.3.  DNAME Owner Name not Redirected Itself . . . . . . . . . .  6
+     2.3.  DNAME Owner Name Matching the QNAME  . . . . . . . . . . .  7
      2.4.  Names Next to and Below a DNAME Record . . . . . . . . . .  7
      2.5.  Compression of the DNAME record. . . . . . . . . . . . . .  7
 
    3.  Processing . . . . . . . . . . . . . . . . . . . . . . . . . .  8
      3.1.  CNAME synthesis  . . . . . . . . . . . . . . . . . . . . .  8
-     3.2.  Server algorithm . . . . . . . . . . . . . . . . . . . . .  8
-     3.3.  Wildcards  . . . . . . . . . . . . . . . . . . . . . . . . 10
-     3.4.  Acceptance and Intermediate Storage  . . . . . . . . . . . 10
+     3.2.  Server algorithm . . . . . . . . . . . . . . . . . . . . .  9
+     3.3.  Wildcards  . . . . . . . . . . . . . . . . . . . . . . . . 11
+     3.4.  Acceptance and Intermediate Storage  . . . . . . . . . . . 11
 
    4.  DNAME Discussions in Other Documents . . . . . . . . . . . . . 11
 
-   5.  Other Issues with DNAME  . . . . . . . . . . . . . . . . . . . 12
-     5.1.  Canonical hostnames cannot be below DNAME owners . . . . . 12
-     5.2.  Dynamic Update and DNAME . . . . . . . . . . . . . . . . . 12
+   5.  Other Issues with DNAME  . . . . . . . . . . . . . . . . . . . 13
+     5.1.  Canonical hostnames cannot be below DNAME owners . . . . . 13
+     5.2.  Dynamic Update and DNAME . . . . . . . . . . . . . . . . . 13
      5.3.  DNSSEC and DNAME . . . . . . . . . . . . . . . . . . . . . 13
        5.3.1.  Signed DNAME, Unsigned Synthesized CNAME . . . . . . . 13
-       5.3.2.  DNAME Bit in NSEC Type Map . . . . . . . . . . . . . . 13
-       5.3.3.  DNAME Chains as Strong as the Weakest Link . . . . . . 13
-       5.3.4.  Validators Must Understand DNAME . . . . . . . . . . . 13
-         5.3.4.1.  DNAME in Bitmap Causes Invalid Name Error  . . . . 13
+       5.3.2.  DNAME Bit in NSEC Type Map . . . . . . . . . . . . . . 14
+       5.3.3.  DNAME Chains as Strong as the Weakest Link . . . . . . 14
+       5.3.4.  Validators Must Understand DNAME . . . . . . . . . . . 14
+         5.3.4.1.  DNAME in Bitmap Causes Invalid Name Error  . . . . 14
          5.3.4.2.  Valid Name Error Response Involving DNAME in
-                   Bitmap . . . . . . . . . . . . . . . . . . . . . . 14
-         5.3.4.3.  Response With Synthesized CNAME  . . . . . . . . . 14
+                   Bitmap . . . . . . . . . . . . . . . . . . . . . . 15
+         5.3.4.3.  Response With Synthesized CNAME  . . . . . . . . . 15
 
    6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
 
    7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
 
-   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 15
+   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 16
 
-   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
-     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 15
-     9.2.  Informative References . . . . . . . . . . . . . . . . . . 16
+   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
+     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 16
+     9.2.  Informative References . . . . . . . . . . . . . . . . . . 17
 
 
 
@@ -164,9 +164,9 @@ Table of Contents
 
 
 
-Rose & Wijngaards         Expires May 16, 2010                  [Page 3]
+Rose & Wijngaards       Expires October 22, 2010                [Page 3]
 
-Internet-Draft              DNAME Redirection              November 2009
+Internet-Draft              DNAME Redirection                 April 2010
 
 
 1.  Introduction
@@ -180,7 +180,7 @@ Internet-Draft              DNAME Redirection              November 2009
    from the queried domain name.  The difference between the two
    resource records is that the CNAME RR directs the lookup of data at
    its owner to another single name, a DNAME RR directs lookups for data
-   at descendents of its owner's name to corresponding names under a
+   at descendants of its owner's name to corresponding names under a
    different (single) node of the tree.
 
    Take for example, looking through a zone (see RFC 1034 [RFC1034],
@@ -220,9 +220,9 @@ Internet-Draft              DNAME Redirection              November 2009
 
 
 
-Rose & Wijngaards         Expires May 16, 2010                  [Page 4]
+Rose & Wijngaards       Expires October 22, 2010                [Page 4]
 
-Internet-Draft              DNAME Redirection              November 2009
+Internet-Draft              DNAME Redirection                 April 2010
 
 
    Its RDATA is comprised of a single field, <target>, which contains a
@@ -234,9 +234,10 @@ Internet-Draft              DNAME Redirection              November 2009
 
    The effect of the DNAME RR is the substitution of the record's
    <target> for its owner name, as a suffix of a domain name.  This
-   substitution has to be applied for every DNAME RR found in the
-   resolution process, which allows fairly lengthy valid chains of DNAME
-   RRs.
+   substitution is to be applied for all names below the owner name of
+   the DNAME RR.  This substitution has to be applied for every DNAME RR
+   found in the resolution process, which allows fairly lengthy valid
+   chains of DNAME RRs.
 
    Details of the substitution process, methods to avoid conflicting
    resource records, and rules for specific corner cases are given in
@@ -275,10 +276,9 @@ Internet-Draft              DNAME Redirection              November 2009
 
 
 
-
-Rose & Wijngaards         Expires May 16, 2010                  [Page 5]
+Rose & Wijngaards       Expires October 22, 2010                [Page 5]
 
-Internet-Draft              DNAME Redirection              November 2009
+Internet-Draft              DNAME Redirection                 April 2010
 
 
    In the table below, the QNAME refers to the query name.  The owner is
@@ -293,7 +293,7 @@ Internet-Draft              DNAME Redirection              November 2009
     QNAME            owner  DNAME   target         result
     ---------------- -------------- -------------- -----------------
     com.             example.com.   example.net.   <no match>
-    example.com.     example.com.   example.net.   <no match>
+    example.com.     example.com.   example.net.   [0]
     a.example.com.   example.com.   example.net.   a.example.net.
     a.b.example.com. example.com.   example.net.   a.b.example.net.
     ab.example.com.  b.example.com. example.net.   <no match>
@@ -305,6 +305,9 @@ Internet-Draft              DNAME Redirection              November 2009
     shortloop.x.x.   x.             .              shortloop.x.
     shortloop.x.     x.             .              shortloop.
 
+   [0] The result depends on the QTYPE.  If the QTYPE = DNAME, then
+       the result is "example.com." else "<no match>"
+
                    Table 1. DNAME Substitution Examples.
 
    It is possible for DNAMEs to form loops, just as CNAMEs can form
@@ -323,23 +326,32 @@ Internet-Draft              DNAME Redirection              November 2009
    DNAME record and its signature (if the zone is signed) are included
    in the answer as proof for the YXDOMAIN (value 6) RCODE.
 
-2.3.  DNAME Owner Name not Redirected Itself
+
+
+
+
+
+
+Rose & Wijngaards       Expires October 22, 2010                [Page 6]
+
+Internet-Draft              DNAME Redirection                 April 2010
+
+
+2.3.  DNAME Owner Name Matching the QNAME
 
    Unlike a CNAME RR, a DNAME RR redirects DNS names subordinate to its
    owner name; the owner name of a DNAME is not redirected itself.  The
    domain name that owns a DNAME record is allowed to have other
    resource record types at that domain name, except DNAMEs, CNAMEs or
-
-
-
-Rose & Wijngaards         Expires May 16, 2010                  [Page 6]
-
-Internet-Draft              DNAME Redirection              November 2009
-
-
    other types that have restrictions on what they can co-exist with.
+   When there is a match of the QTYPE to a type (or types) also owned by
+   the owner name the response is sourced from the owner name.  E.g., a
+   QTYPE of ANY would return the (available) types at the owner name,
+   not the target name.
+
    DNAME RRs MUST NOT appear at the same owner name as an NS RR unless
-   the owner name is the zone apex.
+   the owner name is the zone apex as this would constitute data below a
+   zone cut.
 
    If a DNAME record is present at the zone apex, there is still a need
    to have the customary SOA and NS resource records there as well.
@@ -373,6 +385,14 @@ Internet-Draft              DNAME Redirection              November 2009
 
    The DNAME owner name can be compressed like any other owner name.
    The DNAME RDATA target name MUST NOT be sent out in compressed form,
+
+
+
+Rose & Wijngaards       Expires October 22, 2010                [Page 7]
+
+Internet-Draft              DNAME Redirection                 April 2010
+
+
    so that a DNAME RR can be treated as an unknown type [RFC3597].
 
    Although the previous DNAME specification [RFC2672] (that is
@@ -386,13 +406,6 @@ Internet-Draft              DNAME Redirection              November 2009
    compression.  This document revises RFC 2672, in that there is no
    EDNS version signaling for DNAME.
 
-
-
-Rose & Wijngaards         Expires May 16, 2010                  [Page 7]
-
-Internet-Draft              DNAME Redirection              November 2009
-
-
 3.  Processing
 
    The DNAME RR causes type NS additional section processing.  This
@@ -403,22 +416,44 @@ Internet-Draft              DNAME Redirection              November 2009
 
    When preparing a response, a server performing a DNAME substitution
    will in all cases include the relevant DNAME RR in the answer
-   section.  A CNAME RR with TTL equal to the corresponding DNAME RR is
-   synthesized and included in the answer section.  The owner name of
-   the CNAME is the QNAME of the query.  The DNSSEC specification
-   [RFC4033], [RFC4034], [RFC4035] says that the synthesized CNAME does
-   not have to be signed.  The DNAME has an RRSIG and a validating
-   resolver can check the CNAME against the DNAME record and validate
-   the signature over the DNAME RR.
+   section.  Relevant includes the following cases:
 
-   Resolvers MUST be able to handle a synthesized CNAME TTL of zero or
-   equal to the TTL of the corresponding DNAME record.  A TTL of zero
-   means that the CNAME can be discarded immediately after processing
-   the answer.
+   1.  The DNAME is being employed as a substitution instruction.
+
+   2.  The DNAME itself matches the QTYPE and the owner name matches
+       QNAME.
+
+   When the owner name name matches the QNAME and the QTYPE matches
+   another type owned there, the DNAME is not included in the answer.
+
+   A CNAME RR with TTL equal to the corresponding DNAME RR is
+   synthesized and included in the answer section when the DNAME is
+   employed as a substitution instruction.  The owner name of the CNAME
+   is the QNAME of the query.  The DNSSEC specification [RFC4033],
+   [RFC4034], [RFC4035] says that the synthesized CNAME does not have to
+   be signed.  The DNAME has an RRSIG and a validating resolver can
+   check the CNAME against the DNAME record and validate the signature
+   over the DNAME RR.
 
    Servers MUST be able to answer a query for a synthesized CNAME.  Like
    other query types this invokes the DNAME, and synthesizes the CNAME
-   into the answer.
+   into the answer.  If the server in question is a cache, the
+   synthesized CNAME's TTL SHOULD be equal to the decremented TTL of the
+   cached DNAME.
+
+
+
+
+Rose & Wijngaards       Expires October 22, 2010                [Page 8]
+
+Internet-Draft              DNAME Redirection                 April 2010
+
+
+   Resolvers MUST be able to handle a synthesized CNAME TTL of zero or
+   equal to the TTL of the corresponding DNAME record (as some older
+   authoritative server implementations set the TTL of synthesized
+   CNAMEs to zero).  A TTL of zero means that the CNAME can be discarded
+   immediately after processing the answer.
 
 3.2.  Server algorithm
 
@@ -441,14 +476,6 @@ Internet-Draft              DNAME Redirection              November 2009
        process can terminate several ways:
 
 
-
-
-
-Rose & Wijngaards         Expires May 16, 2010                  [Page 8]
-
-Internet-Draft              DNAME Redirection              November 2009
-
-
        A.  If the whole of QNAME is matched, we have found the node.
 
            If the data at the node is a CNAME, and QTYPE does not match
@@ -471,6 +498,13 @@ Internet-Draft              DNAME Redirection              November 2009
            4.
 
 
+
+
+Rose & Wijngaards       Expires October 22, 2010                [Page 9]
+
+Internet-Draft              DNAME Redirection                 April 2010
+
+
        C.  If at some label, a match is impossible (i.e., the
            corresponding label does not exist), look to see whether the
            last label matched has a DNAME record.
@@ -497,14 +531,6 @@ Internet-Draft              DNAME Redirection              November 2009
            set the owner of the RR to be QNAME, and not the node with
            the "*" label.  If the data at the node with the "*" label is
            a CNAME, and QTYPE doesn't match CNAME, copy the CNAME RR
-
-
-
-Rose & Wijngaards         Expires May 16, 2010                  [Page 9]
-
-Internet-Draft              DNAME Redirection              November 2009
-
-
            into the answer section of the response changing the owner
            name to the QNAME, change QNAME to the canonical name in the
            CNAME RR, and go back to step 1.  Otherwise, Go to step 6.
@@ -527,6 +553,14 @@ Internet-Draft              DNAME Redirection              November 2009
    6.  Using local data only, attempt to add other RRs which may be
        useful to the additional section of the query.  Exit.
 
+
+
+
+Rose & Wijngaards       Expires October 22, 2010               [Page 10]
+
+Internet-Draft              DNAME Redirection                 April 2010
+
+
    Note that there will be at most one ancestor with a DNAME as
    described in step 4 unless some zone's data is in violation of the
    no-descendants limitation in section 3.  An implementation might take
@@ -553,14 +587,6 @@ Internet-Draft              DNAME Redirection              November 2009
    Recursive caching name servers can encounter data at names below the
    owner name of a DNAME RR, due to a change at the authoritative server
    where data from before and after the change resides in the cache.
-
-
-
-Rose & Wijngaards         Expires May 16, 2010                 [Page 10]
-
-Internet-Draft              DNAME Redirection              November 2009
-
-
    This conflict situation is a transitional phase that ends when the
    old data times out.  The caching name server can opt to store both
    old and new data and treat each as if the other did not exist, or
@@ -580,6 +606,17 @@ Internet-Draft              DNAME Redirection              November 2009
    In [RFC2181], in Section 10.3., the discussion on MX and NS records
    touches on redirection by CNAMEs, but this also holds for DNAMEs.
 
+
+
+
+
+
+
+Rose & Wijngaards       Expires October 22, 2010               [Page 11]
+
+Internet-Draft              DNAME Redirection                 April 2010
+
+
    Excerpt from 10.3.  MX and NS records (in RFC 2181).
 
            The domain name used as the value of a NS resource record,
@@ -604,19 +641,6 @@ Internet-Draft              DNAME Redirection              November 2009
    would greatly improve the manageability of the IPv6 reverse tree.
    These changes are made explicit below.
 
-
-
-
-
-
-
-
-
-Rose & Wijngaards         Expires May 16, 2010                 [Page 11]
-
-Internet-Draft              DNAME Redirection              November 2009
-
-
    In [RFC3363], the paragraph
 
      "The issues for DNAME in the reverse mapping tree appears to be
@@ -639,6 +663,16 @@ Internet-Draft              DNAME Redirection              November 2009
      "Those nodes are NOT RECOMMENDED to support the experimental
      A6 Resource Record [RFC3363]."
 
+
+
+
+
+
+Rose & Wijngaards       Expires October 22, 2010               [Page 12]
+
+Internet-Draft              DNAME Redirection                 April 2010
+
+
 5.  Other Issues with DNAME
 
    There are several issues to be aware of about the use of DNAME.
@@ -665,19 +699,13 @@ Internet-Draft              DNAME Redirection              November 2009
 
    DNAME records can be added, changed and removed in a zone using
    dynamic update transactions.  Adding a DNAME RR to a zone occludes
-
-
-
-Rose & Wijngaards         Expires May 16, 2010                 [Page 12]
-
-Internet-Draft              DNAME Redirection              November 2009
-
-
    any domain names that may exist under the added DNAME.
 
-   A server MUST reject a dynamic update message that attempts to add a
-   DNAME RR at a name that already has a CNAME RR or another DNAME RR
-   associated with that name.
+   A server MUST ignore a dynamic update message that attempts to add a
+   non-DNAME/CNAME RR at a name that already has a DNAME RR associated
+   with that name.  Otherwise, replace the DNAME RR with the DNAME (or
+   CNAME) update RR.  This is similar behavior to dynamic updates to an
+   owner name of a CNAME RR [RFC2136].
 
 5.3.  DNSSEC and DNAME
 
@@ -693,12 +721,20 @@ Internet-Draft              DNAME Redirection              November 2009
    RR and then checking that the CNAME was properly synthesized is
    sufficient proof.
 
+
+
+
+Rose & Wijngaards       Expires October 22, 2010               [Page 13]
+
+Internet-Draft              DNAME Redirection                 April 2010
+
+
 5.3.2.  DNAME Bit in NSEC Type Map
 
    In any negative response, the NSEC or NSEC3 [RFC5155] record type bit
    map SHOULD be checked to see that there was no DNAME that could have
    been applied.  If the DNAME bit in the type bit map is set and the
-   query name is a subdomain of the closest encloser that is asserted,
+   query name is a sub-domain of the closest encloser that is asserted,
    then DNAME substitution should have been done, but the substitution
    has not been done as specified.
 
@@ -715,21 +751,14 @@ Internet-Draft              DNAME Redirection              November 2009
 
    Below are examples of why DNSSEC validators MUST understand DNAME.
    In the examples below, SOA records, wildcard denial NSECs and other
-   material not under discussion has been omitted.
+   material not under discussion has been omitted or shortened.
 
 5.3.4.1.  DNAME in Bitmap Causes Invalid Name Error
 
+   ;; Header: QR AA RCODE=3(NXDOMAIN)
+   ;; OPT PSEUDOSECTION:
+   ; EDNS: version: 0, flags: do; udp: 4096
 
-
-
-
-
-Rose & Wijngaards         Expires May 16, 2010                 [Page 13]
-
-Internet-Draft              DNAME Redirection              November 2009
-
-
-   ;; Header: QR AA DO RCODE=3(NXDOMAIN)
    ;; Question
    foo.bar.example.com. IN A
    ;; Authority
@@ -745,9 +774,23 @@ Internet-Draft              DNAME Redirection              November 2009
    If the DNAME bit had not been set in the NSEC record above then the
    answer would have validated as a correct name error response.
 
+
+
+
+
+
+
+Rose & Wijngaards       Expires October 22, 2010               [Page 14]
+
+Internet-Draft              DNAME Redirection                 April 2010
+
+
 5.3.4.2.  Valid Name Error Response Involving DNAME in Bitmap
 
-   ;; Header: QR AA DO RCODE=3(NXDOMAIN)
+   ;; Header: QR AA RCODE=3(NXDOMAIN)
+   ;; OPT PSEUDOSECTION:
+   ; EDNS: version: 0, flags: do; udp: 4096
+
    ;; Question
    cee.example.com. IN A
    ;; Authority
@@ -760,7 +803,10 @@ Internet-Draft              DNAME Redirection              November 2009
 
 5.3.4.3.  Response With Synthesized CNAME
 
-   ;; Header: QR AA DO RCODE=0(NOERROR)
+   ;; Header: QR AA RCODE=0(NOERROR)
+   ;; OPT PSEUDOSECTION:
+   ; EDNS: version: 0, flags: do; udp: 4096
+
    ;; Question
    foo.bar.example.com. IN A
    ;; Answer
@@ -777,14 +823,6 @@ Internet-Draft              DNAME Redirection              November 2009
    recursively resolve further to query for the foo.bar.example.net A
    record.
 
-
-
-
-Rose & Wijngaards         Expires May 16, 2010                 [Page 14]
-
-Internet-Draft              DNAME Redirection              November 2009
-
-
 6.  IANA Considerations
 
    The DNAME Resource Record type code 39 (decimal) originally has been
@@ -795,6 +833,14 @@ Internet-Draft              DNAME Redirection              November 2009
 
    DNAME redirects queries elsewhere, which may impact security based on
    policy and the security status of the zone with the DNAME and the
+
+
+
+Rose & Wijngaards       Expires October 22, 2010               [Page 15]
+
+Internet-Draft              DNAME Redirection                 April 2010
+
+
    redirection zone's security status.  For validating resolvers, the
    lowest security status of the links in the chain of CNAME and DNAME
    redirections is applied to the result.
@@ -833,14 +879,6 @@ Internet-Draft              DNAME Redirection              November 2009
 
    [RFC2136]  Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
               "Dynamic Updates in the Domain Name System (DNS UPDATE)",
-
-
-
-Rose & Wijngaards         Expires May 16, 2010                 [Page 15]
-
-Internet-Draft              DNAME Redirection              November 2009
-
-
               RFC 2136, April 1997.
 
    [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
@@ -851,6 +889,14 @@ Internet-Draft              DNAME Redirection              November 2009
               February 2000.
 
    [RFC3597]  Gustafsson, A., "Handling of Unknown DNS Resource Record
+
+
+
+Rose & Wijngaards       Expires October 22, 2010               [Page 16]
+
+Internet-Draft              DNAME Redirection                 April 2010
+
+
               (RR) Types", RFC 3597, September 2003.
 
    [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
@@ -892,9 +938,19 @@ Internet-Draft              DNAME Redirection              November 2009
 
 
 
-Rose & Wijngaards         Expires May 16, 2010                 [Page 16]
+
+
+
+
+
+
+
+
+
+
+Rose & Wijngaards       Expires October 22, 2010               [Page 17]
 
-Internet-Draft              DNAME Redirection              November 2009
+Internet-Draft              DNAME Redirection                 April 2010
 
 
 Authors' Addresses
@@ -907,7 +963,7 @@ Authors' Addresses
 
    Phone: +1-301-975-8439
    Fax:   +1-301-975-6238
-   EMail: scottr@nist.gov
+   EMail: scottr.nist@gmail.com
 
 
    Wouter Wijngaards
@@ -948,6 +1004,5 @@ Authors' Addresses
 
 
 
-Rose & Wijngaards         Expires May 16, 2010                 [Page 17]
+Rose & Wijngaards       Expires October 22, 2010               [Page 18]
 
-

contrib/bind9/doc/draft/draft-ietf-dnsext-rfc3597-bis-02.txt

@@ -6,13 +6,20 @@
 
 INTERNET-DRAFT                                             A. Gustafsson
                                           Araneus Information Systems Oy
-                                                      September 23, 2009
+                                                       February 24, 2010
 
 Intended status: Draft Standard
 Obsoletes: RFC3597
 
            Handling of Unknown DNS Resource Record (RR) Types
-                  draft-ietf-dnsext-rfc3597-bis-00.txt
+                  draft-ietf-dnsext-rfc3597-bis-02.txt
+
+Abstract
+
+   Extending the Domain Name System (DNS) with new Resource Record (RR)
+   types should not requires changes to name server software.  This
+   document specifies how new RR types are transparently handled by DNS
+   software.
 
 Status of this Memo
 
@@ -36,30 +43,27 @@ Status of this Memo
 
 Copyright Notice
 
-   Copyright (c) 2009 IETF Trust and the persons identified as the
-   document authors. All rights reserved.
+   Copyright (c) 2010 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
 
    This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents in effect on the date of
-   publication of this document (http://trustee.ietf.org/license-info).
-   Please review these documents carefully, as they describe your rights
-   and restrictions with respect to this document.
-
-Abstract
-
-   Extending the Domain Name System (DNS) with new Resource Record (RR)
-   types should not requires changes to name server software.  This
-   document specifies how new RR types are transparently handled by DNS
-   software.
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document. Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document. Code Components extracted from this document must
 
 
 
-
-Expires March 2010           Standards Track                    [Page 1]
+Expires August 2010          Standards Track                    [Page 1]
 
-draft-ietf-dnsext-rfc3597-bis-00.txt                           July 2009
+draft-ietf-dnsext-rfc3597-bis-02.txt                       February 2010
 
 
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
 1.  Introduction
 
    The DNS [RFC1034] is designed to be extensible to support new
@@ -78,10 +82,13 @@ draft-ietf-dnsext-rfc3597-bis-00.txt                           July 2009
    types by allowing them to be treated transparently by existing
    implementations.  Thanks to the widespread adoption of that
    specification, much of the DNS is now capable of handling new record
-   types without software changes.
+   types without software changes.  Another development that has
+   simplified the introduction of new DNS RR types is the adoption of a
+   simpler IANA allocation procedure for RR types [RFC5395].
 
    This document is a self-contained revised specification supplanting
-   and obsoleting [RFC3597].
+   and obsoleting RFC 3597, with the aim of allowing the specification
+   to advance on the Standards Track.
 
 2.  Definitions
 
@@ -96,25 +103,24 @@ draft-ietf-dnsext-rfc3597-bis-00.txt                           July 2009
    Meta-TYPEs.  Such an RR cannot be converted to a type-specific text
    format, compressed, or otherwise handled in a type-specific way.
 
-   In the case of a type whose RDATA format is class specific, an RR is
-   considered to be of unknown type when the RDATA format for that
-   combination of type and class is not known.
+   In the case of a type whose RDATA format is known to be class
+   specific, an RR is considered to be of unknown type when the RDATA
+   format for that combination of type and class is not known.
 
 3.  Transparency
 
+
+
+Expires August 2010          Standards Track                    [Page 2]
+
+draft-ietf-dnsext-rfc3597-bis-02.txt                       February 2010
+
+
    To enable new RR types to be deployed without server changes, name
    servers and resolvers MUST handle RRs of unknown type transparently.
-   That is, they must treat the RDATA section of such RRs as
-   unstructured binary data, storing and transmitting it without change
-   [RFC1123].
-
-
-
-
-Expires March 2010           Standards Track                    [Page 2]
-
-draft-ietf-dnsext-rfc3597-bis-00.txt                           July 2009
-
+   The RDATA section of RRs of unknown type must be treated as
+   unstructured binary data, and must be stored and transmitted without
+   change ([RFC1123], section 6.1.3.5).
 
    To ensure the correct operation of equality comparison (section 6)
    and of the DNSSEC canonical form (section 7) when an RR type is known
@@ -142,7 +148,7 @@ draft-ietf-dnsext-rfc3597-bis-00.txt                           July 2009
 
    Receiving servers MUST decompress domain names in RRs of well-known
    type, and SHOULD also decompress RRs of type RP, AFSDB, RT, SIG, PX,
-   NXT, NAPTR, and SRV to ensure interoperability with implementations
+   NXT, SRV, and NAPTR to ensure interoperability with implementations
    predating [RFC3597].
 
    Specifications for new RR types that contain domain names within
@@ -158,76 +164,39 @@ draft-ietf-dnsext-rfc3597-bis-00.txt                           July 2009
    In the "type" field of a master file line, an unknown RR type is
    represented by the word "TYPE" immediately followed by the decimal RR
    type number, with no intervening whitespace.  In the "class" field,
+
+
+
+Expires August 2010          Standards Track                    [Page 3]
+
+draft-ietf-dnsext-rfc3597-bis-02.txt                       February 2010
+
+
    an unknown class is similarly represented as the word "CLASS"
    immediately followed by the decimal class number.
 
    This convention allows types and classes to be distinguished from
    each other and from TTL values, allowing the "[<TTL>] [<class>]
    <type> <RDATA>" and "[<class>] [<TTL>] <type> <RDATA>" forms of
-
-
-
-Expires March 2010           Standards Track                    [Page 3]
-
-draft-ietf-dnsext-rfc3597-bis-00.txt                           July 2009
-
-
-   [RFC1035] to both be unambiguously parsed.
+   [RFC1035] section 5.1 to both be unambiguously parsed.
 
    The RDATA section of an RR of unknown type is represented as a
-   sequence of white space separated words as follows:
+   sequence of items separated by any combination of tabs and spaces, as
+   follows:
 
-      The special token \# (a backslash immediately followed by a hash
-      sign), which identifies the RDATA as having the generic encoding
-      defined herein rather than a traditional type-specific encoding.
+     - The special token \# (a backslash immediately followed by a hash
+       sign), which identifies the RDATA as having the generic encoding
+       defined herein rather than a traditional type-specific encoding.
 
-      An unsigned decimal integer specifying the RDATA length in octets.
+     - An unsigned decimal integer specifying the RDATA length in
+       octets.
 
-      Zero or more words of hexadecimal data encoding the actual RDATA
-      field, each containing an even number of hexadecimal digits.
+     - Zero or more items of hexadecimal data encoding the actual RDATA
+       field, each item containing an even number of hexadecimal digits.
 
    If the RDATA is of zero length, the text representation contains only
    the \# token and the single zero representing the length.
 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires March 2010           Standards Track                    [Page 4]
-
-draft-ietf-dnsext-rfc3597-bis-00.txt                           July 2009
-
-
    An implementation MAY also choose to represent some RRs of known type
    using the above generic representations for the type, class and/or
    RDATA, which carries the benefit of making the resulting master file
@@ -251,6 +220,14 @@ draft-ietf-dnsext-rfc3597-bis-00.txt                           July 2009
 
       a.example.   CLASS32     TYPE731         \# 6 abcd (
                                                ef 01 23 45 )
+
+
+
+Expires August 2010          Standards Track                    [Page 4]
+
+draft-ietf-dnsext-rfc3597-bis-02.txt                       February 2010
+
+
       b.example.   HS          TYPE62347       \# 0
       e.example.   IN          A               \# 4 C0000201
       e.example.   CLASS1      TYPE1           192.0.2.1
@@ -274,16 +251,6 @@ draft-ietf-dnsext-rfc3597-bis-00.txt                           July 2009
    records differing only in character case, and not expected to cause
    any problems in practice.
 
-
-
-
-
-
-Expires March 2010           Standards Track                    [Page 5]
-
-draft-ietf-dnsext-rfc3597-bis-00.txt                           July 2009
-
-
 7.  DNSSEC Considerations
 
    The rules for the DNSSEC canonical form and ordering were updated to
@@ -309,6 +276,14 @@ draft-ietf-dnsext-rfc3597-bis-00.txt                           July 2009
    This specification is not believed to cause any new security
    problems, nor to solve any existing ones.
 
+
+
+
+Expires August 2010          Standards Track                    [Page 5]
+
+draft-ietf-dnsext-rfc3597-bis-02.txt                       February 2010
+
+
 11.  Normative References
 
    [RFC1034]   Mockapetris, P., "Domain Names - Concepts and
@@ -332,14 +307,6 @@ draft-ietf-dnsext-rfc3597-bis-00.txt                           July 2009
                Means for Expressing Location Information in the Domain
                Name System", RFC 1876, January 1996.
 
-
-
-
-Expires March 2010           Standards Track                    [Page 6]
-
-draft-ietf-dnsext-rfc3597-bis-00.txt                           July 2009
-
-
    [RFC2136]   Vixie, P., Ed., Thomson, S., Rekhter, Y. and J. Bound,
                "Dynamic Updates in the Domain Name System (DNS UPDATE)",
                RFC 2136, April 1997.
@@ -362,34 +329,123 @@ draft-ietf-dnsext-rfc3597-bis-00.txt                           July 2009
    Phone: +358 40 547 2099
    EMail: [email protected]
 
+Appendix A. Summary of Changes Since RFC3597
+
+   This section summarizes the major changes between RFC3597 and this
 
 
 
+Expires August 2010          Standards Track                    [Page 6]
+
+draft-ietf-dnsext-rfc3597-bis-02.txt                       February 2010
 
 
+   document.  In addition to the changes listed below, there has also
+   been a number of editorial changes, such as updates to the text in
+   the Abstract and Introduction to better reflect the current state of
+   implementation, updates to boilerplate text, and minor
+   clarifications.
 
+   The reference to the DNS IANA Considerations BCP (BCP42) has been
+   changed from RFC2929 to the current version, RFC5395.
 
+   Downward references have been eliminated; specifically, the document
+   no longer refers to RFC2163 or RFC2535.
 
+   IP addresses in examples have been changed to use the 192.0.2.0/24
+   range per RFC3330.
 
+   The document no longer specifies changes to the DNSSEC canonical form
+   and ordering, as those changes have now been incorporated into the
+   base DNSSEC specification.
 
+Appendix B. Detailed Change Log
 
+   [NOTE TO RFC EDITOR:  PLEASE REMOVE THIS APPENDIX ON PUBLICATION.]
 
+B.1.  Changes between RFC3597 and -00
 
+   The reference to the DNS IANA Considerations BCP (BCP42) has been
+   changed from RFC2929 to the current version, RFC5395.
 
+   Downward references have been eliminated; specifically, the document
+   no longer refers to RFC2163 or RFC2535.
 
+   IP addresses in examples have been changed to use the 192.0.2.0/24
+   range per RFC3330.
 
+   The document no longer specifies changes to the DNSSEC canonical form
+   and ordering, as those changes have now been incorporated into the
+   base DNSSEC specification.
 
+   There has also been a number of editorial changes, such as updates to
+   the text in the Abstract and Introduction to better reflect the
+   current state of implementation.
 
+B.2.  Changes between -00 and -01
 
+   Moved the Abstract to immediately following the document title.
 
+   Updated boilerplate to the current version.
 
 
 
 
+Expires August 2010          Standards Track                    [Page 7]
+
+draft-ietf-dnsext-rfc3597-bis-02.txt                       February 2010
 
 
+   In the Introduction, the text "Another development that has
+   simplified the introduction of new DNS RR types is the adoption of a
+   simpler IANA allocation procedure for RR types" and a reference to
+   [RFC5395] were added.
 
+   In the Introduction, the text "with the aim of allowing the
+   specification to advance on the Standards Track" was added to explain
+   the motivation for the draft.
 
+   In section 2, the text "is class specific" was replaced by "is known
+   to be class specific".
 
-Expires March 2010           Standards Track                    [Page 7]
+   In section 3, the words "That is" were removed so as not to imply
+   that the transparent treatment of RRs of unknown type is only a
+   matter of how the RDATA field is handled.  The remainder of the
+   sentence was rephrased.
+
+   In section 4, the entries for SRV and NAPTR in the list of RR types
+   to decompress were swapped to make the list consistently ordered by
+   ascending numerical RR type.
+
+   References to RFC 1035 and RFC 1123 now include the specific section
+   numbers being referenced.
+
+   A Change History was added as Appendix A.
+
+B.3. Changes between -01 and -02
+
+   In section 5, the term "white space" was replaced by "any combination
+   of tabs and spaces", and the term "word" was replaced by "item", for
+   consistency with RFC1035 terminology.
+
+   In section 5, hyphens were added to mark the beginning of each item
+   in the the list of items comprising the RDATA text representation.
+
+   The Change History was split into a Summary of Changes Since RFC3597
+   (Appendix A) intended to remain in the document when published as an
+   RFC, and a Detailed Change Log (Appendix B) to be deleted on
+   publication.
+
+
+
+
+
+
+
+
+
+
+
+
+Expires August 2010          Standards Track                    [Page 8]
 

contrib/bind9/doc/draft/draft-ietf-dnsop-default-local-zones-10.txt

@@ -3,12 +3,12 @@
 
 Network Working Group                                         M. Andrews
 Internet-Draft                                                       ISC
-Intended status: BCP                                   November 19, 2009
-Expires: May 23, 2010
+Intended status: BCP                                      March 25, 2010
+Expires: September 26, 2010
 
 
                         Locally-served DNS Zones
-                draft-ietf-dnsop-default-local-zones-09
+                draft-ietf-dnsop-default-local-zones-10
 
 Abstract
 
@@ -41,20 +41,20 @@ Status of this Memo
    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html.
 
-   This Internet-Draft will expire on May 23, 2010.
+   This Internet-Draft will expire on September 26, 2010.
 
 Copyright Notice
 
-   Copyright (c) 2009 IETF Trust and the persons identified as the
+   Copyright (c) 2010 IETF Trust and the persons identified as the
    document authors.  All rights reserved.
 
    This document is subject to BCP 78 and the IETF Trust's Legal
 
 
 
-Andrews                   Expires May 23, 2010                  [Page 1]
+Andrews                Expires September 26, 2010               [Page 1]
 
-Internet-Draft          Locally-served DNS Zones           November 2009
+Internet-Draft          Locally-served DNS Zones              March 2010
 
 
    Provisions Relating to IETF Documents
@@ -108,9 +108,9 @@ Internet-Draft          Locally-served DNS Zones           November 2009
 
 
 
-Andrews                   Expires May 23, 2010                  [Page 2]
+Andrews                Expires September 26, 2010               [Page 2]
 
-Internet-Draft          Locally-served DNS Zones           November 2009
+Internet-Draft          Locally-served DNS Zones              March 2010
 
 
 Table of Contents
@@ -121,9 +121,9 @@ Table of Contents
    3.  Changes to Iterative Resolver Behaviour. . . . . . . . . . . .  4
    4.  Lists Of Zones Covered . . . . . . . . . . . . . . . . . . . .  5
      4.1.  RFC1918 Zones  . . . . . . . . . . . . . . . . . . . . . .  5
-     4.2.  RFC3330 Zones  . . . . . . . . . . . . . . . . . . . . . .  6
+     4.2.  RFC3330 and RFC5737 Zones  . . . . . . . . . . . . . . . .  6
      4.3.  Local IPv6 Unicast Addresses . . . . . . . . . . . . . . .  6
-     4.4.  IPv6 Locally Assigned Local Addresses  . . . . . . . . . .  6
+     4.4.  IPv6 Locally Assigned Local Addresses  . . . . . . . . . .  7
      4.5.  IPv6 Link Local Addresses  . . . . . . . . . . . . . . . .  7
      4.6.  IPv6 Example Prefix  . . . . . . . . . . . . . . . . . . .  7
    5.  Zones that are Out-Of-Scope  . . . . . . . . . . . . . . . . .  7
@@ -134,18 +134,19 @@ Table of Contents
      9.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
      9.2.  Informative References . . . . . . . . . . . . . . . . . . 10
    Appendix A.  Change History [To Be Removed on Publication] . . . . 10
-     A.1.  draft-ietf-dnsop-default-local-zones-09.txt  . . . . . . . 10
-     A.2.  draft-ietf-dnsop-default-local-zones-08.txt  . . . . . . . 10
-     A.3.  draft-ietf-dnsop-default-local-zones-07.txt  . . . . . . . 10
-     A.4.  draft-ietf-dnsop-default-local-zones-06.txt  . . . . . . . 10
-     A.5.  draft-ietf-dnsop-default-local-zones-05.txt  . . . . . . . 11
-     A.6.  draft-ietf-dnsop-default-local-zones-04.txt  . . . . . . . 11
-     A.7.  draft-ietf-dnsop-default-local-zones-03.txt  . . . . . . . 11
-     A.8.  draft-ietf-dnsop-default-local-zones-02.txt  . . . . . . . 11
-     A.9.  draft-ietf-dnsop-default-local-zones-01.txt  . . . . . . . 11
-     A.10. draft-ietf-dnsop-default-local-zones-00.txt  . . . . . . . 11
-     A.11. draft-andrews-full-service-resolvers-03.txt  . . . . . . . 11
-     A.12. draft-andrews-full-service-resolvers-02.txt  . . . . . . . 12
+     A.1.  draft-ietf-dnsop-default-local-zones-10.txt  . . . . . . . 10
+     A.2.  draft-ietf-dnsop-default-local-zones-09.txt  . . . . . . . 10
+     A.3.  draft-ietf-dnsop-default-local-zones-08.txt  . . . . . . . 11
+     A.4.  draft-ietf-dnsop-default-local-zones-07.txt  . . . . . . . 11
+     A.5.  draft-ietf-dnsop-default-local-zones-06.txt  . . . . . . . 11
+     A.6.  draft-ietf-dnsop-default-local-zones-05.txt  . . . . . . . 11
+     A.7.  draft-ietf-dnsop-default-local-zones-04.txt  . . . . . . . 11
+     A.8.  draft-ietf-dnsop-default-local-zones-03.txt  . . . . . . . 11
+     A.9.  draft-ietf-dnsop-default-local-zones-02.txt  . . . . . . . 11
+     A.10. draft-ietf-dnsop-default-local-zones-01.txt  . . . . . . . 11
+     A.11. draft-ietf-dnsop-default-local-zones-00.txt  . . . . . . . 11
+     A.12. draft-andrews-full-service-resolvers-03.txt  . . . . . . . 12
+     A.13. draft-andrews-full-service-resolvers-02.txt  . . . . . . . 12
    Appendix B.  Proposed Status [To Be Removed on Publication]  . . . 12
    Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
 
@@ -163,10 +164,9 @@ Table of Contents
 
 
 
-
-Andrews                   Expires May 23, 2010                  [Page 3]
+Andrews                Expires September 26, 2010               [Page 3]
 
-Internet-Draft          Locally-served DNS Zones           November 2009
+Internet-Draft          Locally-served DNS Zones              March 2010
 
 
 1.  Introduction
@@ -220,9 +220,9 @@ Internet-Draft          Locally-served DNS Zones           November 2009
 
 
 
-Andrews                   Expires May 23, 2010                  [Page 4]
+Andrews                Expires September 26, 2010               [Page 4]
 
-Internet-Draft          Locally-served DNS Zones           November 2009
+Internet-Draft          Locally-served DNS Zones              March 2010
 
 
 2.  Effects on sites using RFC 1918 addresses.
@@ -276,9 +276,9 @@ Internet-Draft          Locally-served DNS Zones           November 2009
 
 
 
-Andrews                   Expires May 23, 2010                  [Page 5]
+Andrews                Expires September 26, 2010               [Page 5]
 
-Internet-Draft          Locally-served DNS Zones           November 2009
+Internet-Draft          Locally-served DNS Zones              March 2010
 
 
    The SOA RR is needed to support negative caching [RFC2308] of name
@@ -332,16 +332,17 @@ Internet-Draft          Locally-served DNS Zones           November 2009
 
 
 
-Andrews                   Expires May 23, 2010                  [Page 6]
+Andrews                Expires September 26, 2010               [Page 6]
 
-Internet-Draft          Locally-served DNS Zones           November 2009
+Internet-Draft          Locally-served DNS Zones              March 2010
 
 
-4.2.  RFC3330 Zones
+4.2.  RFC3330 and RFC5737 Zones
 
    The following zones correspond to those address ranges from [RFC3330]
-   that are not expected to appear as source or destination addresses on
-   the public Internet and to not have a unique name to associate with.
+   and [RFC5737] that are not expected to appear as source or
+   destination addresses on the public Internet and to not have a unique
+   name to associate with.
 
    The recommendation to serve an empty zone 127.IN-ADDR.ARPA is not a
    attempt to discourage any practice to provide a PTR RR for
@@ -357,7 +358,9 @@ Internet-Draft          Locally-served DNS Zones           November 2009
          | 0.IN-ADDR.ARPA               | IPv4 "THIS" NETWORK    |
          | 127.IN-ADDR.ARPA             | IPv4 LOOP-BACK NETWORK |
          | 254.169.IN-ADDR.ARPA         | IPv4 LINK LOCAL        |
-         | 2.0.192.IN-ADDR.ARPA         | IPv4 TEST NET          |
+         | 2.0.192.IN-ADDR.ARPA         | IPv4 TEST NET 1        |
+         | 100.51.198.IN-ADDR.ARPA      | IPv4 TEST NET 2        |
+         | 113.0.203.IN-ADDR.ARPA       | IPv4 TEST NET 3        |
          | 255.255.255.255.IN-ADDR.ARPA | IPv4 BROADCAST         |
          +------------------------------+------------------------+
 
@@ -380,19 +383,20 @@ Internet-Draft          Locally-served DNS Zones           November 2009
    readability and to adhere to line width constraints.  They are not
    parts of the zone names.
 
+
+
+
+
+
+Andrews                Expires September 26, 2010               [Page 7]
+
+Internet-Draft          Locally-served DNS Zones              March 2010
+
+
 4.4.  IPv6 Locally Assigned Local Addresses
 
    Section 4.4 of [RFC4193] already required special treatment of:
 
-
-
-
-
-Andrews                   Expires May 23, 2010                  [Page 7]
-
-Internet-Draft          Locally-served DNS Zones           November 2009
-
-
                              +--------------+
                              | Zone         |
                              +--------------+
@@ -438,17 +442,16 @@ Internet-Draft          Locally-served DNS Zones           November 2009
    F.E.F.IP6.ARPA may still need to be deployed in the short term if the
    traffic becomes excessive.
 
+
+
+Andrews                Expires September 26, 2010               [Page 8]
+
+Internet-Draft          Locally-served DNS Zones              March 2010
+
+
    For IPv6 Non-Locally Assigned Local addresses (L = 0) [RFC4193],
    there has been no decision made about whether the Regional Internet
    Registries (RIRs) will provide delegations in this space or not.  If
-
-
-
-Andrews                   Expires May 23, 2010                  [Page 8]
-
-Internet-Draft          Locally-served DNS Zones           November 2009
-
-
    they don't, then C.F.IP6.ARPA will need to be added to the list in
    Section 4.4.  If they do, then registries will need to take steps to
    ensure that name servers are provided for these addresses.
@@ -494,17 +497,17 @@ Internet-Draft          Locally-served DNS Zones           November 2009
    DNSSEC validation to succeed for queries in these spaces despite not
    being answered from the delegated servers.
 
+
+
+
+Andrews                Expires September 26, 2010               [Page 9]
+
+Internet-Draft          Locally-served DNS Zones              March 2010
+
+
    It is recommended that sites actively using these namespaces secure
    them using DNSSEC [RFC4035] by publishing and using DNSSEC trust
    anchors.  This will protect the clients from accidental import of
-
-
-
-Andrews                   Expires May 23, 2010                  [Page 9]
-
-Internet-Draft          Locally-served DNS Zones           November 2009
-
-
    unsigned responses from the Internet.
 
 
@@ -551,16 +554,16 @@ Internet-Draft          Locally-served DNS Zones           November 2009
    [RFC4159]  Huston, G., "Deprecation of "ip6.int"", BCP 109, RFC 4159,
               August 2005.
 
+
+
+Andrews                Expires September 26, 2010              [Page 10]
+
+Internet-Draft          Locally-served DNS Zones              March 2010
+
+
    [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
               Addresses", RFC 4193, October 2005.
 
-
-
-Andrews                   Expires May 23, 2010                 [Page 10]
-
-Internet-Draft          Locally-served DNS Zones           November 2009
-
-
    [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
               Architecture", RFC 4291, February 2006.
 
@@ -588,45 +591,54 @@ Internet-Draft          Locally-served DNS Zones           November 2009
    [RFC3849]  Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix
               Reserved for Documentation", RFC 3849, July 2004.
 
+   [RFC5737]  Arkko, J., Cotton, M., and L. Vergoda, "IPv4 Address
+              Blocks Reserved for Documentation", RFC 5737,
+              January 2010.
+
 
 Appendix A.  Change History [To Be Removed on Publication]
 
-A.1.  draft-ietf-dnsop-default-local-zones-09.txt
+A.1.  draft-ietf-dnsop-default-local-zones-10.txt
+
+   added RFC 5737 zones
+
+A.2.  draft-ietf-dnsop-default-local-zones-09.txt
 
    refresh awaiting writeup
 
-A.2.  draft-ietf-dnsop-default-local-zones-08.txt
+
+
+
+
+
+
+Andrews                Expires September 26, 2010              [Page 11]
+
+Internet-Draft          Locally-served DNS Zones              March 2010
+
+
+A.3.  draft-ietf-dnsop-default-local-zones-08.txt
 
    editorial, reference updates
 
-A.3.  draft-ietf-dnsop-default-local-zones-07.txt
+A.4.  draft-ietf-dnsop-default-local-zones-07.txt
 
    none, expiry prevention
 
-A.4.  draft-ietf-dnsop-default-local-zones-06.txt
+A.5.  draft-ietf-dnsop-default-local-zones-06.txt
 
    add IPv6 example prefix
 
-
-
-
-
-
-Andrews                   Expires May 23, 2010                 [Page 11]
-
-Internet-Draft          Locally-served DNS Zones           November 2009
-
-
-A.5.  draft-ietf-dnsop-default-local-zones-05.txt
+A.6.  draft-ietf-dnsop-default-local-zones-05.txt
 
    none, expiry prevention
 
-A.6.  draft-ietf-dnsop-default-local-zones-04.txt
+A.7.  draft-ietf-dnsop-default-local-zones-04.txt
 
    Centrally Assigned Local addresses -> Non-Locally Assigned Local
    address
 
-A.7.  draft-ietf-dnsop-default-local-zones-03.txt
+A.8.  draft-ietf-dnsop-default-local-zones-03.txt
 
    expanded section 4 descriptions
 
@@ -636,44 +648,40 @@ A.7.  draft-ietf-dnsop-default-local-zones-03.txt
 
    Revised language.
 
-A.8.  draft-ietf-dnsop-default-local-zones-02.txt
+A.9.  draft-ietf-dnsop-default-local-zones-02.txt
 
    RNAME now "nobody.invalid."
 
    Revised language.
 
-A.9.  draft-ietf-dnsop-default-local-zones-01.txt
+A.10.  draft-ietf-dnsop-default-local-zones-01.txt
 
    Revised impact description.
 
    Updated to reflect change in IP6.INT status.
 
-A.10.  draft-ietf-dnsop-default-local-zones-00.txt
+A.11.  draft-ietf-dnsop-default-local-zones-00.txt
 
    Adopted by DNSOP.
 
    "Author's Note" re-titled "Zones that are Out-Of-Scope"
 
+
+
+Andrews                Expires September 26, 2010              [Page 12]
+
+Internet-Draft          Locally-served DNS Zones              March 2010
+
+
    Add note that these zone are expected to seed the IANA registry.
 
    Title changed.
 
-A.11.  draft-andrews-full-service-resolvers-03.txt
+A.12.  draft-andrews-full-service-resolvers-03.txt
 
    Added "Proposed Status".
 
-
-
-
-
-
-
-Andrews                   Expires May 23, 2010                 [Page 12]
-
-Internet-Draft          Locally-served DNS Zones           November 2009
-
-
-A.12.  draft-andrews-full-service-resolvers-02.txt
+A.13.  draft-andrews-full-service-resolvers-02.txt
 
    Added 0.IN-ADDR.ARPA.
 
@@ -692,7 +700,7 @@ Author's Address
    Redwood City, CA  94063
    US
 
-   Email: Mark_Andrews@isc.org
+   Email: marka@isc.org
 
 
 
@@ -716,14 +724,5 @@ Author's Address
 
 
 
-
-
-
-
-
-
-
-
-Andrews                   Expires May 23, 2010                 [Page 13]
+Andrews                Expires September 26, 2010              [Page 13]
 
-

contrib/bind9/doc/draft/draft-ietf-dnsop-dnssec-trust-history-01.txt

@@ -0,0 +1,504 @@
+
+
+
+Domain Name System Operations                              W. Wijngaards
+Internet-Draft                                                O. Kolkman
+Intended status: Standards Track                              NLnet Labs
+Expires: August 26, 2010                               February 22, 2010
+
+
+                  DNSSEC Trust Anchor History Service
+                draft-ietf-dnsop-dnssec-trust-history-01
+
+Abstract
+
+   When DNS validators have trusted keys, but have been offline for a
+   longer period, key rollover will fail and they are stuck with stale
+   trust anchors.  History service allows validators to query for older
+   DNSKEY RRsets and pick up the rollover trail where they left off.
+
+Requirements Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+Status of This Memo
+
+   This Internet-Draft is submitted to IETF in full conformance with the
+   provisions of BCP 78 and BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on August 26, 2010.
+
+Copyright Notice
+
+   Copyright (c) 2010 IETF Trust and the persons identified as the
+
+
+
+Wijngaards & Kolkman     Expires August 26, 2010                [Page 1]
+
+Internet-Draft            Trust History Service            February 2010
+
+
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the BSD License.
+
+1.  Introduction
+
+   This memo defines a trust history service for DNS validators -- the
+   component in a resolver that performs DNSSEC [RFC4034] validation,
+   validator for short.
+
+   A validator that has been offline or missed an (emergency) rollover
+   can use this service to reconfigure themselves with the current
+   trust-anchor.  Using a newly defined resource record (RR) that links
+   old DNSKEYS together, the TALINK RR, a validator fetches old DNSKEY
+   RRsets and checks they form a chain to the latest key (see
+   Section 2).  The lists of old DNSKEYS, linked with the TALINK RRs, do
+   not necessarily need to be published in the zone for which the DNSKEY
+   history is being maintained but can be published in any DNS domain.
+   We will call the entity that offers the trust history the History
+   Provider.  The choice of the History Provider is made by the
+   maintainer of the validator, possibly based on a hint provided, using
+   the TALINK, by the zone owner.
+
+   The algorithm that the validator uses to construct a history and
+   reconfigure a new key is detailed in Section 3.  The algorithms for
+   how providers of trust history can fetch the DNSKEY data as published
+   by the zone they track and publish that are explained in Section 4.
+
+2.  The  TALINK Resource Record
+
+   The DNS Resource Record type TALINK (decimal 58) ties the elements of
+   a linked list of DNSKEY RRs together.
+
+   The rdata consists of two domain names.  The first name is the start,
+   or previous name, and the other name the end or next name in the
+   list.  The empty label '.' is used at the endpoints of the list.
+
+   The presentation format is the two domain names.  The wire encoding
+   is the two domain names, with no compression so the type can be
+   treated according to [RFC3597].  The list is a double linked list,
+
+
+
+Wijngaards & Kolkman     Expires August 26, 2010                [Page 2]
+
+Internet-Draft            Trust History Service            February 2010
+
+
+   because this empowers low memory hosts to perform consistency checks.
+
+3.  Trust History Lookup
+
+   This is the algorithm that a validator uses to detect and resolve the
+   situation in which a trust-anchor is out of sync with the DNSKEYs
+   published by a zone owner.  The algorithm uses the TALINK RR type
+   which is used to link various old DNSKEYs as published by the History
+   Provider, to arrive from the outdated configured Trust Anchor to one
+   that matches the current DNSKEY.  The TALINK RR type is defined in
+   Section 2.
+
+   When the algorithm below results in failure the trust history cannot
+   be build and a new trust anchor will need to be re-configured using
+   another mechanism.
+
+   Step 1:  The validator performs a DNSKEY lookup to the target zone,
+      which looks like any other initial DNSKEY lookup that the
+      validator needs to match a trust anchor to the currently used
+      DNSKEY RR set.  If the keyset verifies with the trust anchor
+      currently held, the trust-anchor is not out of sync.  Otherwise,
+      store the DNSKEY RR set as result.  The algorithm will
+      successfully build a linked list to this DNSKEY RR, or delete the
+      trust point, or fail.
+
+      All nameservers (the ones authoritative for the zone or the
+      upstream resolver caches when the validator is not full resolver)
+      SHOULD be checked to make sure the DNSKEY RR sets are the same.
+      The results can differ if a key-rollover is in progress and not
+      all nameservers are in sync yet.  This case can be detected by
+      checking that the older keyset signs the newer and take the newer
+      as result keyset.  The keysets are distinguished by the average
+      over the middle of the inception and expiration dates of the
+      signatures that are validated by the keyset itself.  Otherwise,
+      the history lookup fails.  If the check fails then the
+      inconsistency may be the result of spoofing, or compromise of
+      (DNS) infrastructure elements.
+
+   Step 2:  Fetch the trust history list end points.  Perform a query of
+      QTYPE TALINK and QNAME the domain name that is configured to be
+      the History Provider for the particular domain you are trying to
+      update the trust-anchor for.
+
+   Step 3:  Go backwards through the trust history list as provided by
+      the TALINK linked list.  Verify that the keyset validly signs the
+      next keyset.  This is [RFC4034] validation, but the RRSIG
+      expiration date is ignored.  [Editor note: Are we shure that there
+      are no server implementations that will not serve expired RRSIG,
+
+
+
+Wijngaards & Kolkman     Expires August 26, 2010                [Page 3]
+
+Internet-Draft            Trust History Service            February 2010
+
+
+      are such 'smart' servers allowed by the specs?  In other words do
+      we need clarification in the DNSSEC-updates document?]  Replace
+      the owner domain name with the target zone name for verification.
+      One of the keys that signs the next keyset MUST have the SEP bit
+      set.  The middle of inception and expiration date from the valid
+      signature MUST be older than that of the signature that validates
+      the next keys in the list.  Query type TALINK to get previous and
+      next locations.
+
+      If all SEP keys have the REVOKE flag set at this step, and the
+      keyset is signed by all SEP keys, then continue but store that the
+      end result is that the trust point is deleted, see Section 5
+      [RFC5011].
+
+      If all SEP keys are of an unknown algorithm at this step, continue
+      and at the next step, when you verify if the keyset signs validly:
+      if false, continue with result a failure, if true, continue with
+      the end result that the trust point is deleted.  Thus, the keysets
+      with unknown algorithms are stepped over with an end result of
+      failure because the validator cannot determine if unknown
+      algorithm signatures are valid, until the oldest keyset with
+      unknown algorithms is signed by a known algorithm and the result
+      is set to deletion and step 3 continues to a known key.
+
+   Step 4:  When the trust anchor currently held by the validator
+      verifies the keyset, the algorithm is done.  The validator SHOULD
+      store the result on stable storage.  Use the new trust anchor for
+      validation (if using [RFC5011], put it in state VALID).
+
+4.  Trust History Tracker
+
+   External trackers can poll the target zone DNSKEY RRset regularly.
+   Ignore date changes in the RRSIG.  Ignore changes to keys with no SEP
+   flag.  Copy the newly polled DNSKEY RRset and RRSIGs, change the
+   owner name to a new name at the history location.  Publish the new
+   RRset and TALINK records to make it the last element in the list.
+   Update the TALINK that advertises the first and last name.
+
+   Integrated into the rollover, the keys are stored in the history and
+   the TALINK is updated when a new key is used in the rollover process.
+   This gives the TALINK and new historical key time to propagate.
+
+   The signer can support trust history.  Trust history key sets need
+   only contain SEP keys.  To use older signers, move historical RRSIGs
+   to another file.  Sign the zone, including the TALINK and DNSKEY
+   records.  Append the historical RRSIGs to the result.  Signing the
+   zone like this obviates the need for changes to signer and server
+   software.
+
+
+
+Wijngaards & Kolkman     Expires August 26, 2010                [Page 4]
+
+Internet-Draft            Trust History Service            February 2010
+
+
+5.  Example
+
+   In this example example.com is the History Provider for example.net.
+   The DNSKEY rdata and RRSIG rdata is omitted for brevity, it is a copy
+   and paste of the data from example.net.
+
+   $ORIGIN example.com.
+   example.com. TALINK h0.example.com. h2.example.com.
+
+   h0 TALINK . h1.example.com.
+   h0 DNSKEY ...
+   h0 RRSIG ...
+
+   h1 TALINK h0.example.com. h2.example.com.
+   h1 DNSKEY ...
+   h1 RRSIG ...
+
+   h2 TALINK h1.example.com. .
+   h2 DNSKEY ...
+   h2 RRSIG ...
+
+   The example.net zone can advertise the example.com History Provider
+   by providing the TALINK shown here at example.com at the apex of the
+   example.net zone.  The TALINK at example.com is then not needed.
+
+6.  Deployment
+
+   The trust history is advertised with TALINK RRs at the zone apex.
+   These represent alternative history sources, that can be searched in
+   turn.  The TALINK at the zone apex contains the first and last name
+   of the list of historical keys.
+
+   The historical list of keys grows perpetually.  Since most validators
+   have recent keys, their processing time remains similar as the list
+   grows.  If validators no longer have trust in the keys then they need
+   no longer be published.  The oldest key entries can be omitted from
+   the list to shorten it.
+
+   The validator decides how long it trusts a key.  A recommendation
+   from the zone owner can be configured for keys of that zone, or
+   recommendations per algorithm and key size can be used (e.g. see
+   [NIST800-57]).  If a key is older than that, trust history lookup
+   fails with it and the trust point can be considered deleted.  This
+   assumes the validator has decided on a security policy and also can
+   take actions when the update of the trust anchor fails.  Without such
+   policy, or if the alternative is no DNSSEC, the approach below can be
+   used.
+
+
+
+
+Wijngaards & Kolkman     Expires August 26, 2010                [Page 5]
+
+Internet-Draft            Trust History Service            February 2010
+
+
+   In general, the decision can be that any key - no matter how old or
+   how small - is better than no security.  The validator then never
+   considers a key too old, and the lookup algorithm becomes an
+   unsecured update mechanism at the time where the key can be trivially
+   broken.  The history provider SHOULD provide these broken keys to
+   facilitate clients performing the unsecured update.  If a key can not
+   be trivially broken then it provides a non-trivial amount of security
+   that the history lookup algorithm uses to get the current keys.
+   Conceivably after the update the result is stored on stable storage
+   and the client is thereafter safe - it performs a leap of faith.  The
+   validator operator can opt for this set up after considering the
+   trade-off between loss of DNSSEC, loss of connectivity, and the
+   argument that perceived security is worse than no security.
+
+   The history lookup can be used on its own.  Then, the trust history
+   is used whenever the key rolls over and no polling is performed.
+   This has associated risks, in that the immediate rollover without
+   timeout that it provides could be abused, and certainly when taken
+   together with leap-of-faith such systems SHOULD inform their user
+   that the key has changed and urge them to do immediate checks.
+   Initially we put a hold down timer on such rollovers to mitigate the
+   abuse risks but these make following normal rollovers impossible.
+
+   If a validator is also using [RFC5011] for the target zone, then the
+   trust history algorithm SHOULD only be invoked if the [RFC5011]
+   algorithm failed due to the inability to perform probes.  This is the
+   case when the last [RFC5011] successful probe was more than 30 days
+   ago.  If a new key has been announced, invoke the history if no 2
+   probes succeeded during the add hold-down time and there was no
+   successful probe after the add hold-down time passed.  Therefore the
+   time of the last successful probe MUST be stored on stable storage.
+
+   For testing the potentially very infrequently used lookup, the
+   following SHOULD be implemented.  For the test the lookup is
+   triggered manually by allowing the system to be given a particular
+   keyset with a last successful lookup date in the past and a test
+   History Provider.  The test History Provider provides access to a
+   generated back-dated test history.
+
+7.  Security Considerations
+
+   The History Provider only provides copies of old data.  If that
+   historic data is altered or withheld the lookup algorithm fails
+   because of validation errors in Step 3 of the algorithm.  If the
+   History provider or a Man in the Middle Adversary (MIMA) has access
+   to the original private keys (through theft, cryptanalisis, or
+   otherwise), history can be altered without failure of the algorithm.
+   Below we only consider MIMAs and assume the History Provider is a
+
+
+
+Wijngaards & Kolkman     Expires August 26, 2010                [Page 6]
+
+Internet-Draft            Trust History Service            February 2010
+
+
+   trusted party.
+
+   Spoofing by a MIMA of data looked up in step 2 or 3, i.e. spoofing of
+   TALINK and DNSKEY data, can present some alternate history.  However
+   the DNSKEY RR set trusted that the history should arrive at is
+   already fixed by step 1.  If an attempt is made to subvert the
+   algorithm at step 2 or 3, then the result keyset can not be replaced
+   by another keyset unnoticed.
+
+   To change the keyset trusted as the outcome, the step 1 data has to
+   be spoofed and the key held by the validator (or a newer historic
+   key) has to be compromised.  Unless such spoof is targeted to a
+   specific victim, a spoof of the step 1 result has a high visibility.
+   Since most of the validators that receive the spoof have an up-to-
+   date trust anchor most validators that would receive this spoof
+   return validation failure for data from the zone that contains the
+   DNSKEYs.  An adversary will therefore have to target the attack to
+   validators that are in the process of an update.  Since validators do
+   not announce that they use trust history lookup until step 2
+   adversaries will not be able to select the validators.
+
+   A spoof of data in steps 2 and 3, together with a compromised (old)
+   key, can result in a downgrade.  At steps 2 and 3 a faked trust point
+   deletion or algorithm rollover can be inserted in a fake history.
+   This avoids the high visibility of spoofing the current key (see
+   previous paragraph) and downgrades to insecure.
+
+   Finally there is the case that one of the keys published by the
+   History Providers has been compromised.  Since someone spoofing at
+   step 1 of the lookup algorithm and presenting some fake history to a
+   compromised key, of course does not include key revocations and does
+   extend the history to contain the compromised key, it therefore is
+   not really useful for a History Provider to remove the key from the
+   published history.  That only makes lookups fail for those validators
+   who are not under attack.  Useful action could be to update
+   validators using some other means.
+
+   Rollover with [RFC5011] revokes keys after use.  If a History
+   Provider is used, then such revoked keys SHOULD be used to perform
+   history tracking and history lookup.  The old keys that the validator
+   starts with and final current keys MUST NOT be trusted if they are
+   revoked.
+
+   Depending on choices by the validator operator, it may accept a leap-
+   of-faith, and possibly allow non-hold-down rollovers.  Although this
+   allows very fast emergency rollover if all clients are known to do
+   trust-history lookups without the RFC5011-algorithm, it also allows
+   an attacker with the private key to attempt to take over a zone
+
+
+
+Wijngaards & Kolkman     Expires August 26, 2010                [Page 7]
+
+Internet-Draft            Trust History Service            February 2010
+
+
+   quickly and get validators to roll to a trust anchor of the
+   attacker's choosing.
+
+   The SEP bit is checked to make sure that control over the KSK is
+   necessary to change the keyset for the target zone.
+
+   The algorithm can be used to get the inception and expiration times
+   of signatures on the current keyset, a clock.  A MIMA can attempt to
+   shorten history and put back that clock, but the algorithm attempts
+   to make this difficult to target and highly visible to others.
+
+   If the clock of the validator can be influenced, then setting it
+   forward is unlikely to give advantage, but setting it backward
+   enables a replay attack of old DNSSEC data and signatures.  This
+   vulnerability exists also in plain DNSSEC.
+
+8.  IANA Considerations
+
+   Resource record type TALINK has been defined using RFC5395 expert
+   review, it has RR type number 58 (decimal).
+
+9.  Acknowledgments
+
+   Thanks to the people who provided review and suggestions, Joe Abley,
+   George Barwood, Edward Lewis, Michael StJohns, Bert Hubert, Mark
+   Andrews, Ted Lemon, Steve Crocker, Bill Manning, Eric Osterweil,
+   Wolfgang Nagele, Alfred Hoenes, Olafur Gudmundsson, Roy Arends and
+   Matthijs Mekking.
+
+10.  References
+
+10.1.  Informative References
+
+   [NIST800-57]  Barker, E., Barker, W., Burr, W., Polk, W., and M.
+                 Smid, "Recommendations for Key Management", NIST
+                 SP 800-57, March 2007.
+
+   [RFC5011]     StJohns, M., "Automated Updates of DNS Security
+                 (DNSSEC) Trust Anchors", RFC 5011, September 2007.
+
+10.2.  Normative References
+
+   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
+                 Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3597]     Gustafsson, A., "Handling of Unknown DNS Resource
+                 Record (RR) Types", RFC 3597, September 2003.
+
+
+
+
+Wijngaards & Kolkman     Expires August 26, 2010                [Page 8]
+
+Internet-Draft            Trust History Service            February 2010
+
+
+   [RFC4034]     Arends, R., Austein, R., Larson, M., Massey, D., and S.
+                 Rose, "Resource Records for the DNS Security
+                 Extensions", RFC 4034, March 2005.
+
+Authors' Addresses
+
+   Wouter Wijngaards
+   NLnet Labs
+   Science Park 140
+   Amsterdam  1098 XG
+   The Netherlands
+
+   EMail: [email protected]
+
+
+   Olaf Kolkman
+   NLnet Labs
+   Science Park 140
+   Amsterdam  1098 XG
+   The Netherlands
+
+   EMail: [email protected]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wijngaards & Kolkman     Expires August 26, 2010                [Page 9]
+

contrib/bind9/doc/draft/draft-kerr-ixfr-only-01.txt

@@ -0,0 +1,336 @@
+
+
+
+DNSext Working Group                                             O. Sury
+Internet-Draft                                                    CZ.NIC
+Updates: 1995 (if approved)                                 S. Kerr, Ed.
+Intended status: Standards Track                                     ISC
+Expires: August 30, 2010                               February 26, 2010
+
+
+               IXFR-ONLY to Prevent IXFR Fallback to AXFR
+                        draft-kerr-ixfr-only-01
+
+Abstract
+
+   This documents proposes a new QTYPE (Query pseudo RRtype) for the
+   Domain Name System (DNS).  IXFR-ONLY is a variant of IXFR (RFC 1995)
+   that allows an authoritative server to incrementally update zone
+   content from another (primary) server without falling back from IXFR
+   to AXFR.  This way, alternate peers can be contacted more quickly and
+   convergence of zone content may be achieved much faster in important,
+   resilient operational scenarios.
+
+Status of this Memo
+
+   This Internet-Draft is submitted to IETF in full conformance with the
+   provisions of BCP 78 and BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on August 30, 2010.
+
+Copyright Notice
+
+   Copyright (c) 2010 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+
+
+
+Sury & Kerr              Expires August 30, 2010                [Page 1]
+
+Internet-Draft                  IXFR-ONLY                  February 2010
+
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the BSD License.
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
+     1.1.  Requirements Language . . . . . . . . . . . . . . . . . . . 3
+   2.  IXFR Server Side  . . . . . . . . . . . . . . . . . . . . . . . 4
+   3.  IXFR Client Side  . . . . . . . . . . . . . . . . . . . . . . . 4
+   4.  Applicability of IXFR-ONLY  . . . . . . . . . . . . . . . . . . 5
+   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
+   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
+   7.  Normative References  . . . . . . . . . . . . . . . . . . . . . 5
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 6
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sury & Kerr              Expires August 30, 2010                [Page 2]
+
+Internet-Draft                  IXFR-ONLY                  February 2010
+
+
+1.  Introduction
+
+   For large DNS zones, RFC 1995 [RFC1995] defines Incremental Zone
+   Transfer (IXFR), which allows only to transfer the changed portion(s)
+   of a zone.
+
+   In the document, an IXFR client and an IXFR server is defined as in
+   RFC 1995 [RFC1995], a secondary name server which requests IXFR is
+   called an IXFR client and a primary or secondary name server which
+   responds to the request is called an IXFR server.
+
+   IXFR is an efficient way to transfer changes in zones from IXFR
+   servers to IXFR clients.  However, when an IXFR client has multiple
+   IXFR servers for a single zone, it is possible that not all IXFR
+   servers have the zone with same serial number for that zone.  In this
+   case, if an IXFR client attempts an IXFR from an IXFR server which
+   does not have zone with the serial number used by the IXFR client,
+   the IXFR server will fall back to a full zone transfer (AXFR) when it
+   has a version of the zone with serial number greater than the serial
+   requested by the IXFR client.
+
+   For example, IXFR server NS1 may have serial numbers 1, 2, and 3 for
+   a zone, and IXFR server NS2 may have serial numbers 1 and 3 for the
+   same zone.  An IXFR client that has the zone with serial number 2
+   which sends an IXFR request to IXFR server NS2 will get a full zone
+   transfer (AXFR) of the zone at serial number 3.  This is because NS2
+   does not know the zone with serial number 2, and therefore does not
+   know what the differences are between zone with serial number 2 and
+   3.
+
+   If the IXFR client in this example had known to send the query to
+   IXFR server NS1, then it could have gotten an incremental transfer
+   (IXFR).  But IXFR clients can only know what the latest version of
+   the zone is at a IXFR server (this information is available via an
+   SOA query).
+
+   The IXFR-ONLY query type provides a way for the IXFR client to ask
+   each IXFR server to return an error instead of sending the current
+   version of the zone via full zone transfer (AXFR).  By using this, a
+   IXFR client can check each IXFR server until it finds one able to
+   provide IXFR.
+
+1.1.  Requirements Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+
+
+
+Sury & Kerr              Expires August 30, 2010                [Page 3]
+
+Internet-Draft                  IXFR-ONLY                  February 2010
+
+
+2.  IXFR Server Side
+
+   A IXFR server receiving a DNS message requesting IXFR-ONLY will reply
+   as described in RFC 1995 [RFC1995] if it is able to produce an IXFR
+   for the serial number requested.
+
+   If the IXFR server is is not able to reply with an IXFR it MUST NOT
+   reply with an AXFR unless AXFR result is smaller than IXFR result.
+   Instead, it MUST reply with RCODE CannotIXFR. (!FIXME)
+
+   If the IXFR result is larger than an AXFR, then an IXFR server MAY
+   reply with an AXFR result instead.  This is an optimization, and IXFR
+   servers MAY only reply with AXFR if they are certain that the reply
+   using AXFR is smaller than an equivalent IXFR reply.
+
+
+3.  IXFR Client Side
+
+   An IXFR client who wishes to use IXFR-ONLY will send a message to one
+   of the IXFR servers.  The format is exactly the same as for IXFR,
+   except the IXFR-ONLY QTYPE code is used instead of the IXFR QTYPE
+   code.
+
+   If the IXFR server replies with IXFR, then the IXFR client is done.
+
+   If the IXFR server replies with an RCODE of CannotIXFR, then the IXFR
+   client proceeds on to a different IXFR server.  In this case the IXFR
+   server implements IXFR-ONLY, but does not have information about zone
+   with the serial number requested.
+
+   If the IXFR server replies with any RCODE other than CannotIXFR or
+   NoError, then the IXFR client proceeds on to a different IXFR server.
+   In this case the IXFR server does not implement IXFR-ONLY.
+
+   If the IXFR client attempts IXFR-ONLY to each IXFR server and none of
+   them reply with an incremental transfer (IXFR), then it should
+   attempt an IXFR as described in RFC 1995 [RFC1995] to each of the
+   IXFR servers which replied with an RCODE other than CannotIXFR or
+   NoError.
+
+   The method described above allows IXFR clients to operate normally in
+   situatians where some of the IXFR servers do support IXFR-ONLY, and
+   some who do not.  IXFR clients MAY remember which IXFR servers
+   support IXFR-ONLY and query those IXFR servers first.  However since
+   IXFR servers may change software or even run a mix of software, IXFR
+   clients MUST attempt to query each IXFR server periodically when they
+   attempt to get new versions of a zone.
+
+
+
+
+Sury & Kerr              Expires August 30, 2010                [Page 4]
+
+Internet-Draft                  IXFR-ONLY                  February 2010
+
+
+   Implementations MAY allow IXFR clients to disable IXFR-ONLY for a
+   given IXFR server, if this is known in advance.  These IXFR servers
+   are treated as if they replied with an RCODE other than CannotIXFR or
+   NoError, although no query with IXFR-ONLY is actually sent.
+
+
+4.  Applicability of IXFR-ONLY
+
+   Implementations SHOULD allow IXFR clients to disable IXFR-ONLY
+   completely.
+
+   Implementations MAY allow IXFR clients to disable IXFR-ONLY for a
+   specific zone.  This may be useful for small zones, where fallback to
+   AXFR is cheap, or in other cases where IXFR-ONLY is causing problems.
+
+   Usage of IXFR-ONLY may cause IXFR clients to prefer particular IXFR
+   servers, by shifting load to ones that support IXFR-ONLY.  If this a
+   problem, then administrators can disable IXFR-ONLY in implementations
+   that allow it.
+
+   If a IXFR client has a single IXFR server for a zone, it SHOULD use
+   IXFR rather than IXFR-ONLY.
+
+
+5.  IANA Considerations
+
+   IANA allocates the new IXFR-ONLY QTYPE, which means "incremental
+   transfer only".  IANA allocates the CannotIXFR RCODE, which means
+   "Server cannot provide IXFR for zone".
+
+
+6.  Security Considerations
+
+   IXFR-ONLY may be used by someone to get information about the state
+   of IXFR servers by providing a quick and efficient way to check which
+   versions of a zone each IXFR server supports.  Zones should be
+   secured via TSIG [RFC2845] to prevent unauthorized information
+   exposure.  However, even administrators of IXFR servers may not want
+   this information given to IXFR clients, in which case they will need
+   to disable IXFR-ONLY.
+
+
+7.  Normative References
+
+   [RFC1995]  Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
+              August 1996.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+
+
+
+Sury & Kerr              Expires August 30, 2010                [Page 5]
+
+Internet-Draft                  IXFR-ONLY                  February 2010
+
+
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake, D., and B.
+              Wellington, "Secret Key Transaction Authentication for DNS
+              (TSIG)", RFC 2845, May 2000.
+
+
+Authors' Addresses
+
+   Ondrej Sury
+   CZ.NIC
+   Americka 23
+   120 00 Praha 2
+   CZ
+
+   Phone: +420 222 745 110
+   Email: [email protected]
+
+
+   Shane Kerr (editor)
+   ISC
+   Bennebrokestraat 17-I
+   1015 PE Amsterdam
+   NL
+
+   Phone: +31 64 6336297
+   Email: [email protected]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sury & Kerr              Expires August 30, 2010                [Page 6]
+

contrib/bind9/doc/draft/draft-mekking-dnsop-auto-cpsync-00.txt

@@ -0,0 +1,336 @@
+
+
+
+Domain Name System Operations                                 W. Mekking
+Internet-Draft                                                NLnet Labs
+Intended status: Standards Track                           June 29, 2010
+Expires: December 31, 2010
+
+
+    Automated (DNSSEC) Child Parent Synchronization using DNS UPDATE
+                   draft-mekking-dnsop-auto-cpsync-00
+
+Abstract
+
+   This document proposes a way to synchronise existing trust anchors
+   automatically between a child zone and its parent.  The algorithm can
+   be used for other Resource Records that are required to delegate from
+   a parent to a child such as NS and glue records.
+
+Requirements Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+Status of This Memo
+
+   This Internet-Draft is submitted in full conformance with the
+   provisions of BCP 78 and BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF).  Note that other groups may also distribute
+   working documents as Internet-Drafts.  The list of current Internet-
+   Drafts is at http://datatracker.ietf.org/drafts/current/.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   This Internet-Draft will expire on December 31, 2010.
+
+Copyright Notice
+
+   Copyright (c) 2010 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+
+
+
+Mekking                 Expires December 31, 2010               [Page 1]
+
+Internet-Draft        Child Parent Synchronization             June 2010
+
+
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+1.  Introduction
+
+   This memo defines a way to synchronise existing trust anchors
+   automatically between a child zone and its parent.  The algorithm can
+   be used for other Resource Records that are required to delegate from
+   a parent to a child such as NS and glue records.
+
+   To create a DNSSEC RFC 4035 [RFC4035] chain of trust, child zones
+   must submit their DNSKEYs, or hashes of their DNSKEYs, to their
+   parent zone.  The parent zone publishes the hashes of the DNSKEYs in
+   the form of a DS record.  The DNSKEY RRset at the child may change
+   over time.  In order to keep the chain of trust intact, the DS
+   records at the parent zone also needs to be updated.  The rolling of
+   the keys with the SEP bit on is one of the few tasks in DNSSEC that
+   yet has to be fully automated.
+
+   The DNS UPDATE mechanism RFC 2136 [RFC2136] can be used to push zone
+   changes to the parent.
+
+   To bootstrap the direct communication channel, information must be
+   exchanged in order to detect service location and granting update
+   privileges.  A new or existing child zone can request a direct
+   communication channel with the parent.  If the parent allows for
+   direct communication with child zones, the parent can share the
+   required data to set up the channel to the child zone.  Once the
+   child has the required credentials, it can use the direct
+   communication channel with the parent to request zone changes related
+   to its delegation.
+
+   If a third party is involved, the third party can act on behalf of
+   the parent.  In this case, the third party will give out the required
+   credentials to set up the communication channel.
+
+   It is RECOMMENDED that the direct communication channel is secured
+   with TSIG [RFC2845] or SIG0 [RFC2931].
+
+2.  Access and Update Control
+
+   The DNS UPDATE normally is used for granting update permissions to a
+   machine that is within the boundary of the same organization.  This
+   document proposes to grant child zones the same permissions.
+   However, it MUST NOT be possible that a child zone updates
+
+
+
+Mekking                 Expires December 31, 2010               [Page 2]
+
+Internet-Draft        Child Parent Synchronization             June 2010
+
+
+   information in the parent zone that falls outside the administrative
+   domain of the corresponding delegation.  For example, it MUST NOT be
+   possible for a child zone to update the data that the parent is
+   authoritative for, or update a delegation that is pointed to a
+   different child zone.  It MUST only be able to update records that
+   match one of the following:
+
+   Or:   The owner name is equal the child zone name and RRtype is
+      delegation specific.  Currently those are records with RRtype NS
+      or DS.
+
+   Or:   The owner name is a subdomain of the child zone name and RRtype
+      is glue specific.  Currently those are records with RRtype A or
+      AAAA.
+
+   This list may be expanded in the future, if there is need for more
+   delegation related zone content.
+
+   In case of adding or deleting delegation specific records, the DNSSEC
+   related RRs in the parent zone might need to be updated.
+
+   The service location may be handed out by the registrar during
+   bootstrap If this information is missing, the normal guidelines for
+   sending DNS UPDATE messages SHOULD be followed.
+
+3.  Update Mechanism
+
+3.1.  Child Duties
+
+   Updating the NS RRset or corresponding glue at the parent, an update
+   can be sent at any time.  Updating the DS RRset is part of key
+   rollover, as described in RFC 4641 [RFC4641].  When performing a key
+   rollover that involves updating the RRset at the parent, the child
+   introduces a new DNSKEY in its zone that represents the security
+   entry point for determining the chain of trust.  After a while, it
+   will revoke and/or remove the previous security entry point.  The
+   timings when to update the DS RRset at the parent are described in
+   draft-dnsop-morris-dnssec-key-timing [keytiming].  When updating the
+   DS RRset at the parent automatically, these timing specifications
+   SHOULD be followed.  To determine the propagation delays described in
+   this document, the child should poll the parent zone for a short
+   time, until the DS is visible at all parent name servers.
+
+   To discuss: A child zone might be unable to reach all parent name
+   servers.
+
+   The child notifies the parent of the requested changes by sending a
+   DNS UPDATE message.  If it receives a NOERROR reply in return, the
+
+
+
+Mekking                 Expires December 31, 2010               [Page 3]
+
+Internet-Draft        Child Parent Synchronization             June 2010
+
+
+   update is acknowledged by the parent zone.  Otherwise, the child MAY
+   retry transmitting the update.  In order to prevent duplicate
+   updates, it SHOULD follow the guidelines described in RFC 2136
+   [RFC2136].
+
+3.2.  Parent Duties
+
+   When the master DNS server of the parent receives a DNS UPDATE from
+   one of its children the following must be done:
+
+   Step 1:  Check the TSIG/SIG0 credentials.  In case of TSIG, the
+      parent should follow the TSIG processing described in section 3.2
+      of RFC 2845.  In case of SIG0, the parent should follow the SIG0
+      processing described in section 3.2 of RFC 2931.
+
+   Step 2:  Verify that the updates matches the update policy for child
+      zones.
+
+   Step 3:  If verified, send back DNS UPDATE OK.  Otherwise, send back
+      DNS UPDATE REFUSED.
+
+   Step 4:  If verified, apply changes.  How that is done is a matter of
+      policy.
+
+3.3.  Proxy considerations
+
+   Some environments don't allow for direct communication between parent
+   and child zone.  In these case, the parent duties can be performed by
+   a different party (for example, the registar).  The third party will
+   forward the update to the parent zone.  In what format depends on
+   local policy.
+
+4.  Example BIND9 Configuration
+
+   This is how a parent zone can configure a policy to enable a child
+   zone synchronize delegation specific records.  The first rule of the
+   update policy grants children to update their DS and NS records in
+   the parent zone, in this case example.com.  The second rule of the
+   update policy grants children to update the corresponding glue
+   records.
+
+   key cs.example.com. {
+   algorithm HMAC-MD5;
+   secret "secretforcs";
+   }
+
+   key math.example.com. {
+   algorithm HMAC-MD5;
+
+
+
+Mekking                 Expires December 31, 2010               [Page 4]
+
+Internet-Draft        Child Parent Synchronization             June 2010
+
+
+   secret "secretformath";
+   }
+
+   ...
+
+   zone "example.com" {
+   type master;
+   file "example.com";
+   update-policy { grant *.example.com. self *.example.com.  DS NS; };
+   update-policy { grant *.example.com. selfsub *.example.com.  A AAAA;
+   };
+   };
+
+5.  Security Considerations
+
+   Automating the synchronization of (DNSSEC) records between the parent
+   and child created a new channel.  We have recommended that this
+   channel should be secured with TSIG or SIG0.  There is an advantage
+   and a disadvantage of the new security channel.  The disadvantage is
+   that you create a new attack window for your DNSSEC credentials.  If
+   the automated synchronization is used for updating DS records at the
+   parent, you SHOULD pick a cryptographically an equally strong or
+   stronger TSIG/SIG0 key than the strength of your DNSSEC keys.
+
+   The advantage is that if somehow your DNSSEC keys are compromised,
+   you can still use this channel to perform an emergency key rollover.
+
+6.  IANA Considerations
+
+   None.
+
+7.  Acknowledgments
+
+   Rickard Bellgrim, Wolfgang Nagele, Wouter Wijngaards and more.
+
+8.  References
+
+8.1.  Informative References
+
+   [RFC2136]    Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
+                "Dynamic Updates in the Domain Name System (DNS
+                UPDATE)", RFC 2136, April 1997.
+
+   [RFC4641]    Kolkman, O. and R. Gieben, "DNSSEC Operational
+                Practices", RFC 4641, September 2006.
+
+   [keytiming]  Morris, S., Ihren, J., and J. Dickinson, "DNSSEC Key
+                Timing Considerations", March 2010.
+
+
+
+Mekking                 Expires December 31, 2010               [Page 5]
+
+Internet-Draft        Child Parent Synchronization             June 2010
+
+
+8.2.  Normative References
+
+   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
+                Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2845]    Vixie, P., Gudmundsson, O., Eastlake, D., and B.
+                Wellington, "Secret Key Transaction Authentication for
+                DNS (TSIG)", RFC 2845, May 2000.
+
+   [RFC2931]    Eastlake, D., "DNS Request and Transaction Signatures (
+                SIG(0)s)", RFC 2931, September 2000.
+
+   [RFC4035]    Arends, R., Austein, R., Larson, M., Massey, D., and S.
+                Rose, "Protocol Modifications for the DNS Security
+                Extensions", RFC 4035, March 2005.
+
+Author's Address
+
+   Matthijs Mekking
+   NLnet Labs
+   Science Park 140
+   Amsterdam  1098 XG
+   The Netherlands
+
+   EMail: [email protected]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mekking                 Expires December 31, 2010               [Page 6]
+

contrib/bind9/doc/draft/draft-yao-dnsext-bname-04.txt

@@ -0,0 +1,729 @@
+
+
+Network Working Group                                             J. Yao
+Internet-Draft                                                    X. Lee
+Intended status: Standards Track                                   CNNIC
+Expires: February 12, 2011                                      P. Vixie
+                                            Internet Software Consortium
+                                                         August 11, 2010
+
+
+                      Bundle DNS Name Redirection
+                     draft-yao-dnsext-bname-04.txt
+
+Abstract
+
+   This document defines a new DNS Resource Record called "BNAME", which
+   provides the capability to map itself and its subtree of the DNS name
+   space to another domain.  It differs from the CNAME record which only
+   maps a single node of the DNS name space, from the DNAME which only
+   maps the subtree of the DNS name space to another domain.
+
+Status of this Memo
+
+   This Internet-Draft is submitted in full conformance with the
+   provisions of BCP 78 and BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF).  Note that other groups may also distribute
+   working documents as Internet-Drafts.  The list of current Internet-
+   Drafts is at http://datatracker.ietf.org/drafts/current/.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   This Internet-Draft will expire on February 12, 2011.
+
+Copyright Notice
+
+   Copyright (c) 2010 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+
+
+
+Yao, et al.             Expires February 12, 2011               [Page 1]
+
+Internet-Draft                    bname                      August 2010
+
+
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+   This document may contain material from IETF Documents or IETF
+   Contributions published or made publicly available before November
+   10, 2008.  The person(s) controlling the copyright in some of this
+   material may not have granted the IETF Trust the right to allow
+   modifications of such material outside the IETF Standards Process.
+   Without obtaining an adequate license from the person(s) controlling
+   the copyright in such materials, this document may not be modified
+   outside the IETF Standards Process, and derivative works of it may
+   not be created outside the IETF Standards Process, except to format
+   it for publication as an RFC or to translate it into languages other
+   than English.
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   3.  The BNAME Resource Record  . . . . . . . . . . . . . . . . . .  4
+     3.1.  Format . . . . . . . . . . . . . . . . . . . . . . . . . .  4
+     3.2.  The BNAME Substitution . . . . . . . . . . . . . . . . . .  4
+     3.3.  The BNAME Rules  . . . . . . . . . . . . . . . . . . . . .  4
+   4.  Query Processing . . . . . . . . . . . . . . . . . . . . . . .  4
+     4.1.  Processing by Servers  . . . . . . . . . . . . . . . . . .  5
+     4.2.  Processing by Resolvers  . . . . . . . . . . . . . . . . .  8
+   5.  BNAME in DNSSEC  . . . . . . . . . . . . . . . . . . . . . . .  9
+     5.1.  BNAME validating . . . . . . . . . . . . . . . . . . . . .  9
+     5.2.  BNAME alias algorithm identifiers  . . . . . . . . . . . . 10
+   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
+   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
+   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
+   9.  Change History . . . . . . . . . . . . . . . . . . . . . . . . 11
+     9.1.  draft-yao-dnsext-bname: Version 00 . . . . . . . . . . . . 11
+     9.2.  draft-yao-dnsext-bname: Version 01 . . . . . . . . . . . . 11
+     9.3.  draft-yao-dnsext-bname: Version 02 . . . . . . . . . . . . 11
+     9.4.  draft-yao-dnsext-bname: Version 03 . . . . . . . . . . . . 11
+   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
+     10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
+     10.2. Informative References . . . . . . . . . . . . . . . . . . 13
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
+
+
+
+
+
+
+
+
+Yao, et al.             Expires February 12, 2011               [Page 2]
+
+Internet-Draft                    bname                      August 2010
+
+
+1.  Introduction
+
+   More and more internationalized domain name labels [RFC3490] appear
+   in the DNS trees.  Some labels [RFC3743] are equivalent in some
+   languages.  The internet users want them to be identical in the DNS
+   resolution.  For example, color.exmaple.com==colour.example.com.  The
+   BNAME represents for bundle names.  This document defines a new DNS
+   Resource Record called "BNAME", which provides the capability to map
+   an entire tree of the DNS name space to another domain.  It means
+   that the BNAME redirects both itself and its descendants to its
+   owner.  The DNAME [RFC2672] and [RFC2672bis] do not redirect itself,
+   only the descendants.  The domain name that owns a DNAME record is
+   allowed to have other resource record types at that domain name.  The
+   domain name that owns a BNAME record is not allowed to have other
+   resource record types at that domain name unless they are the DNSSEC
+   related resource record types defined in [RFC4033], [RFC4034],
+   [RFC4035] and [RFC5155].  A server MAY refuse to load a zone that has
+   data at a sub-domain of a domain name owning a BNAME RR or that has
+   other data except the DNSSEC related resource record types and BNAME
+   at that name.  BNAME is a singleton type, meaning only one BNAME is
+   allowed per name except the DNSSEC related resource record types.
+   Resolvers, servers and zone content administrators should be cautious
+   that usage of BNAME or its combination with CNAME or DNAME may lead
+   to form loops.  The loops should be avoided.
+
+1.1.  Terminology
+
+   All the basic terms used in this specification are defined in the
+   documents [RFC1034], [RFC1035] and [RFC2672].
+
+
+2.  Motivation
+
+   In some languages, some characters have the variants, which look
+   differently or very similar but are identical in the meaning.  For
+   example, Chinese character U+56FD and its variant U+570B look
+   differently, but are identical in the meaning.  If Internationalized
+   Domain Label" or "IDL" [RFC3743] are composed of variant characters,
+   we regard this kind of IDL as the IDL variant.  If these IDL variants
+   are put into the DNS for resolution, they are expected to be
+   identical in the DNS resolution.  More comprehensible example is that
+   we expect color.exmaple.com to be equivalent with the
+   colour.exmaple.com in the DNS resolution.  The BNAME Resource Record
+   and its processing rules are conceived as a solution to this
+   equivalence problem.  Without the BNAME mechanism, current mechanisms
+   such as DNAME or CNAME are not enough capable to solve all the
+   problems with the emergence of internationalized domain names.  The
+   internationalized domain names may have alias or equivalence of the
+
+
+
+Yao, et al.             Expires February 12, 2011               [Page 3]
+
+Internet-Draft                    bname                      August 2010
+
+
+   original one.  The BNAME solution provides the solution to both ASCII
+   alias names and internationalized domain alias names.
+
+
+3.  The BNAME Resource Record
+
+3.1.  Format
+
+   The BNAME RR has mnemonic BNAME and type code xx (decimal).  It is
+   not class-sensitive.  Its RDATA is comprised of a single field,
+   <target>, which contains a fully qualified domain name that must be
+   sent in uncompressed form [RFC1035], [RFC3597].  The <target> field
+   MUST be present.  The presentation format of <target> is that of a
+   domain name [RFC1035].  The wildcards in the BNAME RR SHOULD NOT be
+   used.
+
+     <owner> <ttl> <class> BNAME <target>
+
+   The effect of the BNAME RR is the substitution of the record's
+   <target> for its owner name, as a suffix of a domain name.  This
+   substitution has to be applied for every BNAME RR found in the
+   resolution process, which allows fairly lengthy valid chains of BNAME
+   RRs.
+
+3.2.  The BNAME Substitution
+
+   A BNAME substitution is performed by replacing the suffix labels of
+   the name being sought matching the owner name of the BNAME resource
+   record with the string of labels in the RDATA field.  The matching
+   labels end with the root label in all cases.  Only whole labels are
+   replaced.
+
+3.3.  The BNAME Rules
+
+   There are two rules which governs the use of BNAMEs in a zone file.
+   The first one is that there SHOULD be no descendants under the owner
+   of the BNAME.  The second one is that no resource records can co-
+   exist with the BNAME for the same name except the DNSSEC related
+   resource record types.  It means that if a BNAME RR is present at a
+   node N, there MUST be no other data except the DNSSEC related
+   resource record types at N and no data at any descendant of N. This
+   restriction applies only to records of the same class as the BNAME
+   record.
+
+
+4.  Query Processing
+
+   To exploit the BNAME mechanism the name resolution algorithms
+
+
+
+Yao, et al.             Expires February 12, 2011               [Page 4]
+
+Internet-Draft                    bname                      August 2010
+
+
+   [RFC1034] must be modified slightly for both servers and resolvers.
+   Both modified algorithms incorporate the operation of making a
+   substitution on a name (either QNAME or SNAME) under control of a
+   BNAME record.  This operation will be referred to as "the BNAME
+   substitution".
+
+4.1.  Processing by Servers
+
+   For a server performing non-recursive service steps 3.a, 3.c and 4 of
+   section 4.3.2 [RFC1034] are changed to check for a BNAME record, and
+   to return certain BNAME records from zone data and the cache.
+
+   If the owner name of the bname is the suffix of the name queryed but
+   different, when preparing a response, a server performing a BNAME
+   substitution will in all cases include the relevant BNAME RR in the
+   answer section.  A CNAME RR is synthesized and included in the answer
+   section.  This will help the client to reach the correct DNS data.
+
+   If the owner name of the bname is same with the name queryed, when
+   preparing a response, a server performing a BNAME substitution will
+   not include the relevant BNAME RR in the answer section unless the
+   type queryed is BNAME.  A CNAME RR will be synthesized and included
+   in the answer section unless the type queryed is BNAME or the query
+   is the DNSSEC query.
+
+   The provided synthesized CNAME RR if there has one, MUST have
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yao, et al.             Expires February 12, 2011               [Page 5]
+
+Internet-Draft                    bname                      August 2010
+
+
+      The same CLASS as the QCLASS of the query,
+
+      TTL equal to the corresponding BNAME RR,
+
+      An <owner> equal to the QNAME in effect at the moment the BNAME RR
+      was encountered, and
+
+      An RDATA field containing the new QNAME formed by the action of
+      the BNAME substitution.
+
+
+   The revised server algorithm is:
+
+
+   1. Set or clear the value of recursion available in the response
+      depending on whether the name server is willing to provide
+      recursive service.  If recursive service is available and
+      requested via the RD bit in the query, go to step 5, otherwise
+      step 2.
+
+   2. Search the available zones for the zone which is the nearest
+      ancestor to QNAME.  If such a zone is found, go to step 3,
+      otherwise step 4.
+
+   3. Start matching down, label by label, in the zone.  The matching
+      process can terminate several ways:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yao, et al.             Expires February 12, 2011               [Page 6]
+
+Internet-Draft                    bname                      August 2010
+
+
+     a. If the whole of QNAME is matched, we have found the node.
+
+         If the data at the node is a CNAME, and QTYPE doesn't match
+         CNAME, copy the CNAME RR into the answer section of the
+         response, change QNAME to the canonical name in the CNAME RR,
+         and go back to step 1.
+
+         If the data at the node is a BNAME, and QTYPE doesn't
+         match BNAME, copy the BNAME RR and also a corresponding,
+         synthesized CNAME RR into the answer section of the
+         response, change QNAME to the name carried as RDATA in
+         the BNAME RR, and go back to step 1.
+
+         Otherwise, copy all RRs which match QTYPE into the answer
+         section and go to step 6.
+
+      b. If a match would take us out of the authoritative data, we have
+         a referral.  This happens when we encounter a node with NS RRs
+         marking cuts along the bottom of a zone.
+
+         Copy the NS RRs for the subzone into the authority section of
+         the reply.  Put whatever addresses are available into the
+         additional section, using glue RRs if the addresses are not
+         available from authoritative data or the cache.  Go to step 4.
+
+      c. If at some label, a match is impossible (i.e., the
+         corresponding label does not exist), look to see whether the
+         last label matched has a BNAME record.
+
+
+         If a BNAME record exists at that point, copy that record into
+         the answer section.  If substitution of its <target> for its
+         <owner> in QNAME would overflow the legal size for a <domain-
+         name>, set RCODE to YXDOMAIN [RFC2136] and exit; otherwise
+         perform the substitution and continue.  The server SHOULD
+         synthesize a corresponding CNAME record as described above and
+         include it in the answer section.  Go back to step 1.
+
+         If there was no BNAME record, look to see if the "*" label
+         exists.
+
+         If the "*" label does not exist, check whether the name we are
+         looking for is the original QNAME in the query or a name we
+         have followed due to a CNAME.  If the name is original, set an
+         authoritative name error in the response and exit.  Otherwise
+         just exit.
+
+
+
+
+
+Yao, et al.             Expires February 12, 2011               [Page 7]
+
+Internet-Draft                    bname                      August 2010
+
+
+
+         If the "*" label does exist, match RRs at that node against
+         QTYPE.  If any match, copy them into the answer section, but
+         set the owner of the RR to be QNAME, and not the node with the
+         "*" label.  Go to step 6.
+
+
+   4. Start matching down in the cache.  If QNAME is found in the cache,
+      copy all RRs attached to it that match QTYPE into the answer
+      section.  If QNAME is not found in the cache but a BNAME record is
+      present at QNAME, copy that BNAME record into the
+      answer section.  If there was no delegation from authoritative
+      data, look for the best one from the cache, and put it in the
+      authority section.  Go to step 6.
+
+   5. Use the local resolver or a copy of its algorithm (see resolver
+      section of this memo) to answer the query.  Store the results,
+      including any intermediate CNAMEs and BNAMEs, in the answer
+      section of the response.
+
+   6. Using local data only, attempt to add other RRs which may be
+      useful to the additional section of the query.  Exit.
+
+
+
+   Note that there will be at most one ancestor with a BNAME as
+   described in step 4 unless some zone's data is in violation of the
+   no-descendants limitation in section 3.  An implementation might take
+   advantage of this limitation by stopping the search of step 3c or
+   step 4 when a BNAME record is encountered.
+
+
+4.2.  Processing by Resolvers
+
+   A resolver or a server providing recursive service must be modified
+   to treat a BNAME as somewhat analogous to a CNAME.  The resolver
+   algorithm of [RFC1034] section 5.3.3 is modified to renumber step 4.d
+   as 4.e and insert a new 4.d.  The complete algorithm becomes:
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yao, et al.             Expires February 12, 2011               [Page 8]
+
+Internet-Draft                    bname                      August 2010
+
+
+   1. See if the answer is in local information, and if so return it to
+      the client.
+
+   2. Find the best servers to ask.
+
+   3. Send them queries until one returns a response.
+
+   4. Analyze the response, either:
+
+      a. if the response answers the question or contains a name error,
+         cache the data as well as returning it back to the client.
+
+      b. if the response contains a better delegation to other servers,
+         cache the delegation information, and go to step 2.
+
+      c. if the response shows a CNAME and that is not the answer
+         itself, cache the CNAME, change the SNAME to the canonical name
+         in the CNAME RR and go to step 1.
+
+      d. if the response shows a BNAME and that is not the answer
+         itself, cache the BNAME.  If substitution of the BNAME's
+         <target> for its <owner> in the SNAME would overflow the legal
+         size for a <domain-name>, return an implementation-dependent
+         error to the application; otherwise perform the substitution
+         and go to step 1.
+
+      e. if the response shows a server failure or other bizarre
+         contents, delete the server from the SLIST and go back to step
+         3.
+
+
+   A resolver or recursive server which understands BNAME records but
+   sends non-extended queries MUST augment step 4.c by deleting from the
+   reply any CNAME records which have an <owner> which is a subdomain of
+   the <owner> of any BNAME record in the response.
+
+
+5.  BNAME in DNSSEC
+
+5.1.  BNAME validating
+
+   With the deployment of DNSSEC, more and more servers and resolvers
+   will support DNSSEC.  In order to make BNAME valid in DNSSEC
+   verification, the DNSSEC enabled resolvers and servers MUST support
+   BNAME.  The synthesized CNAME in the answer section for the BNAME
+   will never be signed if there has one.
+
+   If the owner name of the bname is the suffix of the name queryed but
+
+
+
+Yao, et al.             Expires February 12, 2011               [Page 9]
+
+Internet-Draft                    bname                      August 2010
+
+
+   different, DNSSEC validators MUST understand BNAME, verify the BNAME
+   and then checking that the CNAME was properly synthesized in order to
+   verify the synthesized CNAME.
+
+   If the owner name of the bname is same with the name queryed, DNSSEC
+   validators MUST understand BNAME and verify the BNAME.  The BNAME
+   enabled resolver (validator) should do somewhat analogous to a CNAME
+   for further query.
+
+   In any negative response, the NSEC or NSEC3 [RFC5155] record type bit
+   map SHOULD be checked to see that there was no BNAME that could have
+   been applied.  If the BNAME bit in the type bit map is set and the
+   query type is not BNAME, then BNAME substitution should have been
+   done.
+
+5.2.  BNAME alias algorithm identifiers
+
+   In order to prevent BNAME-unaware resolvers from attempting to
+   validate responses from BNAME-signed zones, this specification
+   allocates two new DNSKEY algorithm identifiers.  Algorithm Y, DSA-
+   BNAME-SHA1 is an alias for algorithm 3, DSA.  Algorithm Z, RSASHA1-
+   BNAME-SHA1 is an alias for algorithm 5, RSASHA1.  These are not new
+   algorithms, they are additional identifiers for the existing
+   algorithms.  Zones signed according to this specification MUST only
+   use these algorithm identifiers for their DNSKEY RRs.  The BNAME-
+   unaware resolvers will not know these new identifiers and treat
+   responses from the BNAME signed zone as insecure, otherwise the bname
+   RR will be regarded as bogus if there is no such a mechanism.  These
+   algorithm identifiers are used with the BNAME hash algorithm SHA1.
+   Using other BNAME hash algorithms requires allocation of a new alias.
+   Validating resolvers which follow the BNAME specification MUST
+   recognize the new alias algorithm identifier.
+
+
+6.  IANA Considerations
+
+   IANA is requested to assign the number to XX.  This document updates
+   the IANA registry "DNS SECURITY ALGORITHM NUMBERS".  IANA is
+   requested to assign the number to Y and Z.
+
+   [[anchor14: Note in draft: before this document goes to WG Last call,
+   it is better that we list all DNSSEC algorithms that need to be
+   aliased to reflect compatibility with this extension.]]
+
+
+7.  Security Considerations
+
+   Both ASCII domain name labels and non-ASCII ones have some aliases.
+
+
+
+Yao, et al.             Expires February 12, 2011              [Page 10]
+
+Internet-Draft                    bname                      August 2010
+
+
+   We can bundle the domain name labels and their aliases through BNAME
+   in the DNS resolutions.  The name labels and their aliases in the
+   particular languages are only known by those who know these
+   languages.  Those labels may be regarded as different ones by those
+   who don't know those languages.  Those who do not know the aliases
+   should only use the familar ones.  The applications will not know the
+   aliases unless they are properly configured.
+
+
+8.  Acknowledgements
+
+   Because the BNAME is very similar to DNAME, the authors learn a lot
+   from [RFC2672].  Many ideas are from the discussion in the DNSOP and
+   DNSEXT mailling list.  Thanks a lot to all in the list.  Many
+   important comments and suggestions are contributed by many members of
+   the DNSEXT and DNSOP WGs.  The authors especially thanks the
+   following ones:Niall O'Reilly, Glen Zorn, Mark Andrews, George
+   Barwood,Olafur Gudmundsson, Sun Guonian and Hanfeng for improving
+   this document.
+
+
+9.  Change History
+
+   [[anchor17: RFC Editor: Please remove this section.]]
+
+9.1.  draft-yao-dnsext-bname: Version 00
+
+   o  Bundle DNS Name Redirection
+
+9.2.  draft-yao-dnsext-bname: Version 01
+
+   o  Improve the algorithm
+   o  Improve the text
+
+9.3.  draft-yao-dnsext-bname: Version 02
+
+   o  Add the DNSSEC discussion
+   o  Improve the text
+
+9.4.  draft-yao-dnsext-bname: Version 03
+
+   o  Update the DNSSEC discussion
+   o  Update the IANA consideration
+
+
+10.  References
+
+
+
+
+
+Yao, et al.             Expires February 12, 2011              [Page 11]
+
+Internet-Draft                    bname                      August 2010
+
+
+10.1.  Normative References
+
+   [ASCII]    American National Standards Institute (formerly United
+              States of America Standards Institute), "USA Code for
+              Information Interchange", ANSI X3.4-1968, 1968.
+
+   [EDNS0]    Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
+              RFC 2671, August 1999.
+
+   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
+              STD 13, RFC 1034, November 1987.
+
+   [RFC1035]  Mockapetris, P., "Domain names - implementation and
+              specification", STD 13, RFC 1035, November 1987.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2136]  Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
+              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
+              RFC 2136, April 1997.
+
+   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
+              RFC 2671, August 1999.
+
+   [RFC2672]  Crawford, M., "Non-Terminal DNS Name Redirection",
+              RFC 2672, August 1999.
+
+   [RFC3490]  Faltstrom, P., Hoffman, P., and A. Costello,
+              "Internationalizing Domain Names in Applications (IDNA)",
+              RFC 3490, March 2003.
+
+   [RFC3597]  Gustafsson, A., "Handling of Unknown DNS Resource Record
+              (RR) Types", RFC 3597, September 2003.
+
+   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
+              10646", RFC 3629, November 2003.
+
+   [RFC3743]  Konishi, K., Huang, K., Qian, H., and Y. Ko, "Joint
+              Engineering Team (JET) Guidelines for Internationalized
+              Domain Names (IDN) Registration and Administration for
+              Chinese, Japanese, and Korean", RFC 3743, April 2004.
+
+   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "DNS Security Introduction and Requirements",
+              RFC 4033, March 2005.
+
+   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+
+
+
+Yao, et al.             Expires February 12, 2011              [Page 12]
+
+Internet-Draft                    bname                      August 2010
+
+
+              Rose, "Resource Records for the DNS Security Extensions",
+              RFC 4034, March 2005.
+
+   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "Protocol Modifications for the DNS Security
+              Extensions", RFC 4035, March 2005.
+
+   [RFC5155]  Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
+              Security (DNSSEC) Hashed Authenticated Denial of
+              Existence", RFC 5155, March 2008.
+
+10.2.  Informative References
+
+   [RFC2672bis]
+              Rose, S. and W. Wijngaards, "Update to DNAME Redirection
+              in the DNS", Internet-Draft ietf-dnsext-rfc2672bis-dname-
+              17.txt, 6 2009.
+
+
+Authors' Addresses
+
+   Jiankang YAO
+   CNNIC
+   No.4 South 4th Street, Zhongguancun
+   Beijing
+
+   Phone: +86 10 58813007
+   Email: [email protected]
+
+
+   Xiaodong LEE
+   CNNIC
+   No.4 South 4th Street, Zhongguancun
+   Beijing
+
+   Phone: +86 10 58813020
+   Email: [email protected]
+
+
+   Paul Vixie
+   Internet Software Consortium
+   950 Charter Street
+   Redwood City, CA
+
+   Phone: +1 650 779 7001
+   Email: [email protected]
+
+
+
+
+
+Yao, et al.             Expires February 12, 2011              [Page 13]
+
+
+

contrib/bind9/doc/rfc/index

@@ -138,3 +138,6 @@
 5625:	DNS Proxy Implementation Guidelines
 5702:   Use of SHA-2 Algorithms with RSA in
          DNSKEY and RRSIG Resource Records for DNSSEC
+5933:	Use of GOST Signature Algorithms in DNSKEY
+         and RRSIG Resource Records for DNSSEC
+

contrib/bind9/doc/rfc/rfc5933.txt

@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                  V. Dolmatov, Ed.
+Request for Comments: 5933                                   A. Chuprina
+Category: Standards Track                                     I. Ustinov
+ISSN: 2070-1721                                           Cryptocom Ltd.
+                                                               July 2010
+
+
+               Use of GOST Signature Algorithms in DNSKEY
+                 and RRSIG Resource Records for DNSSEC
+
+Abstract
+
+   This document describes how to produce digital signatures and hash
+   functions using the GOST R 34.10-2001 and GOST R 34.11-94 algorithms
+   for DNSKEY, RRSIG, and DS resource records, for use in the Domain
+   Name System Security Extensions (DNSSEC).
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc5933.
+
+Copyright Notice
+
+   Copyright (c) 2010 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+
+Dolmatov, et al.             Standards Track                    [Page 1]
+
+RFC 5933            Use of GOST Signatures in DNSSEC           July 2010
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
+     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
+   2.  DNSKEY Resource Records . . . . . . . . . . . . . . . . . . . . 3
+     2.1.  Using a Public Key with Existing Cryptographic
+           Libraries . . . . . . . . . . . . . . . . . . . . . . . . . 3
+     2.2.  GOST DNSKEY RR Example  . . . . . . . . . . . . . . . . . . 4
+   3.  RRSIG Resource Records  . . . . . . . . . . . . . . . . . . . . 4
+     3.1.  RRSIG RR Example  . . . . . . . . . . . . . . . . . . . . . 5
+   4.  DS Resource Records . . . . . . . . . . . . . . . . . . . . . . 5
+     4.1.  DS RR Example . . . . . . . . . . . . . . . . . . . . . . . 5
+   5.  Deployment Considerations . . . . . . . . . . . . . . . . . . . 6
+     5.1.  Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . . 6
+     5.2.  Signature Sizes . . . . . . . . . . . . . . . . . . . . . . 6
+     5.3.  Digest Sizes  . . . . . . . . . . . . . . . . . . . . . . . 6
+   6.  Implementation Considerations . . . . . . . . . . . . . . . . . 6
+     6.1.  Support for GOST Signatures . . . . . . . . . . . . . . . . 6
+     6.2.  Support for NSEC3 Denial of Existence . . . . . . . . . . . 6
+   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
+   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
+   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
+   10. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
+     10.1. Normative References  . . . . . . . . . . . . . . . . . . . 7
+     10.2. Informative References  . . . . . . . . . . . . . . . . . . 8
+
+1.  Introduction
+
+   The Domain Name System (DNS) is the global hierarchical distributed
+   database for Internet Naming.  The DNS has been extended to use
+   cryptographic keys and digital signatures for the verification of the
+   authenticity and integrity of its data.  RFC 4033 [RFC4033], RFC 4034
+   [RFC4034], and RFC 4035 [RFC4035] describe these DNS Security
+   Extensions, called DNSSEC.
+
+   RFC 4034 describes how to store DNSKEY and RRSIG resource records,
+   and specifies a list of cryptographic algorithms to use.  This
+   document extends that list with the signature and hash algorithms
+   GOST R 34.10-2001 ([GOST3410], [RFC5832]) and GOST R 34.11-94
+   ([GOST3411], [RFC5831]), and specifies how to store DNSKEY data and
+   how to produce RRSIG resource records with these algorithms.
+
+   Familiarity with DNSSEC and with GOST signature and hash algorithms
+   is assumed in this document.
+
+   The term "GOST" is not officially defined, but is usually used to
+   refer to the collection of the Russian cryptographic algorithms
+   GOST R 34.10-2001 [RFC5832], GOST R 34.11-94 [RFC5831], and
+
+
+
+Dolmatov, et al.             Standards Track                    [Page 2]
+
+RFC 5933            Use of GOST Signatures in DNSSEC           July 2010
+
+
+   GOST 28147-89 [RFC5830].  Since GOST 28147-89 is not used in DNSSEC,
+   "GOST" will only refer to GOST R 34.10-2001 and GOST R 34.11-94 in
+   this document.
+
+1.1.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+2.  DNSKEY Resource Records
+
+   The format of the DNSKEY RR can be found in RFC 4034 [RFC4034].
+
+   GOST R 34.10-2001 public keys are stored with the algorithm
+   number 12.
+
+   The wire format of the public key is compatible with RFC 4491
+   [RFC4491]:
+
+   According to [GOST3410] and [RFC5832], a public key is a point on the
+   elliptic curve Q = (x,y).
+
+   The wire representation of a public key MUST contain 64 octets, where
+   the first 32 octets contain the little-endian representation of x and
+   the second 32 octets contain the little-endian representation of y.
+
+   Corresponding public key parameters are those identified by
+   id-GostR3410-2001-CryptoPro-A-ParamSet (1.2.643.2.2.35.1) [RFC4357],
+   and the digest parameters are those identified by
+   id-GostR3411-94-CryptoProParamSet (1.2.643.2.2.30.1) [RFC4357].
+
+2.1.  Using a Public Key with Existing Cryptographic Libraries
+
+   At the time of this writing, existing GOST-aware cryptographic
+   libraries are capable of reading GOST public keys via a generic X509
+   API if the key is encoded according to RFC 4491 [RFC4491],
+   Section 2.3.2.
+
+   To make this encoding from the wire format of a GOST public key with
+   the parameters used in this document, prepend the 64 octets of key
+   data with the following 37-byte sequence:
+
+      0x30 0x63 0x30 0x1c 0x06 0x06 0x2a 0x85 0x03 0x02 0x02 0x13 0x30
+      0x12 0x06 0x07 0x2a 0x85 0x03 0x02 0x02 0x23 0x01 0x06 0x07 0x2a
+      0x85 0x03 0x02 0x02 0x1e 0x01 0x03 0x43 0x00 0x04 0x40
+
+
+
+
+
+Dolmatov, et al.             Standards Track                    [Page 3]
+
+RFC 5933            Use of GOST Signatures in DNSSEC           July 2010
+
+
+2.2.  GOST DNSKEY RR Example
+
+   Given a private key with the following value (the value of the
+   GostAsn1 field is split here into two lines to simplify reading; in
+   the private key file, it must be in one line):
+
+      Private-key-format: v1.2
+      Algorithm: 12 (ECC-GOST)
+      GostAsn1: MEUCAQAwHAYGKoUDAgITMBIGByqFAwICIwEGByqFAwICHgEEIgQg/9M
+                iXtXKg9FDXDN/R9CmVhJDyuzRAIgh4tPwCu4NHIs=
+
+   The following DNSKEY RR stores a DNS zone key for example.net:
+
+      example.net. 86400 IN DNSKEY 256 3 12 (
+                                   aRS/DcPWGQj2wVJydT8EcAVoC0kXn5pDVm2I
+                                   MvDDPXeD32dsSKcmq8KNVzigjL4OXZTV+t/6
+                                   w4X1gpNrZiC01g==
+                                   ) ; key id = 59732
+
+3.  RRSIG Resource Records
+
+   The value of the signature field in the RRSIG RR follows RFC 4490
+   [RFC4490] and is calculated as follows.  The values for the RDATA
+   fields that precede the signature data are specified in RFC 4034
+   [RFC4034].
+
+   hash = GOSTR3411(data)
+
+   where "data" is the wire format data of the resource record set that
+   is signed, as specified in RFC 4034 [RFC4034].
+
+   The hash MUST be calculated with GOST R 34.11-94 parameters
+   identified by id-GostR3411-94-CryptoProParamSet [RFC4357].
+
+   The signature is calculated from the hash according to the
+   GOST R 34.10-2001 standard, and its wire format is compatible with
+   RFC 4490 [RFC4490].
+
+   Quoting RFC 4490:
+
+   "The signature algorithm GOST R 34.10-2001 generates a digital
+   signature in the form of two 256-bit numbers, r and s.  Its octet
+   string representation consists of 64 octets, where the first
+   32 octets contain the big-endian representation of s and the second
+   32 octets contain the big-endian representation of r".
+
+
+
+
+
+
+Dolmatov, et al.             Standards Track                    [Page 4]
+
+RFC 5933            Use of GOST Signatures in DNSSEC           July 2010
+
+
+3.1.  RRSIG RR Example
+
+   With the private key from Section 2.2, sign the following RRSet,
+   consisting of one A record:
+
+      www.example.net. 3600 IN A 192.0.2.1
+
+   Setting the inception date to 2000-01-01 00:00:00 UTC and the
+   expiration date to 2030-01-01 00:00:00 UTC, the following signature
+   RR will be valid:
+
+     www.example.net. 3600 IN RRSIG A 12 3 3600 20300101000000 (
+                                    20000101000000 59732 example.net.
+                                    7vzzz6iLOmvtjs5FjVjSHT8XnRKFY15ki6Kp
+                                    kNPkUnS8iIns0Kv4APT+D9ibmHhGri6Sfbyy
+                                    zi67+wBbbW/jrA== )
+
+   Note: The ECC-GOST signature algorithm uses random data, so the
+   actual computed signature value will differ between signature
+   calculations.
+
+4.  DS Resource Records
+
+   The GOST R 34.11-94 digest algorithm is denoted in DS RRs by the
+   digest type 3.  The wire format of a digest value is compatible with
+   RFC 4490 [RFC4490], that is, the digest is in little-endian
+   representation.
+
+   The digest MUST always be calculated with GOST R 34.11-94 parameters
+   identified by id-GostR3411-94-CryptoProParamSet [RFC4357].
+
+4.1.  DS RR Example
+
+   For Key Signing Key (KSK):
+
+      example.net. 86400   DNSKEY  257 3 12 (
+                                   LMgXRHzSbIJGn6i16K+sDjaDf/k1o9DbxScO
+                                   gEYqYS/rlh2Mf+BRAY3QHPbwoPh2fkDKBroF
+                                   SRGR7ZYcx+YIQw==
+                                   ) ; key id = 40692
+
+   The DS RR will be
+
+      example.net. 3600 IN DS 40692 12 3 (
+                22261A8B0E0D799183E35E24E2AD6BB58533CBA7E3B14D659E9CA09B
+                2071398F )
+
+
+
+
+
+Dolmatov, et al.             Standards Track                    [Page 5]
+
+RFC 5933            Use of GOST Signatures in DNSSEC           July 2010
+
+
+5.  Deployment Considerations
+
+5.1.  Key Sizes
+
+   According to RFC 4357 [RFC4357], the key size of GOST public keys
+   MUST be 512 bits.
+
+5.2.  Signature Sizes
+
+   According to the GOST R 34.10-2001 digital signature algorithm
+   specification ([GOST3410], [RFC5832]), the size of a GOST signature
+   is 512 bits.
+
+5.3.  Digest Sizes
+
+   According to GOST R 34.11-94 ([GOST3411], [RFC5831]), the size of a
+   GOST digest is 256 bits.
+
+6.  Implementation Considerations
+
+6.1.  Support for GOST Signatures
+
+   DNSSEC-aware implementations MAY be able to support RRSIG and DNSKEY
+   resource records created with the GOST algorithms as defined in this
+   document.
+
+6.2.  Support for NSEC3 Denial of Existence
+
+   Any DNSSEC-GOST implementation MUST support both NSEC [RFC4035] and
+   NSEC3 [RFC5155].
+
+7.  Security Considerations
+
+   Currently, the cryptographic resistance of the GOST R 34.10-2001
+   digital signature algorithm is estimated as 2**128 operations of
+   multiple elliptic curve point computations on prime modulus of order
+   2**256.
+
+   Currently, the cryptographic resistance of the GOST R 34.11-94 hash
+   algorithm is estimated as 2**128 operations of computations of a step
+   hash function.  (There is a known method to reduce this estimate to
+   2**105 operations, but it demands padding the colliding message with
+   1024 random bit blocks each of 256-bit length; thus, it cannot be
+   used in any practical implementation).
+
+
+
+
+
+
+
+Dolmatov, et al.             Standards Track                    [Page 6]
+
+RFC 5933            Use of GOST Signatures in DNSSEC           July 2010
+
+
+8.  IANA Considerations
+
+   This document updates the IANA registry "DNS Security Algorithm
+   Numbers" [RFC4034].  The following entries have been added to the
+   registry:
+
+                                      Zone    Trans.
+    Value  Algorithm         Mnemonic Signing Sec.  References   Status
+     12    GOST R 34.10-2001 ECC-GOST     Y   *     RFC 5933    OPTIONAL
+
+   This document updates the RFC 4034 Digest Types assignment
+   ([RFC4034], Section A.2) by adding the value and status for the
+   GOST R 34.11-94 algorithm:
+
+      Value   Algorithm        Status
+        3    GOST R 34.11-94  OPTIONAL
+
+9.  Acknowledgments
+
+   This document is a minor extension to RFC 4034 [RFC4034].  Also, we
+   tried to follow the documents RFC 3110 [RFC3110], RFC 4509 [RFC4509],
+   and RFC 4357 [RFC4357] for consistency.  The authors of and
+   contributors to these documents are gratefully acknowledged for their
+   hard work.
+
+   The following people provided additional feedback, text, and valuable
+   assistance: Dmitry Burkov, Jaap Akkerhuis, Olafur Gundmundsson,
+   Jelte Jansen, and Wouter Wijngaards.
+
+10.  References
+
+10.1.  Normative References
+
+   [GOST3410]  "Information technology.  Cryptographic data security.
+               Signature and verification processes of [electronic]
+               digital signature.", GOST R 34.10-2001, Gosudarstvennyi
+               Standard of Russian Federation, Government Committee of
+               Russia for Standards, 2001. (In Russian).
+
+   [GOST3411]  "Information technology.  Cryptographic data security.
+               Hashing function.", GOST R 34.11-94, Gosudarstvennyi
+               Standard of Russian Federation, Government Committee of
+               Russia for Standards, 1994. (In Russian).
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+
+Dolmatov, et al.             Standards Track                    [Page 7]
+
+RFC 5933            Use of GOST Signatures in DNSSEC           July 2010
+
+
+   [RFC3110]   Eastlake 3rd, D., "RSA/SHA-1 SIGs and RSA KEYs in the
+               Domain Name System (DNS)", RFC 3110, May 2001.
+
+   [RFC4033]   Arends, R., Austein, R., Larson, M., Massey, D., and S.
+               Rose, "DNS Security Introduction and Requirements",
+               RFC 4033, March 2005.
+
+   [RFC4034]   Arends, R., Austein, R., Larson, M., Massey, D., and S.
+               Rose, "Resource Records for the DNS Security Extensions",
+               RFC 4034, March 2005.
+
+   [RFC4035]   Arends, R., Austein, R., Larson, M., Massey, D., and S.
+               Rose, "Protocol Modifications for the DNS Security
+               Extensions", RFC 4035, March 2005.
+
+   [RFC4357]   Popov, V., Kurepkin, I., and S. Leontiev, "Additional
+               Cryptographic Algorithms for Use with GOST 28147-89,
+               GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94
+               Algorithms", RFC 4357, January 2006.
+
+   [RFC4490]   Leontiev, S., Ed. and G. Chudov, Ed., "Using the
+               GOST 28147-89, GOST R 34.11-94, GOST R 34.10-94, and
+               GOST R 34.10-2001 Algorithms with Cryptographic Message
+               Syntax (CMS)", RFC 4490, May 2006.
+
+   [RFC4491]   Leontiev, S., Ed. and D. Shefanovski, Ed., "Using the
+               GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94
+               Algorithms with the Internet X.509 Public Key
+               Infrastructure Certificate and CRL Profile", RFC 4491,
+               May 2006.
+
+   [RFC5155]   Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
+               Security (DNSSEC) Hashed Authenticated Denial of
+               Existence", RFC 5155, March 2008.
+
+10.2.  Informative References
+
+   [RFC4509]   Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
+               (DS) Resource Records (RRs)", RFC 4509, May 2006.
+
+   [RFC5830]   Dolmatov, V., Ed., "GOST 28147-89: Encryption,
+               Decryption, and Message Authentication Code (MAC)
+               Algorithms", RFC 5830, March 2010.
+
+   [RFC5831]   Dolmatov, V., Ed., "GOST R 34.11-94: Hash Function
+               Algorithm", RFC 5831, March 2010.
+
+
+
+
+
+Dolmatov, et al.             Standards Track                    [Page 8]
+
+RFC 5933            Use of GOST Signatures in DNSSEC           July 2010
+
+
+   [RFC5832]   Dolmatov, V., Ed., "GOST R 34.10-2001: Digital Signature
+               Algorithm", RFC 5832, March 2010.
+
+Authors' Addresses
+
+   Vasily Dolmatov (editor)
+   Cryptocom Ltd.
+   14/2, Kedrova St.
+   Moscow,   117218
+   Russian Federation
+
+   Phone: +7 499 124 6226
+   EMail: [email protected]
+
+
+   Artem Chuprina
+   Cryptocom Ltd.
+   14/2, Kedrova St.
+   Moscow,   117218
+   Russian Federation
+
+   Phone: +7 499 124 6226
+   EMail: [email protected]
+
+
+   Igor Ustinov
+   Cryptocom Ltd.
+   14/2, Kedrova St.
+   Moscow,   117218
+   Russian Federation
+
+   Phone: +7 499 124 6226
+   EMail: [email protected]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dolmatov, et al.             Standards Track                    [Page 9]
+

contrib/bind9/lib/dns/api

@@ -1,3 +1,3 @@
-LIBINTERFACE = 38
-LIBREVISION = 0
-LIBAGE = 0
+LIBINTERFACE = 39
+LIBREVISION = 1
+LIBAGE = 1

contrib/bind9/lib/dns/include/dns/db.h

@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004, 2005, 2007, 2009  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007, 2009, 2010  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: db.h,v 1.76.18.14 2009/01/19 00:36:28 marka Exp $ */
+/* $Id: db.h,v 1.76.18.16 2010/11/17 23:45:12 tbox Exp $ */
 
 #ifndef DNS_DB_H
 #define DNS_DB_H 1
@@ -184,13 +184,15 @@ struct dns_db {
 /*%
  * Options that can be specified for dns_db_find().
  */
-#define DNS_DBFIND_GLUEOK		0x01
-#define DNS_DBFIND_VALIDATEGLUE		0x02
-#define DNS_DBFIND_NOWILD		0x04
-#define DNS_DBFIND_PENDINGOK		0x08
-#define DNS_DBFIND_NOEXACT		0x10
-#define DNS_DBFIND_FORCENSEC		0x20
-#define DNS_DBFIND_COVERINGNSEC		0x40
+#define DNS_DBFIND_GLUEOK		0x0001
+#define DNS_DBFIND_VALIDATEGLUE		0x0002
+#define DNS_DBFIND_NOWILD		0x0004
+#define DNS_DBFIND_PENDINGOK		0x0008
+#define DNS_DBFIND_NOEXACT		0x0010
+#define DNS_DBFIND_FORCENSEC		0x0020
+#define DNS_DBFIND_COVERINGNSEC		0x0040
+#define DNS_DBFIND_FORCENSEC3		0x0080
+#define DNS_DBFIND_ADDITIONALOK		0x0100
 /*@}*/
 
 /*@{*/
@@ -649,6 +651,10 @@ dns_db_find(dns_db_t *db, dns_name_t *name, dns_dbversion_t *version,
  *	For cache databases, glue is any rdataset with a trust of
  *	dns_trust_glue.
  *
+ * \li	If 'options' does not have #DNS_DBFIND_ADDITIONALOK set, then no
+ *	additional records will be returned.  Only caches can have
+ *	rdataset with trust dns_trust_additional.
+ *
  * \li	If 'options' does not have #DNS_DBFIND_PENDINGOK set, then no
  *	pending data will be returned.  This option is only meaningful for
  *	cache databases.

contrib/bind9/lib/dns/include/dns/ncache.h

@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2010  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: ncache.h,v 1.17.18.2 2005/04/29 00:16:16 marka Exp $ */
+/* $Id: ncache.h,v 1.17.18.4 2010/06/04 23:46:02 tbox Exp $ */
 
 #ifndef DNS_NCACHE_H
 #define DNS_NCACHE_H 1
@@ -63,6 +63,11 @@ isc_result_t
 dns_ncache_add(dns_message_t *message, dns_db_t *cache, dns_dbnode_t *node,
 	       dns_rdatatype_t covers, isc_stdtime_t now, dns_ttl_t maxttl,
 	       dns_rdataset_t *addedrdataset);
+isc_result_t
+dns_ncache_addoptout(dns_message_t *message, dns_db_t *cache,
+		     dns_dbnode_t *node, dns_rdatatype_t covers,
+		     isc_stdtime_t now, dns_ttl_t maxttl,
+		     isc_boolean_t optout, dns_rdataset_t *addedrdataset);
 /*%<
  * Convert the authority data from 'message' into a negative cache
  * rdataset, and store it in 'cache' at 'node' with a TTL limited to
@@ -71,6 +76,8 @@ dns_ncache_add(dns_message_t *message, dns_db_t *cache, dns_dbnode_t *node,
  * The 'covers' argument is the RR type whose nonexistence we are caching,
  * or dns_rdatatype_any when caching a NXDOMAIN response.
  *
+ * 'optout' indicates a DNS_RDATASETATTR_OPTOUT should be set.
+ *
  * Note:
  *\li	If 'addedrdataset' is not NULL, then it will be attached to the added
  *	rdataset.  See dns_db_addrdataset() for more details.
@@ -154,6 +161,26 @@ dns_ncache_getrdataset(dns_rdataset_t *ncacherdataset, dns_name_t *name,
  *
  */
 
+isc_result_t
+dns_ncache_getsigrdataset(dns_rdataset_t *ncacherdataset, dns_name_t *name,
+			  dns_rdatatype_t covers, dns_rdataset_t *rdataset);
+/*%<
+ * Similar to dns_ncache_getrdataset() but get the rrsig that matches.
+ */
+
+void
+dns_ncache_current(dns_rdataset_t *ncacherdataset, dns_name_t *found,
+		   dns_rdataset_t *rdataset);
+
+/*%<
+ * Extract the current rdataset and name from a ncache entry.
+ *
+ * Requires:
+ * \li	'ncacherdataset' to be valid and to be a negative cache entry
+ * \li	'found' to be valid.
+ * \li	'rdataset' to be unassociated.
+ */
+
 ISC_LANG_ENDDECLS
 
 #endif /* DNS_NCACHE_H */

contrib/bind9/lib/dns/include/dns/rdataset.h

@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2006, 2009  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2006, 2009, 2010  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: rdataset.h,v 1.51.18.9 2009/01/19 23:46:16 tbox Exp $ */
+/* $Id: rdataset.h,v 1.51.18.11 2010/02/26 23:46:37 tbox Exp $ */
 
 #ifndef DNS_RDATASET_H
 #define DNS_RDATASET_H 1
@@ -104,6 +104,9 @@ typedef struct dns_rdatasetmethods {
 						 dns_rdataset_t *rdataset,
 						 dns_rdatasetadditional_t type,
 						 dns_rdatatype_t qtype);
+	void			(*settrust)(dns_rdataset_t *rdataset,
+					    dns_trust_t trust);
+	void			(*expire)(dns_rdataset_t *rdataset);
 } dns_rdatasetmethods_t;
 
 #define DNS_RDATASET_MAGIC	       ISC_MAGIC('D','N','S','R')
@@ -592,6 +595,19 @@ dns_rdataset_putadditional(dns_acache_t *acache,
  *			  information for 'rdataset.'
  */
 
+void
+dns_rdataset_settrust(dns_rdataset_t *rdataset, dns_trust_t trust);
+/*%<
+ * Set the trust of the 'rdataset' to trust in any in the backing database.
+ * The local trust level of 'rdataset' is also set.
+ */
+
+void
+dns_rdataset_expire(dns_rdataset_t *rdataset);
+/*%<
+ * Mark the rdataset to be expired in the backing database.
+ */
+
 ISC_LANG_ENDDECLS
 
 #endif /* DNS_RDATASET_H */

contrib/bind9/lib/dns/include/dns/resolver.h

@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2006, 2009  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2006, 2009, 2010  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001, 2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: resolver.h,v 1.40.18.13 2009/09/24 23:46:07 tbox Exp $ */
+/* $Id: resolver.h,v 1.40.18.15 2010/02/26 23:46:37 tbox Exp $ */
 
 #ifndef DNS_RESOLVER_H
 #define DNS_RESOLVER_H 1
@@ -491,6 +491,48 @@ dns_resolver_getzeronosoattl(dns_resolver_t *resolver);
 void
 dns_resolver_setzeronosoattl(dns_resolver_t *resolver, isc_boolean_t state);
 
+void
+dns_resolver_addbadcache(dns_resolver_t *resolver, dns_name_t *name,
+			 dns_rdatatype_t type, isc_time_t *expire);
+/*%<
+ * Add a entry to the bad cache for <name,type> that will expire at 'expire'.
+ *
+ * Requires:
+ * \li	resolver to be valid.
+ * \li	name to be valid.
+ */
+
+isc_boolean_t
+dns_resolver_getbadcache(dns_resolver_t *resolver, dns_name_t *name,
+			 dns_rdatatype_t type, isc_time_t *now);
+/*%<
+ * Check to see if there is a unexpired entry in the bad cache for
+ * <name,type>.
+ *
+ * Requires:
+ * \li	resolver to be valid.
+ * \li	name to be valid.
+ */
+
+void
+dns_resolver_flushbadcache(dns_resolver_t *resolver, dns_name_t *name);
+/*%<
+ * Flush the bad cache of all entries at 'name' if 'name' is non NULL.
+ * Flush the entire bad cache if 'name' is NULL.
+ *
+ * Requires:
+ * \li	resolver to be valid.
+ */
+
+void
+dns_resolver_printbadcache(dns_resolver_t *resolver, FILE *fp);
+/*%
+ * Print out the contents of the bad cache to 'fp'.
+ *
+ * Requires:
+ * \li	resolver to be valid.
+ */
+
 ISC_LANG_ENDDECLS
 
 #endif /* DNS_RESOLVER_H */

contrib/bind9/lib/dns/include/dns/result.h

@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2010  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: result.h,v 1.104.10.6 2005/06/17 02:04:32 marka Exp $ */
+/* $Id: result.h,v 1.104.10.8 2010/02/26 23:46:37 tbox Exp $ */
 
 #ifndef DNS_RESULT_H
 #define DNS_RESULT_H 1
@@ -147,8 +147,11 @@
 #define DNS_R_COVERINGNSEC		(ISC_RESULTCLASS_DNS + 101)
 #define DNS_R_MXISADDRESS		(ISC_RESULTCLASS_DNS + 102)
 #define DNS_R_DUPLICATE			(ISC_RESULTCLASS_DNS + 103)
+#define DNS_R_INVALIDNSEC3		(ISC_RESULTCLASS_DNS + 104)
+#define DNS_R_NOTMASTER			(ISC_RESULTCLASS_DNS + 105)
+#define DNS_R_BROKENCHAIN		(ISC_RESULTCLASS_DNS + 106)
 
-#define DNS_R_NRESULTS			104	/*%< Number of results */
+#define DNS_R_NRESULTS			107	/*%< Number of results */
 
 /*
  * DNS wire format rcodes.

contrib/bind9/lib/dns/include/dns/types.h

@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2006, 2009  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2006, 2009, 2010  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: types.h,v 1.109.18.15 2009/11/25 04:50:25 marka Exp $ */
+/* $Id: types.h,v 1.109.18.17 2010/06/04 23:46:02 tbox Exp $ */
 
 #ifndef DNS_TYPES_H
 #define DNS_TYPES_H 1
@@ -285,6 +285,7 @@ enum {
 #define DNS_TRUST_PENDING(x)		((x) == dns_trust_pending_answer || \
 					 (x) == dns_trust_pending_additional)
 #define DNS_TRUST_GLUE(x)		((x) == dns_trust_glue)
+#define DNS_TRUST_ANSWER(x)		((x) == dns_trust_answer)
 
 
 /*%

contrib/bind9/lib/dns/include/dns/validator.h

@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004, 2005, 2007, 2009  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007, 2009, 2010  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: validator.h,v 1.27.18.13 2009/01/19 00:36:28 marka Exp $ */
+/* $Id: validator.h,v 1.27.18.15 2010/02/26 23:46:37 tbox Exp $ */
 
 #ifndef DNS_VALIDATOR_H
 #define DNS_VALIDATOR_H 1
@@ -151,6 +151,8 @@ struct dns_validator {
 	isc_boolean_t			mustbesecure;
 	unsigned int			dlvlabels;
 	unsigned int			depth;
+	unsigned int			authcount;
+	unsigned int			authfail;
 };
 
 /*%

contrib/bind9/lib/dns/ncache.c

@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2010  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: ncache.c,v 1.36.18.3 2005/04/29 00:15:59 marka Exp $ */
+/* $Id: ncache.c,v 1.36.18.8 2010/06/03 23:46:10 tbox Exp $ */
 
 /*! \file */
 
@@ -30,6 +30,9 @@
 #include <dns/rdata.h>
 #include <dns/rdatalist.h>
 #include <dns/rdataset.h>
+#include <dns/rdatastruct.h>
+
+#define DNS_NCACHE_RDATA 20U
 
 /*
  * The format of an ncache rdata is a sequence of one or more records of
@@ -37,6 +40,7 @@
  *
  *	owner name
  *	type
+ *	trust
  *	rdata count
  *		rdata length			These two occur 'rdata count'
  *		rdata				times.
@@ -100,10 +104,11 @@ dns_ncache_add(dns_message_t *message, dns_db_t *cache, dns_dbnode_t *node,
 	dns_name_t *name;
 	dns_ttl_t ttl;
 	dns_trust_t trust;
-	dns_rdata_t rdata = DNS_RDATA_INIT;
+	dns_rdata_t rdata[DNS_NCACHE_RDATA];
 	dns_rdataset_t ncrdataset;
 	dns_rdatalist_t ncrdatalist;
 	unsigned char data[4096];
+	unsigned int next = 0;
 
 	/*
 	 * Convert the authority data from 'message' into a negative cache
@@ -118,7 +123,17 @@ dns_ncache_add(dns_message_t *message, dns_db_t *cache, dns_dbnode_t *node,
 	 */
 
 	/*
-	 * First, build an ncache rdata in buffer.
+	 * Initialize the list.
+	 */
+	ncrdatalist.rdclass = dns_db_class(cache);
+	ncrdatalist.type = 0;
+	ncrdatalist.covers = covers;
+	ncrdatalist.ttl = maxttl;
+	ISC_LIST_INIT(ncrdatalist.rdata);
+	ISC_LINK_INIT(&ncrdatalist, link);
+
+	/*
+	 * Build an ncache rdatas into buffer.
 	 */
 	ttl = maxttl;
 	trust = 0xffff;
@@ -160,10 +175,12 @@ dns_ncache_add(dns_message_t *message, dns_db_t *cache, dns_dbnode_t *node,
 					 */
 					isc_buffer_availableregion(&buffer,
 								   &r);
-					if (r.length < 3)
+					if (r.length < 2)
 						return (ISC_R_NOSPACE);
 					isc_buffer_putuint16(&buffer,
 							     rdataset->type);
+					isc_buffer_putuint8(&buffer,
+							     rdataset->trust);
 					/*
 					 * Copy the rdataset into the buffer.
 					 */
@@ -171,6 +188,21 @@ dns_ncache_add(dns_message_t *message, dns_db_t *cache, dns_dbnode_t *node,
 							       &buffer);
 					if (result != ISC_R_SUCCESS)
 						return (result);
+
+					if (next >= DNS_NCACHE_RDATA)
+						return (ISC_R_NOSPACE);
+					dns_rdata_init(&rdata[next]);
+					isc_buffer_remainingregion(&buffer, &r);
+					rdata[next].data = r.base;
+					rdata[next].length = r.length;
+					rdata[next].rdclass =
+						ncrdatalist.rdclass;
+					rdata[next].type = 0;
+					rdata[next].flags = 0;
+					ISC_LIST_APPEND(ncrdatalist.rdata,
+							&rdata[next], link);
+					isc_buffer_forward(&buffer, r.length);
+					next++;
 				}
 			}
 		}
@@ -205,10 +237,9 @@ dns_ncache_add(dns_message_t *message, dns_db_t *cache, dns_dbnode_t *node,
 		 * Copy the type and a zero rdata count to the buffer.
 		 */
 		isc_buffer_availableregion(&buffer, &r);
-		if (r.length < 4)
+		if (r.length < 5)
 			return (ISC_R_NOSPACE);
-		isc_buffer_putuint16(&buffer, 0);
-		isc_buffer_putuint16(&buffer, 0);
+		isc_buffer_putuint16(&buffer, 0);	/* type */
 		/*
 		 * RFC2308, section 5, says that negative answers without
 		 * SOAs should not be cached.
@@ -226,27 +257,27 @@ dns_ncache_add(dns_message_t *message, dns_db_t *cache, dns_dbnode_t *node,
 			trust = dns_trust_authauthority;
 		} else
 			trust = dns_trust_additional;
+		isc_buffer_putuint8(&buffer, trust);	/* trust */
+		isc_buffer_putuint16(&buffer, 0);	/* count */
+
+		/*
+		 * Now add it to the cache.
+		 */
+		if (next >= DNS_NCACHE_RDATA)
+			return (ISC_R_NOSPACE);
+		dns_rdata_init(&rdata[next]);
+		isc_buffer_remainingregion(&buffer, &r);
+		rdata[next].data = r.base;
+		rdata[next].length = r.length;
+		rdata[next].rdclass = ncrdatalist.rdclass;
+		rdata[next].type = 0;
+		rdata[next].flags = 0;
+		ISC_LIST_APPEND(ncrdatalist.rdata, &rdata[next], link);
 	}
 
-	/*
-	 * Now add it to the cache.
-	 */
 	INSIST(trust != 0xffff);
-	isc_buffer_usedregion(&buffer, &r);
-	rdata.data = r.base;
-	rdata.length = r.length;
-	rdata.rdclass = dns_db_class(cache);
-	rdata.type = 0;
-	rdata.flags = 0;
 
-	ncrdatalist.rdclass = rdata.rdclass;
-	ncrdatalist.type = 0;
-	ncrdatalist.covers = covers;
 	ncrdatalist.ttl = ttl;
-	ISC_LIST_INIT(ncrdatalist.rdata);
-	ISC_LINK_INIT(&ncrdatalist, link);
-
-	ISC_LIST_APPEND(ncrdatalist.rdata, &rdata, link);
 
 	dns_rdataset_init(&ncrdataset);
 	RUNTIME_CHECK(dns_rdatalist_tordataset(&ncrdatalist, &ncrdataset)
@@ -281,18 +312,14 @@ dns_ncache_towire(dns_rdataset_t *rdataset, dns_compress_t *cctx,
 	REQUIRE(rdataset != NULL);
 	REQUIRE(rdataset->type == 0);
 
-	result = dns_rdataset_first(rdataset);
-	if (result != ISC_R_SUCCESS)
-		return (result);
-	dns_rdataset_current(rdataset, &rdata);
-	INSIST(dns_rdataset_next(rdataset) == ISC_R_NOMORE);
-	isc_buffer_init(&source, rdata.data, rdata.length);
-	isc_buffer_add(&source, rdata.length);
-
 	savedbuffer = *target;
-
 	count = 0;
-	do {
+
+	result = dns_rdataset_first(rdataset);
+	while (result == ISC_R_SUCCESS) {
+		dns_rdataset_current(rdataset, &rdata);
+		isc_buffer_init(&source, rdata.data, rdata.length);
+		isc_buffer_add(&source, rdata.length);
 		dns_name_init(&name, NULL);
 		isc_buffer_remainingregion(&source, &remaining);
 		dns_name_fromregion(&name, &remaining);
@@ -300,8 +327,9 @@ dns_ncache_towire(dns_rdataset_t *rdataset, dns_compress_t *cctx,
 		isc_buffer_forward(&source, name.length);
 		remaining.length -= name.length;
 
-		INSIST(remaining.length >= 4);
+		INSIST(remaining.length >= 5);
 		type = isc_buffer_getuint16(&source);
+		isc_buffer_forward(&source, 1);
 		rcount = isc_buffer_getuint16(&source);
 
 		for (i = 0; i < rcount; i++) {
@@ -370,8 +398,12 @@ dns_ncache_towire(dns_rdataset_t *rdataset, dns_compress_t *cctx,
 
 			count++;
 		}
-		isc_buffer_remainingregion(&source, &remaining);
-	} while (remaining.length > 0);
+		INSIST(isc_buffer_remaininglength(&source) == 0);
+		result = dns_rdataset_next(rdataset);
+		dns_rdata_reset(&rdata);
+	}
+	if (result != ISC_R_NOMORE)
+		goto rollback;
 
 	*countp = count;
 
@@ -467,6 +499,13 @@ rdataset_count(dns_rdataset_t *rdataset) {
 	return (count);
 }
 
+static void
+rdataset_settrust(dns_rdataset_t *rdataset, dns_trust_t trust) {
+	unsigned char *raw = rdataset->private3;
+
+	raw[-1] = trust;
+}
+
 static dns_rdatasetmethods_t rdataset_methods = {
 	rdataset_disassociate,
 	rdataset_first,
@@ -478,7 +517,9 @@ static dns_rdatasetmethods_t rdataset_methods = {
 	NULL,
 	NULL,
 	NULL,
-	NULL
+	NULL,
+	rdataset_settrust,
+	NULL,
 };
 
 isc_result_t
@@ -491,8 +532,8 @@ dns_ncache_getrdataset(dns_rdataset_t *ncacherdataset, dns_name_t *name,
 	isc_buffer_t source;
 	dns_name_t tname;
 	dns_rdatatype_t ttype;
-	unsigned int i, rcount;
-	isc_uint16_t length;
+	dns_trust_t trust = dns_trust_none;
+	dns_rdataset_t clone;
 
 	REQUIRE(ncacherdataset != NULL);
 	REQUIRE(ncacherdataset->type == 0);
@@ -500,15 +541,13 @@ dns_ncache_getrdataset(dns_rdataset_t *ncacherdataset, dns_name_t *name,
 	REQUIRE(!dns_rdataset_isassociated(rdataset));
 	REQUIRE(type != dns_rdatatype_rrsig);
 
-	result = dns_rdataset_first(ncacherdataset);
-	if (result != ISC_R_SUCCESS)
-		return (result);
-	dns_rdataset_current(ncacherdataset, &rdata);
-	INSIST(dns_rdataset_next(ncacherdataset) == ISC_R_NOMORE);
-	isc_buffer_init(&source, rdata.data, rdata.length);
-	isc_buffer_add(&source, rdata.length);
-
-	do {
+	dns_rdataset_init(&clone);
+	dns_rdataset_clone(ncacherdataset, &clone);
+	result = dns_rdataset_first(&clone);
+	while (result == ISC_R_SUCCESS) {
+		dns_rdataset_current(&clone, &rdata);
+		isc_buffer_init(&source, rdata.data, rdata.length);
+		isc_buffer_add(&source, rdata.length);
 		dns_name_init(&tname, NULL);
 		isc_buffer_remainingregion(&source, &remaining);
 		dns_name_fromregion(&tname, &remaining);
@@ -516,35 +555,32 @@ dns_ncache_getrdataset(dns_rdataset_t *ncacherdataset, dns_name_t *name,
 		isc_buffer_forward(&source, tname.length);
 		remaining.length -= tname.length;
 
-		INSIST(remaining.length >= 4);
+		INSIST(remaining.length >= 3);
 		ttype = isc_buffer_getuint16(&source);
 
 		if (ttype == type && dns_name_equal(&tname, name)) {
+			trust = isc_buffer_getuint8(&source);
+			INSIST(trust <= dns_trust_ultimate);
 			isc_buffer_remainingregion(&source, &remaining);
 			break;
 		}
-
-		rcount = isc_buffer_getuint16(&source);
-		for (i = 0; i < rcount; i++) {
-			isc_buffer_remainingregion(&source, &remaining);
-			INSIST(remaining.length >= 2);
-			length = isc_buffer_getuint16(&source);
-			isc_buffer_remainingregion(&source, &remaining);
-			INSIST(remaining.length >= length);
-			isc_buffer_forward(&source, length);
-		}
-		isc_buffer_remainingregion(&source, &remaining);
-	} while (remaining.length > 0);
-
-	if (remaining.length == 0)
+		result = dns_rdataset_next(&clone);
+		dns_rdata_reset(&rdata);
+	}
+	dns_rdataset_disassociate(&clone);
+	if (result == ISC_R_NOMORE)
 		return (ISC_R_NOTFOUND);
+	if (result != ISC_R_SUCCESS)
+		return (result);
+
+	INSIST(remaining.length != 0);
 
 	rdataset->methods = &rdataset_methods;
 	rdataset->rdclass = ncacherdataset->rdclass;
 	rdataset->type = type;
 	rdataset->covers = 0;
 	rdataset->ttl = ncacherdataset->ttl;
-	rdataset->trust = ncacherdataset->trust;
+	rdataset->trust = trust;
 	rdataset->private1 = NULL;
 	rdataset->private2 = NULL;
 
@@ -555,5 +591,179 @@ dns_ncache_getrdataset(dns_rdataset_t *ncacherdataset, dns_name_t *name,
 	 */
 	rdataset->privateuint4 = 0;
 	rdataset->private5 = NULL;
+	rdataset->private6 = NULL;
 	return (ISC_R_SUCCESS);
 }
+
+isc_result_t
+dns_ncache_getsigrdataset(dns_rdataset_t *ncacherdataset, dns_name_t *name,
+			  dns_rdatatype_t covers, dns_rdataset_t *rdataset)
+{
+	dns_name_t tname;
+	dns_rdata_rrsig_t rrsig;
+	dns_rdata_t rdata = DNS_RDATA_INIT;
+	dns_rdataset_t clone;
+	dns_rdatatype_t type;
+	dns_trust_t trust = dns_trust_none;
+	isc_buffer_t source;
+	isc_region_t remaining, sigregion;
+	isc_result_t result;
+	unsigned char *raw;
+	unsigned int count;
+
+	REQUIRE(ncacherdataset != NULL);
+	REQUIRE(ncacherdataset->type == 0);
+	REQUIRE(name != NULL);
+	REQUIRE(!dns_rdataset_isassociated(rdataset));
+
+	dns_rdataset_init(&clone);
+	dns_rdataset_clone(ncacherdataset, &clone);
+	result = dns_rdataset_first(&clone);
+	while (result == ISC_R_SUCCESS) {
+		dns_rdataset_current(&clone, &rdata);
+		isc_buffer_init(&source, rdata.data, rdata.length);
+		isc_buffer_add(&source, rdata.length);
+		dns_name_init(&tname, NULL);
+		isc_buffer_remainingregion(&source, &remaining);
+		dns_name_fromregion(&tname, &remaining);
+		INSIST(remaining.length >= tname.length);
+		isc_buffer_forward(&source, tname.length);
+		remaining.length -= tname.length;
+		remaining.base += tname.length;
+
+		INSIST(remaining.length >= 2);
+		type = isc_buffer_getuint16(&source);
+		remaining.length -= 2;
+		remaining.base += 2;
+
+		if (type != dns_rdatatype_rrsig ||
+		    !dns_name_equal(&tname, name)) {
+			result = dns_rdataset_next(&clone);
+			dns_rdata_reset(&rdata);
+			continue;
+		}
+
+		INSIST(remaining.length >= 1);
+		trust = isc_buffer_getuint8(&source);
+		INSIST(trust <= dns_trust_ultimate);
+		remaining.length -= 1;
+		remaining.base += 1;
+
+		raw = remaining.base;
+		count = raw[0] * 256 + raw[1];
+		INSIST(count > 0);
+		raw += 2;
+		sigregion.length = raw[0] * 256 + raw[1];
+		raw += 2;
+		sigregion.base = raw;
+		dns_rdata_reset(&rdata);
+		dns_rdata_fromregion(&rdata, rdataset->rdclass,
+				     dns_rdatatype_rrsig, &sigregion);
+		(void)dns_rdata_tostruct(&rdata, &rrsig, NULL);
+		if (rrsig.covered == covers) {
+			isc_buffer_remainingregion(&source, &remaining);
+			break;
+		}
+
+		result = dns_rdataset_next(&clone);
+		dns_rdata_reset(&rdata);
+	}
+	dns_rdataset_disassociate(&clone);
+	if (result == ISC_R_NOMORE)
+		return (ISC_R_NOTFOUND);
+	if (result != ISC_R_SUCCESS)
+		return (result);
+
+	INSIST(remaining.length != 0);
+
+	rdataset->methods = &rdataset_methods;
+	rdataset->rdclass = ncacherdataset->rdclass;
+	rdataset->type = dns_rdatatype_rrsig;
+	rdataset->covers = covers;
+	rdataset->ttl = ncacherdataset->ttl;
+	rdataset->trust = trust;
+	rdataset->private1 = NULL;
+	rdataset->private2 = NULL;
+
+	rdataset->private3 = remaining.base;
+
+	/*
+	 * Reset iterator state.
+	 */
+	rdataset->privateuint4 = 0;
+	rdataset->private5 = NULL;
+	rdataset->private6 = NULL;
+	return (ISC_R_SUCCESS);
+}
+
+void
+dns_ncache_current(dns_rdataset_t *ncacherdataset, dns_name_t *found,
+		   dns_rdataset_t *rdataset)
+{
+	dns_rdata_t rdata = DNS_RDATA_INIT;
+	dns_trust_t trust;
+	isc_region_t remaining, sigregion;
+	isc_buffer_t source;
+	dns_name_t tname;
+	dns_rdatatype_t type;
+	unsigned int count;
+	dns_rdata_rrsig_t rrsig;
+	unsigned char *raw;
+
+	REQUIRE(ncacherdataset != NULL);
+	REQUIRE(ncacherdataset->type == 0);
+	REQUIRE(found != NULL);
+	REQUIRE(!dns_rdataset_isassociated(rdataset));
+
+	dns_rdataset_current(ncacherdataset, &rdata);
+	isc_buffer_init(&source, rdata.data, rdata.length);
+	isc_buffer_add(&source, rdata.length);
+
+	dns_name_init(&tname, NULL);
+	isc_buffer_remainingregion(&source, &remaining);
+	dns_name_fromregion(found, &remaining);
+	INSIST(remaining.length >= found->length);
+	isc_buffer_forward(&source, found->length);
+	remaining.length -= found->length;
+
+	INSIST(remaining.length >= 5);
+	type = isc_buffer_getuint16(&source);
+	trust = isc_buffer_getuint8(&source);
+	INSIST(trust <= dns_trust_ultimate);
+	isc_buffer_remainingregion(&source, &remaining);
+
+	rdataset->methods = &rdataset_methods;
+	rdataset->rdclass = ncacherdataset->rdclass;
+	rdataset->type = type;
+	if (type == dns_rdatatype_rrsig) {
+		/*
+		 * Extract covers from RRSIG.
+		 */
+		raw = remaining.base;
+		count = raw[0] * 256 + raw[1];
+		INSIST(count > 0);
+		raw += 2;
+		sigregion.length = raw[0] * 256 + raw[1];
+		raw += 2;
+		sigregion.base = raw;
+		dns_rdata_reset(&rdata);
+		dns_rdata_fromregion(&rdata, rdataset->rdclass,
+				     rdataset->type, &sigregion);
+		(void)dns_rdata_tostruct(&rdata, &rrsig, NULL);
+		rdataset->covers = rrsig.covered;
+	} else
+		rdataset->covers = 0;
+	rdataset->ttl = ncacherdataset->ttl;
+	rdataset->trust = trust;
+	rdataset->private1 = NULL;
+	rdataset->private2 = NULL;
+
+	rdataset->private3 = remaining.base;
+
+	/*
+	 * Reset iterator state.
+	 */
+	rdataset->privateuint4 = 0;
+	rdataset->private5 = NULL;
+	rdataset->private6 = NULL;
+}