2522. [security] Handle -1 from DSA_do_verify().

2520.	[bug]		Update xml statistics version number to 2.0 as change
			#2388 made the schema incompatible to the previous
			version. [RT #19080]

CHANGES

@@ -1,3 +1,24 @@
+	--- 9.5.1-P1 released ---
+
+2522.	[security]	Handle -1 from DSA_do_verify().
+
+	--- 9.5.1 released ---
+
+2520.	[bug]		Update xml statistics version number to 2.0 as change
+			#2388 made the schema incompatible to the previous
+			version. [RT #19080]
+
+	--- 9.5.1rc2 released ---
+
+2513	[bug]		Fix windows cli build. [RT #19062]
+
+2510.	[bug]		"dig +sigchase" could trigger REQUIRE failures.
+			[RT #19033]
+
+2509.	[bug]		Specifying a fixed query source port was broken.
+			[RT #19051]
+
+2504.	[bug]		Address race condition in the socket code. [RT #18899]
 
 	--- 9.5.1rc1 released ---
 
@@ -238,6 +259,10 @@
 			for select().  To enable this, set ISC_SOCKET_MAXSOCKETS
 			at compilation time.  [RT #18433]
 
+			Note: with changes #2469 and #2421 above, there is no
+			need to tweak ISC_SOCKET_MAXSOCKETS at compilation time
+			any more.
+
 2410.	[bug]		Correctly delete m_versionInfo. [RT #18432]
 
 2409.	[bug]		Only log that we disabled EDNS processing if we were

README

@@ -43,6 +43,9 @@ BIND 9
 		Nominum, Inc.
 
 
+BIND 9.5.1
+	BIND 9.5.1 is a maintence release for BIND 9.5.
+
 BIND 9.5.0
 
 	BIND 9.5.0 has a number of new features over 9.4,

bin/dig/dighost.c

@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: dighost.c,v 1.304.12.7 2008/07/23 23:31:17 marka Exp $ */
+/* $Id: dighost.c,v 1.304.12.7.6.1 2008/12/10 23:25:06 marka Exp $ */
 
 /*! \file
  *  \note
@@ -3616,7 +3616,7 @@ dns_rdataset_t *
 search_type(dns_name_t *name, dns_rdatatype_t type, dns_rdatatype_t covers) {
 	dns_rdataset_t *rdataset;
 	dns_rdata_sig_t siginfo;
-	dns_rdata_t sigrdata;
+	dns_rdata_t sigrdata = DNS_RDATA_INIT;
 	isc_result_t result;
 
 	for (rdataset = ISC_LIST_HEAD(name->list); rdataset != NULL;
@@ -3626,7 +3626,6 @@ search_type(dns_name_t *name, dns_rdatatype_t type, dns_rdatatype_t covers) {
 				return (rdataset);
 		} else if ((type == dns_rdatatype_rrsig) &&
 			   (rdataset->type == dns_rdatatype_rrsig)) {
-			dns_rdata_init(&sigrdata);
 			result = dns_rdataset_first(rdataset);
 			check_result(result, "empty rdataset");
 			dns_rdataset_current(rdataset, &sigrdata);
@@ -4149,7 +4148,7 @@ isc_result_t
 grandfather_pb_test(dns_name_t *zone_name, dns_rdataset_t  *sigrdataset)
 {
 	isc_result_t result;
-	dns_rdata_t sigrdata;
+	dns_rdata_t sigrdata = DNS_RDATA_INIT;
 	dns_rdata_sig_t siginfo;
 
 	result = dns_rdataset_first(sigrdataset);
@@ -4169,6 +4168,7 @@ grandfather_pb_test(dns_name_t *zone_name, dns_rdataset_t  *sigrdataset)
 		}
 
 		dns_rdata_freestruct(&siginfo);
+		dns_rdata_reset(&sigrdata);
 
 	} while (dns_rdataset_next(chase_sigkeyrdataset) == ISC_R_SUCCESS);
 
@@ -4255,7 +4255,7 @@ contains_trusted_key(dns_name_t *name, dns_rdataset_t *rdataset,
 		     isc_mem_t *mctx)
 {
 	isc_result_t result;
-	dns_rdata_t rdata;
+	dns_rdata_t rdata = DNS_RDATA_INIT;
 	dst_key_t *trustedKey = NULL;
 	dst_key_t *dnsseckey = NULL;
 	int i;
@@ -4265,7 +4265,6 @@ contains_trusted_key(dns_name_t *name, dns_rdataset_t *rdataset,
 
 	result = dns_rdataset_first(rdataset);
 	check_result(result, "empty rdataset");
-	dns_rdata_init(&rdata);
 
 	do {
 		dns_rdataset_current(rdataset, &rdata);
@@ -4315,7 +4314,7 @@ sigchase_verify_sig(dns_name_t *name, dns_rdataset_t *rdataset,
 		    isc_mem_t *mctx)
 {
 	isc_result_t result;
-	dns_rdata_t keyrdata;
+	dns_rdata_t keyrdata = DNS_RDATA_INIT;
 	dst_key_t *dnsseckey = NULL;
 
 	result = dns_rdataset_first(keyrdataset);
@@ -4338,6 +4337,7 @@ sigchase_verify_sig(dns_name_t *name, dns_rdataset_t *rdataset,
 			return (ISC_R_SUCCESS);
 		}
 		dst_key_free(&dnsseckey);
+		dns_rdata_reset(&keyrdata);
 	} while (dns_rdataset_next(chase_keyrdataset) == ISC_R_SUCCESS);
 
 	dns_rdata_reset(&keyrdata);
@@ -4351,7 +4351,7 @@ sigchase_verify_sig_key(dns_name_t *name, dns_rdataset_t *rdataset,
 			isc_mem_t *mctx)
 {
 	isc_result_t result;
-	dns_rdata_t sigrdata;
+	dns_rdata_t sigrdata = DNS_RDATA_INIT;
 	dns_rdata_sig_t siginfo;
 
 	result = dns_rdataset_first(sigrdataset);
@@ -4389,6 +4389,7 @@ sigchase_verify_sig_key(dns_name_t *name, dns_rdataset_t *rdataset,
 			}
 		}
 		dns_rdata_freestruct(&siginfo);
+		dns_rdata_reset(&sigrdata);
 
 	} while (dns_rdataset_next(chase_sigkeyrdataset) == ISC_R_SUCCESS);
 
@@ -4403,25 +4404,23 @@ sigchase_verify_ds(dns_name_t *name, dns_rdataset_t *keyrdataset,
 		   dns_rdataset_t *dsrdataset, isc_mem_t *mctx)
 {
 	isc_result_t result;
-	dns_rdata_t keyrdata;
-	dns_rdata_t newdsrdata;
-	dns_rdata_t dsrdata;
+	dns_rdata_t keyrdata = DNS_RDATA_INIT;
+	dns_rdata_t newdsrdata = DNS_RDATA_INIT;
+	dns_rdata_t dsrdata = DNS_RDATA_INIT;
 	dns_rdata_ds_t dsinfo;
 	dst_key_t *dnsseckey = NULL;
 	unsigned char dsbuf[DNS_DS_BUFFERSIZE];
 
 	result = dns_rdataset_first(dsrdataset);
 	check_result(result, "empty DSset dataset");
-	dns_rdata_init(&dsrdata);
 	do {
 		dns_rdataset_current(dsrdataset, &dsrdata);
 
 		result = dns_rdata_tostruct(&dsrdata, &dsinfo, NULL);
-		check_result(result, "dns_rdata_tostruct  for DS");
+		check_result(result, "dns_rdata_tostruct for DS");
 
 		result = dns_rdataset_first(keyrdataset);
 		check_result(result, "empty KEY dataset");
-		dns_rdata_init(&keyrdata);
 
 		do {
 			dns_rdataset_current(keyrdataset, &keyrdata);
@@ -4436,7 +4435,6 @@ sigchase_verify_ds(dns_name_t *name, dns_rdataset_t *keyrdataset,
 			 * id of DNSKEY referenced by the DS
 			 */
 			if (dsinfo.key_tag == dst_key_id(dnsseckey)) {
-				dns_rdata_init(&newdsrdata);
 
 				result = dns_ds_buildrdata(name, &keyrdata,
 							   dsinfo.digest_type,
@@ -4484,14 +4482,16 @@ sigchase_verify_ds(dns_name_t *name, dns_rdataset_t *keyrdataset,
 				dns_rdata_reset(&newdsrdata);
 			}
 			dst_key_free(&dnsseckey);
+			dns_rdata_reset(&keyrdata);
 			dnsseckey = NULL;
 		} while (dns_rdataset_next(chase_keyrdataset) == ISC_R_SUCCESS);
-		dns_rdata_reset(&keyrdata);
+		dns_rdata_reset(&dsrdata);
 
 	} while (dns_rdataset_next(chase_dsrdataset) == ISC_R_SUCCESS);
-#if 0
-	dns_rdata_reset(&dsrdata); WARNING
-#endif
+
+	dns_rdata_reset(&keyrdata);
+	dns_rdata_reset(&newdsrdata);
+	dns_rdata_reset(&dsrdata);
 
 	return (ISC_R_NOTFOUND);
 }
@@ -4884,7 +4884,7 @@ getneededrr(dns_message_t *msg)
 {
 	isc_result_t result;
 	dns_name_t *name = NULL;
-	dns_rdata_t sigrdata;
+	dns_rdata_t sigrdata = DNS_RDATA_INIT;
 	dns_rdata_sig_t siginfo;
 	isc_boolean_t   true = ISC_TRUE;
 
@@ -4938,7 +4938,6 @@ getneededrr(dns_message_t *msg)
 	/* first find the DNSKEY name */
 	result = dns_rdataset_first(chase_sigrdataset);
 	check_result(result, "empty RRSIG dataset");
-	dns_rdata_init(&sigrdata);
 	dns_rdataset_current(chase_sigrdataset, &sigrdata);
 	result = dns_rdata_tostruct(&sigrdata, &siginfo, NULL);
 	check_result(result, "sigrdata tostruct siginfo");
@@ -5316,6 +5315,7 @@ prove_nx_domain(dns_message_t *msg,
 			}
 
 			dns_rdata_freestruct(&nsecstruct);
+			dns_rdata_reset(&nsec);
 		}
 	} while (dns_message_nextname(msg, DNS_SECTION_AUTHORITY)
 		 == ISC_R_SUCCESS);

bin/named/statschannel.c

@@ -14,7 +14,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: statschannel.c,v 1.2.2.13 2008/08/08 05:10:34 marka Exp $ */
+/* $Id: statschannel.c,v 1.2.2.13.2.1 2008/12/18 02:39:12 marka Exp $ */
 
 /*! \file */
 
@@ -635,7 +635,7 @@ generatexml(ns_server_t *server, int *buflen, xmlChar **buf) {
 	TRY0(xmlTextWriterStartElement(writer, ISC_XMLCHAR "bind"));
 	TRY0(xmlTextWriterStartElement(writer, ISC_XMLCHAR "statistics"));
 	TRY0(xmlTextWriterWriteAttribute(writer, ISC_XMLCHAR "version",
-					 ISC_XMLCHAR "1.0"));
+					 ISC_XMLCHAR "2.0"));
 
 	/* Set common fields for statistics dump */
 	dumparg.type = statsformat_xml;

doc/draft/draft-ietf-dnsext-forgery-resilience-02.txt

@@ -1,17 +0,0 @@
-
-This Internet-Draft, draft-ietf-dnsext-forgery-resilience-01.txt, has expired, and has been deleted 
-from the Internet-Drafts directory.  An Internet-Draft expires 185 days from 
-the date that it is posted unless it is replaced by an updated version, or the
-Secretariat has been notified that the document is under official review by the
-IESG or has been passed to the RFC Editor for review and/or publication as an 
-RFC.  This Internet-Draft was not published as an RFC.
-
-Internet-Drafts are not archival documents, and copies of Internet-Drafts that have 
-been deleted from the directory are not available.  The Secretariat does not have 
-any information regarding the future plans of the author(s) or working group, if 
-applicable, with respect to this deleted Internet-Draft.  For more information, or 
-to request a copy of the document, please contact the author(s) directly.
-
-Draft Author(s):
-Remco van Mook <remco@virtu.nl>,
-Bert Hubert <bert.hubert@netherlabs.nl>

doc/draft/draft-ietf-dnsext-rfc2671bis-edns0-01.txt

@@ -1,480 +0,0 @@
-
-
-
-
-
-
-DNSEXT Working Group                                Paul Vixie, ISC
-INTERNET-DRAFT
-<draft-ietf-dnsext-rfc2671bis-edns0-01.txt>          March 17, 2008
-
-Intended Status: Standards Track
-Obsoletes: 2671 (if approved)
-
-
-              Revised extension mechanisms for DNS (EDNS0)
-
-
-Status of this Memo
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of 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.
-
-Copyright Notice
-
-   Copyright (C) The IETF Trust (2007).
-
-
-                                 Abstract
-
-   The Domain Name System's wire protocol includes a number of fixed
-   fields whose range has been or soon will be exhausted and does not
-   allow clients to advertise their capabilities to servers.  This
-   document describes backward compatible mechanisms for allowing the
-   protocol to grow.
-
-
-
-Expires September 2008                                          [Page 1]
-
-INTERNET-DRAFT                    EDNS0                       March 2008
-
-
-1 - Introduction
-
-1.1. DNS (see [RFC1035]) specifies a Message Format and within such
-messages there are standard formats for encoding options, errors, and
-name compression.  The maximum allowable size of a DNS Message is fixed.
-Many of DNS's protocol limits are too small for uses which are or which
-are desired to become common.  There is no way for implementations to
-advertise their capabilities.
-
-1.2. Unextended agents will not know how to interpret the protocol
-extensions detailed here.  In practice, these clients will be upgraded
-when they have need of a new feature, and only new features will make
-use of the extensions.  Extended agents must be prepared for behaviour
-of unextended clients in the face of new protocol elements, and fall
-back gracefully to unextended DNS.  RFC 2671 originally has proposed
-extensions to the basic DNS protocol to overcome these deficiencies.
-This memo refines that specification and obsoletes RFC 2671.
-
-1.3. 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].
-
-2 - Affected Protocol Elements
-
-2.1. The DNS Message Header's (see [RFC1035 4.1.1]) second full 16-bit
-word is divided into a 4-bit OPCODE, a 4-bit RCODE, and a number of
-1-bit flags.  The original reserved Z bits have been allocated to
-various purposes, and most of the RCODE values are now in use.  More
-flags and more possible RCODEs are needed.  The OPT pseudo-RR specified
-in Section 4 contains subfields that carry a bit field extension of the
-RCODE field and additional flag bits, respectively; for details see
-Section 4.6 below.
-
-2.2. The first two bits of a wire format domain label are used to denote
-the type of the label.  [RFC1035 4.1.4] allocates two of the four
-possible types and reserves the other two.  Proposals for use of the
-remaining types far outnumber those available.  More label types were
-needed, and an extension mechanism was proposed in RFC 2671 [RFC2671
-Section 3].  Section 3 of this document reserves DNS labels with a first
-octet in the range of 64-127 decimal (label type 01) for future
-standardization of Extended DNS Labels.
-
-
-
-
-
-
-
-Expires September 2008                                          [Page 2]
-
-INTERNET-DRAFT                    EDNS0                       March 2008
-
-
-2.3. DNS Messages are limited to 512 octets in size when sent over UDP.
-While the minimum maximum reassembly buffer size still allows a limit of
-512 octets of UDP payload, most of the hosts now connected to the
-Internet are able to reassemble larger datagrams.  Some mechanism must
-be created to allow requestors to advertise larger buffer sizes to
-responders.  To this end, the OPT pseudo-RR specified in Section 4
-contains a maximum payload size field; for details see Section 4.5
-below.
-
-3 - Extended Label Types
-
-The first octet in the on-the-wire representation of a DNS label
-specifies the label type; the basic DNS specification [RFC1035]
-dedicates the two most significant bits of that octet for this purpose.
-
-This document reserves DNS label type 0b01 for use as an indication for
-Extended Label Types.  A specific extended label type is selected by the
-6 least significant bits of the first octet.  Thus, Extended Label Types
-are indicated by the values 64-127 (0b01xxxxxx) in the first octet of
-the label.
-
-Allocations from this range are to be made for IETF documents fully
-describing the syntax and semantics as well as the applicability of the
-particular Extended Label Type.
-
-This document does not describe any specific Extended Label Type.
-
-4 - OPT pseudo-RR
-
-4.1. One OPT pseudo-RR (RR type 41) MAY be added to the additional data
-section of a request, and to responses to such requests.  An OPT is
-called a pseudo-RR because it pertains to a particular transport level
-message and not to any actual DNS data.  OPT RRs MUST NOT be cached,
-forwarded, or stored in or loaded from master files.  The quantity of
-OPT pseudo-RRs per message MUST be either zero or one, but not greater.
-
-4.2. An OPT RR has a fixed part and a variable set of options expressed
-as {attribute, value} pairs.  The fixed part holds some DNS meta data
-and also a small collection of new protocol elements which we expect to
-be so popular that it would be a waste of wire space to encode them as
-{attribute, value} pairs.
-
-
-
-
-
-
-
-Expires September 2008                                          [Page 3]
-
-INTERNET-DRAFT                    EDNS0                       March 2008
-
-
-4.3. The fixed part of an OPT RR is structured as follows:
-
-Field Name   Field Type     Description
-------------------------------------------------------
-NAME         domain name    empty (root domain)
-TYPE         u_int16_t      OPT (41)
-CLASS        u_int16_t      sender's UDP payload size
-TTL          u_int32_t      extended RCODE and flags
-RDLEN        u_int16_t      describes RDATA
-RDATA        octet stream   {attribute,value} pairs
-
-
-4.4. The variable part of an OPT RR is encoded in its RDATA and is
-structured as zero or more of the following:
-
-      :          +0 (MSB)             :              +1 (LSB)         :
-      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-   0: |                          OPTION-CODE                          |
-      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-   2: |                         OPTION-LENGTH                         |
-      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-   4: |                                                               |
-      /                          OPTION-DATA                          /
-      /                                                               /
-      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-
-
-OPTION-CODE    (Assigned by IANA.)
-
-OPTION-LENGTH  Size (in octets) of OPTION-DATA.
-
-OPTION-DATA    Varies per OPTION-CODE.
-
-4.4.1. Order of appearance of option tuples is never relevant.  Any
-option whose meaning is affected by other options is so affected no
-matter which one comes first in the OPT RDATA.
-
-4.4.2. Any OPTION-CODE values not understood by a responder or requestor
-MUST be ignored.  So, specifications of such options might wish to
-include some kind of signalled acknowledgement.  For example, an option
-specification might say that if a responder sees option XYZ, it SHOULD
-include option XYZ in its response.
-
-
-
-
-
-
-Expires September 2008                                          [Page 4]
-
-INTERNET-DRAFT                    EDNS0                       March 2008
-
-
-4.5. The sender's UDP payload size (which OPT stores in the RR CLASS
-field) is the number of octets of the largest UDP payload that can be
-reassembled and delivered in the sender's network stack.  Note that path
-MTU, with or without fragmentation, may be smaller than this.  Values
-lower than 512 are undefined, and may be treated as format errors, or
-may be treated as equal to 512, at the implementor's discretion.
-
-4.5.1. Note that a 512-octet UDP payload requires a 576-octet IP
-reassembly buffer.  Choosing 1280 on an Ethernet connected requestor
-would be reasonable.  The consequence of choosing too large a value may
-be an ICMP message from an intermediate gateway, or even a silent drop
-of the response message.
-
-4.5.2. Both requestors and responders are advised to take account of the
-path's discovered MTU (if already known) when considering message sizes.
-
-4.5.3. The requestor's maximum payload size can change over time, and
-therefore MUST NOT be cached for use beyond the transaction in which it
-is advertised.
-
-4.5.4. The responder's maximum payload size can change over time, but
-can be reasonably expected to remain constant between two sequential
-transactions; for example, a meaningless QUERY to discover a responder's
-maximum UDP payload size, followed immediately by an UPDATE which takes
-advantage of this size.  (This is considered preferrable to the outright
-use of TCP for oversized requests, if there is any reason to suspect
-that the responder implements EDNS, and if a request will not fit in the
-default 512 payload size limit.)
-
-4.5.5. Due to transaction overhead, it is unwise to advertise an
-architectural limit as a maximum UDP payload size.  Just because your
-stack can reassemble 64KB datagrams, don't assume that you want to spend
-more than about 4KB of state memory per ongoing transaction.
-
-4.6. The extended RCODE and flags (which OPT stores in the RR TTL field)
-are structured as follows:
-
-      :          +0 (MSB)             :              +1 (LSB)         :
-      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-   0: |         EXTENDED-RCODE        |            VERSION            |
-      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-   2: | DO|                           Z                               |
-      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-
-
-
-
-
-Expires September 2008                                          [Page 5]
-
-INTERNET-DRAFT                    EDNS0                       March 2008
-
-
-EXTENDED-RCODE  Forms upper 8 bits of extended 12-bit RCODE.  Note that
-                EXTENDED-RCODE value zero (0) indicates that an
-                unextended RCODE is in use (values zero (0) through
-                fifteen (15)).
-
-VERSION         Indicates the implementation level of whoever sets it.
-                Full conformance with this specification is indicated by
-                version zero (0).  Requestors are encouraged to set this
-                to the lowest implemented level capable of expressing a
-                transaction, to minimize the responder and network load
-                of discovering the greatest common implementation level
-                between requestor and responder.  A requestor's version
-                numbering strategy should ideally be a run time
-                configuration option.
-
-                If a responder does not implement the VERSION level of
-                the request, then it answers with RCODE=BADVERS.  All
-                responses MUST be limited in format to the VERSION level
-                of the request, but the VERSION of each response MUST be
-                the highest implementation level of the responder.  In
-                this way a requestor will learn the implementation level
-                of a responder as a side effect of every response,
-                including error responses, including RCODE=BADVERS.
-
-DO              DNSSEC OK bit [RFC3225].
-
-Z               Set to zero by senders and ignored by receivers, unless
-                modified in a subsequent specification [IANAFLAGS].
-
-5 - Transport Considerations
-
-5.1. The presence of an OPT pseudo-RR in a request is an indication that
-the requestor fully implements the given version of EDNS, and can
-correctly understand any response that conforms to that feature's
-specification.
-
-5.2. Lack of use of these features in a request is an indication that
-the requestor does not implement any part of this specification and that
-the responder SHOULD NOT use any protocol extension described here in
-its response.
-
-5.3. Responders who do not understand these protocol extensions are
-expected to send a response with RCODE NOTIMPL, FORMERR, or SERVFAIL, or
-to appear to "time out" due to inappropriate action by a "middle box"
-such as a NAT, or to ignore extensions and respond only to unextended
-
-
-
-Expires September 2008                                          [Page 6]
-
-INTERNET-DRAFT                    EDNS0                       March 2008
-
-
-protocol elements.  Therefore use of extensions SHOULD be "probed" such
-that a responder who isn't known to support them be allowed a retry with
-no extensions if it responds with such an RCODE, or does not respond.
-If a responder's capability level is cached by a requestor, a new probe
-SHOULD be sent periodically to test for changes to responder capability.
-
-5.4. If EDNS is used in a request, and the response arrives with TC set
-and with no EDNS OPT RR, a requestor should assume that truncation
-prevented the OPT RR from being appended by the responder, and further,
-that EDNS is not used in the response.  Correspondingly, an EDNS
-responder who cannot fit all necessary elements (including an OPT RR)
-into a response, should respond with a normal (unextended) DNS response,
-possibly setting TC if the response will not fit in the unextended
-response message's 512-octet size.
-
-6 - Security Considerations
-
-Requestor-side specification of the maximum buffer size may open a new
-DNS denial of service attack if responders can be made to send messages
-which are too large for intermediate gateways to forward, thus leading
-to potential ICMP storms between gateways and responders.
-
-7 - IANA Considerations
-
-IANA has allocated RR type code 41 for OPT.
-
-This document controls the following IANA sub-registries in registry
-"DOMAIN NAME SYSTEM PARAMETERS":
-
-   "EDNS Extended Label Type"
-   "EDNS Option Codes"
-   "EDNS Version Numbers"
-   "Domain System Response Code"
-
-IANA is advised to re-parent these subregistries to this document.
-
-This document assigns label type 0b01xxxxxx as "EDNS Extended Label
-Type."  We request that IANA record this assignment.
-
-This document assigns option code 65535 to "Reserved for future
-expansion."
-
-This document assigns EDNS Extended RCODE "16" to "BADVERS".
-
-
-
-
-
-Expires September 2008                                          [Page 7]
-
-INTERNET-DRAFT                    EDNS0                       March 2008
-
-
-IESG approval is required to create new entries in the EDNS Extended
-Label Type or EDNS Version Number registries, while any published RFC
-(including Informational, Experimental, or BCP) is grounds for
-allocation of an EDNS Option Code.
-
-8 - Acknowledgements
-
-Paul Mockapetris, Mark Andrews, Robert Elz, Don Lewis, Bob Halley,
-Donald Eastlake, Rob Austein, Matt Crawford, Randy Bush, Thomas Narten,
-Alfred Hoenes and Markku Savela were each instrumental in creating and
-refining this specification.
-
-9 - References
-
-[RFC1035]    P. Mockapetris, "Domain Names - Implementation and
-             Specification," RFC 1035, USC/Information Sciences
-             Institute, November 1987.
-
-[RFC2119]    S. Bradner, "Key words for use in RFCs to Indicate
-             Requirement Levels," RFC 2119, Harvard University, March
-             1997.
-
-[RFC2671]    P. Vixie, "Extension mechanisms for DNS (EDNS0)," RFC 2671,
-             Internet Software Consortium, August 1999.
-
-[RFC3225]    D. Conrad, "Indicating Resolver Support of DNSSEC," RFC
-             3225, Nominum Inc., December 2001.
-
-[IANAFLAGS]  IANA, "DNS Header Flags and EDNS Header Flags," web site
-             http://www.iana.org/assignments/dns-header-flags, as of
-             June 2005 or later.
-
-10 - Author's Address
-
-Paul Vixie
-   Internet Systems Consortium
-   950 Charter Street
-   Redwood City, CA 94063
-   +1 650 423 1301
-   EMail: vixie@isc.org
-
-
-
-
-
-
-
-
-Expires September 2008                                          [Page 8]
-
-INTERNET-DRAFT                    EDNS0                       March 2008
-
-
-Full Copyright Statement
-
-Copyright (C) IETF Trust (2007).
-
-This document is subject to the rights, licenses and restrictions
-contained in BCP 78, and except as set forth therein, the authors retain
-all their rights.
-
-This document and the information contained herein are provided on an
-"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR
-IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE
-INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-The IETF takes no position regarding the validity or scope of any
-Intellectual Property Rights or other rights that might be claimed to
-pertain to the implementation or use of the technology described in this
-document or the extent to which any license under such rights might or
-might not be available; nor does it represent that it has made any
-independent effort to identify any such rights.  Information on the
-procedures with respect to rights in RFC documents can be found in BCP
-78 and BCP 79.
-
-Copies of IPR disclosures made to the IETF Secretariat and any
-assurances of licenses to be made available, or the result of an attempt
-made to obtain a general license or permission for the use of such
-proprietary rights by implementers or users of this specification can be
-obtained from the IETF on-line IPR repository at
-http://www.ietf.org/ipr.
-
-The IETF invites any interested party to bring to its attention any
-copyrights, patents or patent applications, or other proprietary rights
-that may cover technology that may be required to implement this
-standard.  Please address the information to the IETF at
-ietf-ipr@ietf.org.
-
-Acknowledgement
-
-Funding for the RFC Editor function is provided by the IETF
-Administrative Support Activity (IASA).
-
-
-
-
-Expires September 2008                                          [Page 9]
-

doc/draft/draft-ietf-dnsop-default-local-zones-05.txt

@@ -1,672 +0,0 @@
-
-
-
-Network Working Group                                         M. Andrews
-Internet-Draft                                                       ISC
-Intended status: BCP                                        June 5, 2008
-Expires: December 7, 2008
-
-
-                        Locally-served DNS Zones
-                draft-ietf-dnsop-default-local-zones-05
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of 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 December 7, 2008.
-
-Abstract
-
-   Experience has shown that there are a number of DNS zones all
-   iterative resolvers and recursive nameservers should, unless
-   configured otherwise, automatically serve.  RFC 4193 specifies that
-   this should occur for D.F.IP6.ARPA.  This document extends the
-   practice to cover the IN-ADDR.ARPA zones for RFC 1918 address space
-   and other well known zones with similar characteristics.
-
-
-
-
-
-
-
-
-
-Andrews                 Expires December 7, 2008                [Page 1]
-
-Internet-Draft          Locally-served DNS Zones               June 2008
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-     1.1.  Reserved Words . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Effects on sites using RFC 1918 addresses. . . . . . . . . . .  4
-   3.  Changes to Iterative Resolver Behaviour. . . . . . . . . . . .  4
-   4.  Lists Of Zones Covered . . . . . . . . . . . . . . . . . . . .  5
-     4.1.  RFC 1918 Zones . . . . . . . . . . . . . . . . . . . . . .  5
-     4.2.  RFC 3330 Zones . . . . . . . . . . . . . . . . . . . . . .  6
-     4.3.  Local IPv6 Unicast Addresses . . . . . . . . . . . . . . .  6
-     4.4.  IPv6 Locally Assigned Local Addresses  . . . . . . . . . .  6
-     4.5.  IPv6 Link Local Addresses  . . . . . . . . . . . . . . . .  7
-   5.  Zones that are Out-Of-Scope  . . . . . . . . . . . . . . . . .  7
-   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
-   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
-   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  8
-   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
-     9.1.  Normative References . . . . . . . . . . . . . . . . . . .  8
-     9.2.  Informative References . . . . . . . . . . . . . . . . . . 10
-   Appendix A.  Change History [To Be Removed on Publication] . . . . 10
-     A.1.  draft-ietf-dnsop-default-local-zones-05.txt  . . . . . . . 10
-     A.2.  draft-ietf-dnsop-default-local-zones-04.txt  . . . . . . . 10
-     A.3.  draft-ietf-dnsop-default-local-zones-03.txt  . . . . . . . 10
-     A.4.  draft-ietf-dnsop-default-local-zones-02.txt  . . . . . . . 10
-     A.5.  draft-ietf-dnsop-default-local-zones-01.txt  . . . . . . . 11
-     A.6.  draft-ietf-dnsop-default-local-zones-00.txt  . . . . . . . 11
-     A.7.  draft-andrews-full-service-resolvers-03.txt  . . . . . . . 11
-     A.8.  draft-andrews-full-service-resolvers-02.txt  . . . . . . . 11
-   Appendix B.  Proposed Status [To Be Removed on Publication]  . . . 11
-   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
-   Intellectual Property and Copyright Statements . . . . . . . . . . 12
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Andrews                 Expires December 7, 2008                [Page 2]
-
-Internet-Draft          Locally-served DNS Zones               June 2008
-
-
-1.  Introduction
-
-   Experience has shown that there are a number of DNS [RFC 1034] [RFC
-   1035] zones that all iterative resolvers and recursive nameservers
-   SHOULD, unless intentionally configured otherwise, automatically
-   serve.  These zones include, but are not limited to, the IN-ADDR.ARPA
-   zones for the address space allocated by [RFC 1918] and the IP6.ARPA
-   zones for locally assigned unique local IPv6 addresses, [RFC 4193].
-
-   This recommendation is made because data has shown that significant
-   leakage of queries for these name spaces is occurring, despite
-   instructions to restrict them, and because it has therefore become
-   necessary to deploy sacrificial name servers to protect the immediate
-   parent name servers for these zones from excessive, unintentional,
-   query load [AS112] [I-D.draft-ietf-dnsop-as112-ops]
-   [I-D.draft-ietf-dnsop-as112-under-attack-help-help].  There is every
-   expectation that the query load will continue to increase unless
-   steps are taken as outlined here.
-
-   Additionally, queries from clients behind badly configured firewalls
-   that allow outgoing queries for these name spaces but drop the
-   responses, put a significant load on the root servers (forward but no
-   reverse zones configured).  They also cause operational load for the
-   root server operators as they have to reply to enquiries about why
-   the root servers are "attacking" these clients.  Changing the default
-   configuration will address all these issues for the zones listed in
-   Section 4.
-
-   [RFC 4193] recommends that queries for D.F.IP6.ARPA be handled
-   locally.  This document extends the recommendation to cover the IN-
-   ADDR.ARPA zones for [RFC 1918] and other well known IN-ADDR.ARPA and
-   IP6.ARPA zones for which queries should not appear on the public
-   Internet.
-
-   It is hoped that by doing this the number of sacrificial servers
-   [AS112] will not have to be increased, and may in time be reduced.
-
-   This recommendation should also help DNS responsiveness for sites
-   which are using [RFC 1918] addresses but do not follow the last
-   paragraph in Section 3 of [RFC 1918].
-
-1.1.  Reserved Words
-
-   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].
-
-
-
-
-
-Andrews                 Expires December 7, 2008                [Page 3]
-
-Internet-Draft          Locally-served DNS Zones               June 2008
-
-
-2.  Effects on sites using RFC 1918 addresses.
-
-   For most sites using [RFC 1918] addresses, the changes here will have
-   little or no detrimental effect.  If the site does not already have
-   the reverse tree populated the only effect will be that the name
-   error responses will be generated locally rather than remotely.
-
-   For sites that do have the reverse tree populated, most will either
-   have a local copy of the zones or will be forwarding the queries to
-   servers which have local copies of the zone.  Therefore this
-   recommendation will not be relevant.
-
-   The most significant impact will be felt at sites that make use of
-   delegations for [RFC 1918] addresses and have populated these zones.
-   These sites will need to override the default configuration expressed
-   in this document to allow resolution to continue.  Typically, such
-   sites will be fully disconnected from the Internet and have their own
-   root servers for their own non-Internet DNS tree.
-
-
-3.  Changes to Iterative Resolver Behaviour.
-
-   Unless configured otherwise, an iterative resolver will now return
-   authoritatively (aa=1) name errors (RCODE=3) for queries within the
-   zones in Section 4, with the obvious exception of queries for the
-   zone name itself where SOA, NS and "no data" responses will be
-   returned as appropriate to the query type.  One common way to do this
-   is to serve empty (SOA and NS only) zones.
-
-   An implementation of this recommendation MUST provide a mechanism to
-   disable this new behaviour, and SHOULD allow this decision on a zone
-   by zone basis.
-
-   If using empty zones one SHOULD NOT use the same NS and SOA records
-   as used on the public Internet servers as that will make it harder to
-   detect the origin of the responses and thus any leakage to the public
-   Internet servers.  This document recommends that the NS record
-   defaults to the name of the zone and the SOA MNAME defaults to the
-   name of the only NS RR's target.  The SOA RNAME should default to
-   "nobody.invalid."  [RFC 2606].  Implementations SHOULD provide a
-   mechanism to set these values.  No address records need to be
-   provided for the name server.
-
-   Below is an example of a generic empty zone in master file format.
-   It will produce a negative cache TTL of 3 hours.
-
-   @ 10800 IN SOA @ nobody.invalid. 1 3600 1200 604800 10800
-   @ 10800 IN NS @
-
-
-
-Andrews                 Expires December 7, 2008                [Page 4]
-
-Internet-Draft          Locally-served DNS Zones               June 2008
-
-
-   The SOA RR is needed to support negative caching [RFC 2308] of name
-   error responses and to point clients to the primary master for DNS
-   dynamic updates.
-
-   SOA values of particular importance are the MNAME, the SOA RR's TTL
-   and the negTTL value.  Both TTL values SHOULD match.  The rest of the
-   SOA timer values MAY be chosen arbitrarily since they are not
-   intended to control any zone transfer activity.
-
-   The NS RR is needed as some UPDATE [RFC 2136] clients use NS queries
-   to discover the zone to be updated.  Having no address records for
-   the name server is expected to abort UPDATE processing in the client.
-
-
-4.  Lists Of Zones Covered
-
-   The following subsections are intended to seed the IANA registry as
-   requested in the IANA Considerations Section.  The zone name is the
-   entity to be registered.
-
-4.1.  RFC 1918 Zones
-
-   The following zones correspond to the IPv4 address space reserved in
-   [RFC 1918].
-
-                         +----------------------+
-                         | Zone                 |
-                         +----------------------+
-                         | 10.IN-ADDR.ARPA      |
-                         | 16.172.IN-ADDR.ARPA  |
-                         | 17.172.IN-ADDR.ARPA  |
-                         | 18.172.IN-ADDR.ARPA  |
-                         | 19.172.IN-ADDR.ARPA  |
-                         | 20.172.IN-ADDR.ARPA  |
-                         | 21.172.IN-ADDR.ARPA  |
-                         | 22.172.IN-ADDR.ARPA  |
-                         | 23.172.IN-ADDR.ARPA  |
-                         | 24.172.IN-ADDR.ARPA  |
-                         | 25.172.IN-ADDR.ARPA  |
-                         | 26.172.IN-ADDR.ARPA  |
-                         | 27.172.IN-ADDR.ARPA  |
-                         | 28.172.IN-ADDR.ARPA  |
-                         | 29.172.IN-ADDR.ARPA  |
-                         | 30.172.IN-ADDR.ARPA  |
-                         | 31.172.IN-ADDR.ARPA  |
-                         | 168.192.IN-ADDR.ARPA |
-                         +----------------------+
-
-
-
-
-Andrews                 Expires December 7, 2008                [Page 5]
-
-Internet-Draft          Locally-served DNS Zones               June 2008
-
-
-4.2.  RFC 3330 Zones
-
-   The following zones correspond to those address ranges from [RFC
-   3330] 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
-   1.0.0.127.IN-ADDR.ARPA locally.  In fact, a meaningful reverse
-   mapping should exist, but the exact setup is out of the scope of this
-   document.  Similar logic applies to the reverse mapping for ::1
-   (Section 4.3).  The recommendations made here simply assume no other
-   coverage for these domains exists.
-
-         +------------------------------+------------------------+
-         | Zone                         | Description            |
-         +------------------------------+------------------------+
-         | 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          |
-         | 255.255.255.255.IN-ADDR.ARPA | IPv4 BROADCAST         |
-         +------------------------------+------------------------+
-
-4.3.  Local IPv6 Unicast Addresses
-
-   The reverse mappings ([RFC 3596], Section 2.5 IP6.ARPA Domain) for
-   the IPv6 Unspecified (::) and Loopback (::1) addresses ([RFC 4291],
-   Sections 2.4, 2.5.2 and 2.5.3) are covered by these two zones:
-
-               +-------------------------------------------+
-               | Zone                                      |
-               +-------------------------------------------+
-               | 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.\ |
-               | 0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA          |
-               | 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.\ |
-               | 0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA          |
-               +-------------------------------------------+
-
-   Note: Line breaks and a escapes '\' have been inserted above for
-   readability and to adhere to line width constraints.  They are not
-   parts of the zone names.
-
-4.4.  IPv6 Locally Assigned Local Addresses
-
-   Section 4.4 of [RFC 4193] already required special treatment of:
-
-
-
-
-Andrews                 Expires December 7, 2008                [Page 6]
-
-Internet-Draft          Locally-served DNS Zones               June 2008
-
-
-                             +--------------+
-                             | Zone         |
-                             +--------------+
-                             | D.F.IP6.ARPA |
-                             +--------------+
-
-4.5.  IPv6 Link Local Addresses
-
-   IPv6 Link-Local Addresses as of [RFC 4291], Section 2.5.6 are covered
-   by four distinct reverse DNS zones:
-
-                            +----------------+
-                            | Zone           |
-                            +----------------+
-                            | 8.E.F.IP6.ARPA |
-                            | 9.E.F.IP6.ARPA |
-                            | A.E.F.IP6.ARPA |
-                            | B.E.F.IP6.ARPA |
-                            +----------------+
-
-
-5.  Zones that are Out-Of-Scope
-
-   IPv6 site-local addresses, [RFC 4291] Sections 2.4 and 2.5.7, and
-   IPv6 Non-Locally Assigned Local addresses [RFC 4193] are not covered
-   here.  It is expected that IPv6 site-local addresses will be self
-   correcting as IPv6 implementations remove support for site-local
-   addresses.  However, sacrificial servers for C.E.F.IP6.ARPA through
-   F.E.F.IP6.ARPA may still need to be deployed in the short term if the
-   traffic becomes excessive.
-
-   For IPv6 Non-Locally Assigned Local addresses (L = 0) [RFC 4193],
-   there has been no decision made about whether the Regional Internet
-   Registries (RIRs) will provide delegations in this space or not.  If
-   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.
-
-   This document also ignores IP6.INT.  IP6.INT has been wound up with
-   only legacy resolvers now generating reverse queries under IP6.INT
-   [RFC 4159].
-
-   This document has also deliberately ignored names immediately under
-   the root domain.  While there is a subset of queries to the root name
-   servers which could be addressed using the techniques described here
-   (e.g. .local, .workgroup and IPv4 addresses), there is also a vast
-   amount of traffic that requires a different strategy (e.g. lookups
-   for unqualified hostnames, IPv6 addresses).
-
-
-
-Andrews                 Expires December 7, 2008                [Page 7]
-
-Internet-Draft          Locally-served DNS Zones               June 2008
-
-
-6.  IANA Considerations
-
-   This document requests that IANA establish a registry of zones which
-   require this default behaviour.  The initial contents of which are in
-   Section 4.  Implementors are encouraged to check this registry and
-   adjust their implementations to reflect changes therein.
-
-   This registry can be amended through "IETF Consensus" as per [RFC
-   2434].
-
-   IANA should co-ordinate with the RIRs to ensure that, as DNSSEC is
-   deployed in the reverse tree, delegations for these zones are made in
-   the manner described in Section 7.
-
-
-7.  Security Considerations
-
-   During the initial deployment phase, particularly where [RFC 1918]
-   addresses are in use, there may be some clients that unexpectedly
-   receive a name error rather than a PTR record.  This may cause some
-   service disruption until their recursive name server(s) have been re-
-   configured.
-
-   As DNSSEC is deployed within the IN-ADDR.ARPA and IP6.ARPA
-   namespaces, the zones listed above will need to be delegated as
-   insecure delegations, or be within insecure zones.  This will allow
-   DNSSEC validation to succeed for queries in these spaces despite not
-   being answered from the delegated servers.
-
-   It is recommended that sites actively using these namespaces secure
-   them using DNSSEC [RFC 4035] by publishing and using DNSSEC trust
-   anchors.  This will protect the clients from accidental import of
-   unsigned responses from the Internet.
-
-
-8.  Acknowledgements
-
-   This work was supported by the US National Science Foundation
-   (research grant SCI-0427144) and DNS-OARC.
-
-
-9.  References
-
-9.1.  Normative References
-
-   [RFC 1034]
-              Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES",
-              STD 13, RFC 1034, November 1987.
-
-
-
-Andrews                 Expires December 7, 2008                [Page 8]
-
-Internet-Draft          Locally-served DNS Zones               June 2008
-
-
-   [RFC 1035]
-              Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND
-              SPECIFICATION", STD 13, RFC 1035, November 1987.
-
-   [RFC 1918]
-              Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
-              and E. Lear, "Address Allocation for Private Internets",
-              BCP 5, RFC 1918, February 1996.
-
-   [RFC 2119]
-              Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC 2136]
-              Vixie, P., Thomson, A., Rekhter, Y., and J. Bound,
-              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
-              RFC 2136, April 1997.
-
-   [RFC 2308]
-              Andrews, M., "Negative Caching of DNS Queries (DNS
-              NCACHE)", RFC 2398, March 1998.
-
-   [RFC 2434]
-              Narten, T. and H. Alvestrand, "Guidelines for Writing an
-              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
-              October 1998.
-
-   [RFC 2606]
-              Eastlake, D. and A. Panitz, "Reserved Top Level DNS
-              Names", BCP 32, RFC 2606, June 1999.
-
-   [RFC 3596]
-              Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
-              "DNS Extensions to Support IPv6", RFC 3596, October 2003.
-
-   [RFC 4035]
-              Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "Protocol Modifications for the DNS Security
-              Extensions", RFC 4035, March 2005.
-
-   [RFC 4159]
-              Huston, G., "Deprecation of "ip6.int"", BCP 109, RFC 4159,
-              August 2005.
-
-   [RFC 4193]
-              Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
-              Addresses", RFC 4193, October 2005.
-
-
-
-
-Andrews                 Expires December 7, 2008                [Page 9]
-
-Internet-Draft          Locally-served DNS Zones               June 2008
-
-
-   [RFC 4291]
-              Hinden, R. and S. Deering, "IP Version 6 Addressing
-              Architecture", RFC 4291, February 2006.
-
-9.2.  Informative References
-
-   [AS112]    "AS112 Project", <http://www.as112.net/>.
-
-   [I-D.draft-ietf-dnsop-as112-ops]
-              Abley, J. and W. Maton, "AS112 Nameserver Operations",
-              draft-ietf-dnsop-as112-ops-00 (work in progress),
-              February 2007.
-
-   [I-D.draft-ietf-dnsop-as112-under-attack-help-help]
-              Abley, J. and W. Maton, "I'm Being Attacked by
-              PRISONER.IANA.ORG!",
-              draft-ietf-dnsop-as112-under-attack-help-help-00 (work in
-              progress), February 2007.
-
-   [RFC 3330]
-              "Special-Use IPv4 Addresses", RFC 3330, September 2002.
-
-
-Appendix A.  Change History [To Be Removed on Publication]
-
-A.1.  draft-ietf-dnsop-default-local-zones-05.txt
-
-   none, expiry prevention
-
-A.2.  draft-ietf-dnsop-default-local-zones-04.txt
-
-   Centrally Assigned Local addresses -> Non-Locally Assigned Local
-   address
-
-A.3.  draft-ietf-dnsop-default-local-zones-03.txt
-
-   expanded section 4 descriptions
-
-   Added references [RFC 2136], [RFC 3596],
-   [I-D.draft-ietf-dnsop-as112-ops] and
-   [I-D.draft-ietf-dnsop-as112-under-attack-help-help].
-
-   Revised language.
-
-A.4.  draft-ietf-dnsop-default-local-zones-02.txt
-
-   RNAME now "nobody.invalid."
-
-
-
-
-Andrews                 Expires December 7, 2008               [Page 10]
-
-Internet-Draft          Locally-served DNS Zones               June 2008
-
-
-   Revised language.
-
-A.5.  draft-ietf-dnsop-default-local-zones-01.txt
-
-   Revised impact description.
-
-   Updated to reflect change in IP6.INT status.
-
-A.6.  draft-ietf-dnsop-default-local-zones-00.txt
-
-   Adopted by DNSOP.
-
-   "Author's Note" re-titled "Zones that are Out-Of-Scope"
-
-   Add note that these zone are expected to seed the IANA registry.
-
-   Title changed.
-
-A.7.  draft-andrews-full-service-resolvers-03.txt
-
-   Added "Proposed Status".
-
-A.8.  draft-andrews-full-service-resolvers-02.txt
-
-   Added 0.IN-ADDR.ARPA.
-
-
-Appendix B.  Proposed Status [To Be Removed on Publication]
-
-   This Internet-Draft is being submitted for eventual publication as an
-   RFC with a proposed status of Best Current Practice.
-
-
-Author's Address
-
-   Mark P. Andrews
-   Internet Systems Consortium
-   950 Charter Street
-   Redwood City, CA  94063
-   US
-
-   Email: Mark_Andrews@isc.org
-
-
-
-
-
-
-
-
-
-Andrews                 Expires December 7, 2008               [Page 11]
-
-Internet-Draft          Locally-served DNS Zones               June 2008
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2008).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-
-
-
-
-
-
-
-
-
-Andrews                 Expires December 7, 2008               [Page 12]
-

lib/dns/api

@@ -1,3 +1,3 @@
 LIBINTERFACE = 45
-LIBREVISION = 2
+LIBREVISION = 4
 LIBAGE = 0

lib/dns/dispatch.c

@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: dispatch.c,v 1.137.128.18 2008/09/04 00:23:59 jinmei Exp $ */
+/* $Id: dispatch.c,v 1.137.128.18.2.2 2008/12/11 00:05:30 tbox Exp $ */
 
 /*! \file */
 
@@ -2588,6 +2588,15 @@ get_udpsocket(dns_dispatchmgr_t *mgr, dns_dispatch_t *disp,
 		 * If this fails 1024 times, we then ask the kernel for
 		 * choosing one.
 		 */
+	} else {
+		/* Allow to reuse address for non-random ports. */
+		result = open_socket(sockmgr, localaddr,
+				     ISC_SOCKET_REUSEADDRESS, &sock);
+
+		if (result == ISC_R_SUCCESS)
+			*sockp = sock;
+
+		return (result);
 	}
 
 	memset(held, 0, sizeof(held));

lib/dns/openssldsa_link.c

@@ -29,7 +29,7 @@
  * IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: openssldsa_link.c,v 1.11 2007/08/28 07:20:42 tbox Exp $ */
+/* $Id: openssldsa_link.c,v 1.11.178.1 2008/12/24 00:20:59 marka Exp $ */
 
 #ifdef OPENSSL
 
@@ -146,7 +146,7 @@ openssldsa_verify(dst_context_t *dctx, const isc_region_t *sig) {
 
 	status = DSA_do_verify(digest, ISC_SHA1_DIGESTLENGTH, dsasig, dsa);
 	DSA_SIG_free(dsasig);
-	if (status == 0)
+	if (status != 1)
 		return (dst__openssl_toresult(DST_R_VERIFYFAILURE));
 
 	return (ISC_R_SUCCESS);

lib/dns/opensslrsa_link.c

@@ -17,7 +17,7 @@
 
 /*
  * Principal Author: Brian Wellington
- * $Id: opensslrsa_link.c,v 1.16 2007/06/19 23:47:16 tbox Exp $
+ * $Id: opensslrsa_link.c,v 1.16.214.1 2008/12/24 00:20:59 marka Exp $
  */
 #ifdef OPENSSL
 
@@ -247,7 +247,7 @@ opensslrsa_verify(dst_context_t *dctx, const isc_region_t *sig) {
 
 	status = RSA_verify(type, digest, digestlen, sig->base,
 			    RSA_size(rsa), rsa);
-	if (status == 0)
+	if (status != 1)
 		return (dst__openssl_toresult(DST_R_VERIFYFAILURE));
 
 	return (ISC_R_SUCCESS);

lib/dns/win32/libdns.mak

@@ -145,6 +145,7 @@ CLEAN :
 	-@erase "$(INTDIR)\gssapictx.obj"
 	-@erase "$(INTDIR)\spnego.obj"
 	-@erase "$(INTDIR)\hmac_link.obj"
+	-@erase "$(INTDIR)\iptable.obj"
 	-@erase "$(INTDIR)\journal.obj"
 	-@erase "$(INTDIR)\key.obj"
 	-@erase "$(INTDIR)\keytable.obj"
@@ -266,6 +267,7 @@ LINK32_OBJS= \
 	"$(INTDIR)\dnssec.obj" \
 	"$(INTDIR)\ds.obj" \
 	"$(INTDIR)\forward.obj" \
+	"$(INTDIR)\iptable.obj" \
 	"$(INTDIR)\journal.obj" \
 	"$(INTDIR)\keytable.obj" \
 	"$(INTDIR)\lib.obj" \
@@ -405,6 +407,8 @@ CLEAN :
 	-@erase "$(INTDIR)\spnego.sbr"
 	-@erase "$(INTDIR)\hmac_link.obj"
 	-@erase "$(INTDIR)\hmac_link.sbr"
+	-@erase "$(INTDIR)\iptable.obj"
+	-@erase "$(INTDIR)\iptable.sbr"
 	-@erase "$(INTDIR)\journal.obj"
 	-@erase "$(INTDIR)\journal.sbr"
 	-@erase "$(INTDIR)\key.obj"
@@ -575,6 +579,7 @@ BSC32_SBRS= \
 	"$(INTDIR)\dnssec.sbr" \
 	"$(INTDIR)\ds.sbr" \
 	"$(INTDIR)\forward.sbr" \
+	"$(INTDIR)\iptable.sbr" \
 	"$(INTDIR)\journal.sbr" \
 	"$(INTDIR)\keytable.sbr" \
 	"$(INTDIR)\lib.sbr" \
@@ -661,6 +666,7 @@ LINK32_OBJS= \
 	"$(INTDIR)\dnssec.obj" \
 	"$(INTDIR)\ds.obj" \
 	"$(INTDIR)\forward.obj" \
+	"$(INTDIR)\iptable.obj" \
 	"$(INTDIR)\journal.obj" \
 	"$(INTDIR)\keytable.obj" \
 	"$(INTDIR)\lib.obj" \

lib/isc/api

@@ -1,3 +1,3 @@
 LIBINTERFACE = 45
-LIBREVISION = 2
+LIBREVISION = 3
 LIBAGE = 0

lib/isc/unix/socket.c

@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: socket.c,v 1.275.10.32 2008/11/20 00:06:01 jinmei Exp $ */
+/* $Id: socket.c,v 1.275.10.32.2.1 2008/12/03 02:33:23 marka Exp $ */
 
 /*! \file */
 
@@ -2360,18 +2360,15 @@ isc_socket_detach(isc_socket_t **socketp) {
 isc_result_t
 isc_socket_close(isc_socket_t *sock) {
 	int fd;
+	isc_socketmgr_t *manager;
+	isc_sockettype_t type;
 
 	REQUIRE(VALID_SOCKET(sock));
 
 	LOCK(&sock->lock);
+
 	REQUIRE(sock->references == 1);
 	REQUIRE(sock->type != isc_sockettype_fdwatch);
-	UNLOCK(&sock->lock);
-	/*
-	 * We don't need to retain the lock hereafter, since no one else has
-	 * this socket.
-	 */
-
 	REQUIRE(sock->fd >= 0 && sock->fd < (int)sock->manager->maxsocks);
 
 	INSIST(!sock->connecting);
@@ -2383,6 +2380,8 @@ isc_socket_close(isc_socket_t *sock) {
 	INSIST(ISC_LIST_EMPTY(sock->accept_list));
 	INSIST(sock->connect_ev == NULL);
 
+	manager = sock->manager;
+	type = sock->type;
 	fd = sock->fd;
 	sock->fd = -1;
 	sock->listener = 0;
@@ -2390,8 +2389,9 @@ isc_socket_close(isc_socket_t *sock) {
 	sock->connecting = 0;
 	sock->bound = 0;
 	isc_sockaddr_any(&sock->peer_address);
+	UNLOCK(&sock->lock);
 
-	closesocket(sock->manager, sock->type, fd);
+	closesocket(manager, type, fd);
 
 	return (ISC_R_SUCCESS);
 }
@@ -3028,6 +3028,7 @@ process_fd(isc_socketmgr_t *manager, int fd, isc_boolean_t readable,
 {
 	isc_socket_t *sock;
 	isc_boolean_t unlock_sock;
+	isc_boolean_t unwatch_read = ISC_FALSE, unwatch_write = ISC_FALSE;
 	int lockid = FDLOCK_ID(fd);
 
 	/*
@@ -3043,11 +3044,10 @@ process_fd(isc_socketmgr_t *manager, int fd, isc_boolean_t readable,
 	}
 
 	sock = manager->fds[fd];
-	UNLOCK(&manager->fdlock[lockid]);
 	unlock_sock = ISC_FALSE;
 	if (readable) {
 		if (sock == NULL) {
-			(void)unwatch_fd(manager, fd, SELECT_POKE_READ);
+			unwatch_read = ISC_TRUE;
 			goto check_write;
 		}
 		unlock_sock = ISC_TRUE;
@@ -3058,13 +3058,13 @@ process_fd(isc_socketmgr_t *manager, int fd, isc_boolean_t readable,
 			else
 				dispatch_recv(sock);
 		}
-		(void)unwatch_fd(manager, fd, SELECT_POKE_READ);
+		unwatch_read = ISC_TRUE;
 	}
 check_write:
 	if (writeable) {
 		if (sock == NULL) {
-			(void)unwatch_fd(manager, fd, SELECT_POKE_WRITE);
-			return;
+			unwatch_write = ISC_TRUE;
+			goto unlock_fd;
 		}
 		if (!unlock_sock) {
 			unlock_sock = ISC_TRUE;
@@ -3076,10 +3076,18 @@ check_write:
 			else
 				dispatch_send(sock);
 		}
-		(void)unwatch_fd(manager, fd, SELECT_POKE_WRITE);
+		unwatch_write = ISC_TRUE;
 	}
 	if (unlock_sock)
 		UNLOCK(&sock->lock);
+
+ unlock_fd:
+	UNLOCK(&manager->fdlock[lockid]);
+	if (unwatch_read)
+		(void)unwatch_fd(manager, fd, SELECT_POKE_READ);
+	if (unwatch_write)
+		(void)unwatch_fd(manager, fd, SELECT_POKE_WRITE);
+
 }
 
 #ifdef USE_KQUEUE

lib/isc/win32/libisc.mak

@@ -159,6 +159,7 @@ CLEAN :
 	-@erase "$(INTDIR)\parseint.obj"
 	-@erase "$(INTDIR)\portset.obj"
 	-@erase "$(INTDIR)\quota.obj"
+	-@erase "$(INTDIR)\radix.obj"
 	-@erase "$(INTDIR)\random.obj"
 	-@erase "$(INTDIR)\ratelimiter.obj"
 	-@erase "$(INTDIR)\refcount.obj"
@@ -258,6 +259,7 @@ LINK32_OBJS= \
 	"$(INTDIR)\netscope.obj" \
 	"$(INTDIR)\ondestroy.obj" \
 	"$(INTDIR)\quota.obj" \
+	"$(INTDIR)\radix.obj" \
 	"$(INTDIR)\random.obj" \
 	"$(INTDIR)\ratelimiter.obj" \
 	"$(INTDIR)\refcount.obj" \
@@ -386,6 +388,8 @@ CLEAN :
 	-@erase "$(INTDIR)\portset.sbr"
 	-@erase "$(INTDIR)\quota.obj"
 	-@erase "$(INTDIR)\quota.sbr"
+	-@erase "$(INTDIR)\radix.obj"
+	-@erase "$(INTDIR)\radix.sbr"
 	-@erase "$(INTDIR)\random.obj"
 	-@erase "$(INTDIR)\random.sbr"
 	-@erase "$(INTDIR)\ratelimiter.obj"
@@ -509,6 +513,7 @@ BSC32_SBRS= \
 	"$(INTDIR)\netscope.sbr" \
 	"$(INTDIR)\ondestroy.sbr" \
 	"$(INTDIR)\quota.sbr" \
+	"$(INTDIR)\radix.sbr" \
 	"$(INTDIR)\random.sbr" \
 	"$(INTDIR)\ratelimiter.sbr" \
 	"$(INTDIR)\refcount.sbr" \
@@ -591,6 +596,7 @@ LINK32_OBJS= \
 	"$(INTDIR)\netscope.obj" \
 	"$(INTDIR)\ondestroy.obj" \
 	"$(INTDIR)\quota.obj" \
+	"$(INTDIR)\radix.obj" \
 	"$(INTDIR)\random.obj" \
 	"$(INTDIR)\ratelimiter.obj" \
 	"$(INTDIR)\refcount.obj" \
@@ -1362,6 +1368,24 @@ SOURCE=..\inet_pton.c
 	$(CPP) $(CPP_PROJ) $(SOURCE)
 
 
+!ENDIF 
+
+SOURCE=..\iterated_hash.c
+
+!IF  "$(CFG)" == "libisc - Win32 Release"
+
+
+"$(INTDIR)\iterated_hash.obj" : $(SOURCE) "$(INTDIR)"
+	$(CPP) $(CPP_PROJ) $(SOURCE)
+
+
+!ELSEIF  "$(CFG)" == "libisc - Win32 Debug"
+
+
+"$(INTDIR)\iterated_hash.obj"	"$(INTDIR)\iterated_hash.sbr" : $(SOURCE) "$(INTDIR)"
+	$(CPP) $(CPP_PROJ) $(SOURCE)
+
+
 !ENDIF 
 
 SOURCE=..\lex.c

util/copyrights

@@ -2030,7 +2030,7 @@
 ./lib/dns/win32/libdns.def			X	2001,2002,2003,2004,2005,2006,2007,2008
 ./lib/dns/win32/libdns.dsp			X	2001,2002,2003,2004,2005,2006,2007,2008
 ./lib/dns/win32/libdns.dsw			X	2001
-./lib/dns/win32/libdns.mak			X	2001,2002,2003,2004,2005,2006,2007
+./lib/dns/win32/libdns.mak			X	2001,2002,2003,2004,2005,2006,2007,2008
 ./lib/dns/win32/version.c			C	1998,1999,2000,2001,2004,2007
 ./lib/dns/xfrin.c				C	1999,2000,2001,2002,2003,2004,2005,2006,2007,2008
 ./lib/dns/zone.c				C	1999,2000,2001,2002,2003,2004,2005,2006,2007,2008

version

@@ -1,4 +1,4 @@
-# $Id: version,v 1.39.18.9 2008/11/16 21:59:04 marka Exp $
+# $Id: version,v 1.39.18.9.2.3 2008/12/24 00:20:59 marka Exp $
 # 
 # This file must follow /bin/sh rules.  It is imported directly via
 # configure.
@@ -6,5 +6,5 @@
 MAJORVER=9
 MINORVER=5
 PATCHVER=1
-RELEASETYPE=rc
+RELEASETYPE=-P
 RELEASEVER=1