9.4-ESV-R2

update
2876. [bug] Named could return SERVFAIL for negative responses
2010-05-10 01:56:40 +00:00 · 2010-04-21 05:15:57 +00:00 · 2010-04-21 04:23:47 +00:00 · 2010-04-21 02:16:31 +00:00 · 2010-04-21 01:23:27 +00:00 · 2010-04-21 00:42:59 +00:00
13 changed files with 2388 additions and 1035 deletions
--- a/5
+++ b/5
@@ -1,3 +1,8 @@
+	--- 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]
--- a/doc/draft/draft-ietf-behave-address-format-07.txt
+++ b/doc/draft/draft-ietf-behave-address-format-07.txt
--- a/doc/draft/draft-ietf-behave-dns64-09.txt
+++ b/doc/draft/draft-ietf-behave-dns64-09.txt
--- a/doc/draft/draft-ietf-dnsext-axfr-clarify-14.txt
+++ b/doc/draft/draft-ietf-dnsext-axfr-clarify-14.txt
@@ -2,22 +2,23 @@



-
 DNS Extensions Working Group                                Edward Lewis
 Internet-Draft                                             NeuStar, Inc.
 Updates: 1034, 1035 (if approved)                         A. Hoenes, Ed.
 Intended status: Standards Track                                  TR-Sys
-Expires: July 18, 2010                                  January 18, 2010
+Expires: September 26, 2010                               March 26, 2010


                    DNS Zone Transfer Protocol (AXFR)
-                    draft-ietf-dnsext-axfr-clarify-13
+                    draft-ietf-dnsext-axfr-clarify-14

 Abstract

-   The Domain Name System standard mechanisms for maintaining coherent
-   servers for a zone consist of three elements.  One mechanism is the
-   Authoritative Transfer (AXFR) defined in RFC 1034 and RFC 1035.
+   The standard means within the Domain Name System protocol for
+   maintaining coherence among a zone's authoritative name servers
+   consists of three mechanisms.  Authoritative Transfer (AXFR) is one
+   of the mechanisms and is defined in RFC 1034 and RFC 1035.
+
   The definition of AXFR has proven insufficient in detail, thereby
   forcing implementations intended to be compliant to make assumptions,
   impeding interoperability.  Yet today we have a satisfactory set of
@@ -28,7 +29,7 @@ Abstract
 Status of this Memo

   This Internet-Draft is submitted in full conformance with the
-   provisions of BCP 78 and BCP 79. This document may contain material
+   provisions of BCP 78 and BCP 79.  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
@@ -54,16 +55,15 @@ Status of this Memo
   http://www.ietf.org/1id-abstracts.html


-
-Lewis & Hoenes            Expires July 18, 2010                 [Page 1]
+Lewis & Hoenes         Expires September 26, 2010               [Page 1]

-Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010


   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

-   This Internet-Draft will expire on July 18, 2010.
+   This Internet-Draft will expire on September 26, 2010.

 Copyright Notice

@@ -111,9 +111,9 @@ Copyright Notice



-Lewis & Hoenes            Expires July 18, 2010                 [Page 2]
+Lewis & Hoenes         Expires September 26, 2010               [Page 2]

-Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010


 Table of Contents
@@ -157,9 +157,9 @@ Table of Contents
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . 25
   10.  Internationalization Considerations . . . . . . . . . . . . 25
   11.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 25
-   12.  References  . . . . . . . . . . . . . . . . . . . . . . . . 25
+   12.  References  . . . . . . . . . . . . . . . . . . . . . . . . 26
   12.1.  Normative References  . ..  . . . . . . . . . . . . . . . 26
-   12.2.  Informative References  . . . . . . . . . . . . . . . . . 27
+   12.2.  Informative References  . . . . . . . . . . . . . . . . . 28
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28


@@ -167,9 +167,9 @@ Table of Contents



-Lewis & Hoenes            Expires July 18, 2010                 [Page 3]
+Lewis & Hoenes         Expires September 26, 2010               [Page 3]

-Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010


 1.  Introduction
@@ -223,9 +223,9 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
   data stored in relational databases (as opposed to master files),


-Lewis & Hoenes            Expires July 18, 2010                 [Page 4]
+Lewis & Hoenes         Expires September 26, 2010               [Page 4]

-Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010


   relying on the database's non-DNS means to synchronize the database
@@ -279,9 +279,9 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
   AXFR.


-Lewis & Hoenes            Expires July 18, 2010                 [Page 5]
+Lewis & Hoenes         Expires September 26, 2010               [Page 5]

-Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010


   This document will update the specification of AXFR.  To this end, it
@@ -291,7 +291,8 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
   4.2.2 of RFC 1035.  Furthermore, it discusses backward compatibility
   issues and provides policy/management considerations as well as
   specific Security Considerations for AXFR.  The goal of this document
-   is to define AXFR as it exists, or is supposed to exist, currently.
+   is to define AXFR as it is understood by the DNS community to exist
+   today.



@@ -334,10 +335,9 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010



-
-Lewis & Hoenes            Expires July 18, 2010                 [Page 6]
+Lewis & Hoenes         Expires September 26, 2010               [Page 6]

-Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010


 2.  AXFR Messages
@@ -385,15 +385,15 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
   -  "Clarifications and Implementation Notes for DNSSECbis" [DNSSEC-U]

   These documents contain information about the syntax and semantics of
-   DNS messages.  They ought not interfere with AXFR but are also
-   helpful in understanding what will be carried via AXFR.
+   DNS messages.  They do not interfere with AXFR but are also helpful
+   in understanding what will be carried via AXFR.




-Lewis & Hoenes            Expires July 18, 2010                 [Page 7]
+Lewis & Hoenes         Expires September 26, 2010               [Page 7]

-Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010


   For convenience, the synopsis of the DNS message header from
@@ -447,9 +447,9 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010



-Lewis & Hoenes            Expires July 18, 2010                 [Page 8]
+Lewis & Hoenes         Expires September 26, 2010               [Page 8]

-Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010


 2.1.1.  Header Values
@@ -503,20 +503,20 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010



-Lewis & Hoenes            Expires July 18, 2010                 [Page 9]
+Lewis & Hoenes         Expires September 26, 2010               [Page 9]

-Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010


   d) The client MUST set this field to the number of resource records
-      it places into the Additional section.  In the absense of explicit
+      it places into the Additional section.  In the absence of explicit
      specification of new RRs to be carried in the Additional section
      of AXFR queries, the value MAY be 0, 1 or 2.  See Section 2.1.5
      "Additional Section" for details on the currently applicable RRs.

 2.1.2.  Question Section

-   The Question Section of the AXFR query MUST conform to Section 4.1.2
+   The Question section of the AXFR query MUST conform to Section 4.1.2
   of RFC 1035, and contain a single resource record with the following
   values:

@@ -543,25 +543,25 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
   carried in the Additional section of normal DNS transactions need to
   explicitly describe their use with AXFR, should that be desired.

-   The client MAY include one EDNS0 OPT [RFC2671] resource record.  If
+   The client MAY include one OPT resource record [RFC2671].  If
   the server does not support EDNS0, the client MUST send this section
-   without an EDNS0 OPT resource record if there is a retry.  However,
+   without an OPT resource record if there is a retry.  However,
   the protocol does not define an explicit indication that the server
   does not support EDNS0; that needs to be inferred by the client.
   Often, the server will return a FormErr(1) which might be related to
   the OPT resource record.  Note that, at the time of this writing,
-   only the EXTENDED-RCODE field of the EDNS0 OPT RR is meaningful in
-   the context of AXFR; future specifications of EDNS0 flags and/or
-   EDNS0 options must describe their usage in the context of AXFR, if
+   only the EXTENDED-RCODE field of the OPT RR is meaningful in
+   the context of AXFR; future specifications of EDNS flags and/or
+   EDNS options must describe their usage in the context of AXFR, if
   applicable.

   The client MAY include one transaction integrity and authentication
   resource record, currently a choice of TSIG [RFC2845] or SIG(0)


-Lewis & Hoenes            Expires July 18, 2010                [Page 10]
+Lewis & Hoenes         Expires September 26, 2010              [Page 10]

-Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010


   [RFC2931].  If the server has indicated that it does not recognize
@@ -578,7 +578,7 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010

   The range of permissible resource records that MAY appear in the
   Additional section might change over time.  If either a change to an
-   existing resource record (like the OPT RR for EDNS0) is made or a new
+   existing resource record (like the OPT RR for EDNS) is made or a new
   Additional section record is created, the new definitions ought to
   include a discussion on the applicability and impact upon AXFR.
   Future resource records residing in the Additional section might have
@@ -615,9 +615,9 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
   AXFR clients MUST ignore any duplicate RRs received.


-Lewis & Hoenes            Expires July 18, 2010                [Page 11]
+Lewis & Hoenes         Expires September 26, 2010              [Page 11]

-Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010


   Each AXFR response message SHOULD contain a sufficient number of RRs
@@ -671,9 +671,9 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
      NSCOUNT     MUST be 0


-Lewis & Hoenes            Expires July 18, 2010                [Page 12]
+Lewis & Hoenes         Expires September 26, 2010              [Page 12]

-Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010


      ARCOUNT     See Note g)
@@ -721,15 +721,15 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
      (Reminder, consult the appropriate IANA registry [DNSVALS].)  If a
      client receives any other value in response, it MUST act according
      to the error.  For example, a malformed AXFR query or the presence
-      of an EDNS0 OPT resource record sent to an old server will result
+      of an OPT resource record sent to an old server will result
      in a FormErr(1) value.  This value is not set as part of the AXFR-
      specific response processing.  The same is true for other values
      indicating an error.


-Lewis & Hoenes            Expires July 18, 2010                [Page 13]
+Lewis & Hoenes         Expires September 26, 2010              [Page 13]

-Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010


   f) The count of answer records MUST equal the number of resource
@@ -739,7 +739,7 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
      client's limitations via configuration data.

   g) The server MUST set this field to the number of resource records
-      it places into the Additional section.  In the absense of explicit
+      it places into the Additional section.  In the absence of explicit
      specification of new RRs to be carried in the Additional section
      of AXFR response messages, the value MAY be 0, 1 or 2.  See
      Section 2.1.5 above for details on the currently applicable RRs
@@ -766,16 +766,16 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010

 2.2.5.  Additional Section

-   The contents of this section MUST follow the guidelines for EDNS0 and
-   TSIG, SIG(0), or whatever other future record is possible here.  The
-   contents of Section 2.1.5 apply analogously as well.
+   The contents of this section MUST follow the guidelines for the OPT,
+   TSIG, and SIG(0) RRs, or whatever other future record is possible
+   here.  The contents of Section 2.1.5 apply analogously as well.

   The following considerations specifically apply to AXFR responses:

-   If the client has supplied an EDNS0 OPT RR in the AXFR query and if
-   the server supports ENDS0 as well, it SHOULD include one EDNS0 OPT RR
+   If the client has supplied an EDNS OPT RR in the AXFR query and if
+   the server supports EDNS as well, it SHOULD include one OPT RR
   in the first response message and MAY do so in subsequent response
-   messages (see Section 2.2); the specifications of EDNS0 options to be
+   messages (see Section 2.2); the specifications of EDNS options to be
   carried in the OPT RR may impose stronger requirements.

   If the client has supplied a transaction security resource record
@@ -783,9 +783,9 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
   method chosen by the client, it MUST place the corresponding resource


-Lewis & Hoenes            Expires July 18, 2010                [Page 14]
+Lewis & Hoenes         Expires September 26, 2010              [Page 14]

-Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010


   record into the AXFR response message(s), according to the rules
@@ -839,9 +839,9 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
   in Section 6 of RFC 2181.


-Lewis & Hoenes            Expires July 18, 2010                [Page 15]
+Lewis & Hoenes         Expires September 26, 2010              [Page 15]

-Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010


   Zones for which it is impractical to list the entire zone for a
@@ -895,9 +895,9 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
      single zone.


-Lewis & Hoenes            Expires July 18, 2010                [Page 16]
+Lewis & Hoenes         Expires September 26, 2010              [Page 16]

-Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010


   o  Different NSEC [RFC4034] (or NSEC3 [RFC5155]) resource records
@@ -951,9 +951,9 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
   more authoritative set, concealing the error.)


-Lewis & Hoenes            Expires July 18, 2010                [Page 17]
+Lewis & Hoenes         Expires September 26, 2010              [Page 17]

-Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010


   3) The inconsistent NS resource record set might indicate a problem
@@ -1007,9 +1007,9 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010



-Lewis & Hoenes            Expires July 18, 2010                [Page 18]
+Lewis & Hoenes         Expires September 26, 2010              [Page 18]

-Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010


   Since the primary objective of AXFR is to enable the client to serve
@@ -1063,9 +1063,9 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010



-Lewis & Hoenes            Expires July 18, 2010                [Page 19]
+Lewis & Hoenes         Expires September 26, 2010              [Page 19]

-Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010


   Therefore, the assumption that a TCP connection is dedicated to a
@@ -1091,7 +1091,7 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
   In the original definition there arguably is an implicit assumption
   (probably unintentional) that a TCP connection is used for one and
   only one AXFR session.  This is evidenced in the lack of an explicit
-   requirement to copy the Question Section and/or the message ID into
+   requirement to copy the Question section and/or the message ID into
   responses, no explicit ordering information within the AXFR response
   messages, and the lack of an explicit notice indicating that a zone
   transfer continues in the next message.
@@ -1119,9 +1119,9 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
   "apparent need".


-Lewis & Hoenes            Expires July 18, 2010                [Page 20]
+Lewis & Hoenes         Expires September 26, 2010              [Page 20]

-Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010


   An AXFR client can cancel the delivery of a zone only by closing the
@@ -1175,9 +1175,9 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
   connection broken.


-Lewis & Hoenes            Expires July 18, 2010                [Page 21]
+Lewis & Hoenes         Expires September 26, 2010              [Page 21]

-Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010


 4.2.  UDP
@@ -1231,9 +1231,9 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010



-Lewis & Hoenes            Expires July 18, 2010                [Page 22]
+Lewis & Hoenes         Expires September 26, 2010              [Page 22]

-Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010


 6.  Zone Integrity
@@ -1287,9 +1287,9 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010



-Lewis & Hoenes            Expires July 18, 2010                [Page 23]
+Lewis & Hoenes         Expires September 26, 2010              [Page 23]

-Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010


 7.  Backwards Compatibility
@@ -1343,13 +1343,19 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010



-Lewis & Hoenes            Expires July 18, 2010                [Page 24]
+Lewis & Hoenes         Expires September 26, 2010              [Page 24]

-Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010


 8.  Security Considerations

+   This document is a clarification of a mechanism outlined in RFCs 1034
+   and 1035 and as such does not add any new security considerations.
+   RFC 3833 [RFC3833] is devoted entirely to security considerations for
+   the DNS; its Section 4.3 delineates zone transfer security aspects
+   from the security threats addressed by DNSSEC.
+
   Concerns regarding authorization, traffic flooding, and message
   integrity are mentioned in "Authorization" (Section 5), "TCP"
   (Section 4.2) and "Zone Integrity" (Section 6).
@@ -1357,8 +1363,9 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010

 9.  IANA Considerations

-   [[ Note to RFC-Ed: this section may be deleted before publication. ]]
-   No new registries or new registrations are included in this document.
+   IANA has added a reference to this RFC in the AXFR (252) row of the
+   "Resource Record (RR) TYPEs" subregistry of the "Domain Name System
+   (DNS) Parameters" registry.


 10.  Internationalization Considerations
@@ -1389,6 +1396,14 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
   Edward Lewis served as a patiently listening sole document editor for
   two years.

+
+
+
+Lewis & Hoenes         Expires September 26, 2010              [Page 25]
+
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010
+
+
 12.  References

   All "RFC" references by can be obtained from the RFC Editor web site
@@ -1397,13 +1412,6 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
   information regarding this organization can be found at the following
   URL:               http://rfc-editor.org/

-
-
-Lewis & Hoenes            Expires July 18, 2010                [Page 25]
-
-Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
-
-
 12.1.  Normative References

   [BCP14]    Bradner, S., "Key words for use in RFCs to Indicate
@@ -1443,6 +1451,15 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
   [RFC2672]  Crawford, M., "Non-Terminal DNS Name Redirection",
              RFC 2672, August 1999.

+
+
+
+
+Lewis & Hoenes         Expires September 26, 2010              [Page 26]
+
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010
+
+
   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
              Wellington, "Secret Key Transaction Authentication for DNS
              (TSIG)", RFC 2845, May 2000.
@@ -1453,13 +1470,6 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
   [RFC2931]  Eastlake 3rd, D., "DNS Request and Transaction Signatures
              ( SIG(0)s )", RFC 2931, September 2000.

-
-
-Lewis & Hoenes            Expires July 18, 2010                [Page 26]
-
-Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
-
-
   [RFC3425]  Lawrence, D., "Obsoleting IQUERY", RFC 3425,
              November 2002.

@@ -1496,6 +1506,16 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
              and RRSIG Resource Records for DNSSEC", RFC 5702,
              October 2009.

+
+
+
+
+
+Lewis & Hoenes         Expires September 26, 2010              [Page 27]
+
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010
+
+
 12.2.  Informative References

   [DNSVALS]  IANA Registry "Domain Name System (DNS) Parameters",
@@ -1508,22 +1528,17 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
              Malis, "A Framework for IP Based Virtual Private
              Networks", RFC 2764, February 2000.

-
-
-
-Lewis & Hoenes            Expires July 18, 2010                [Page 27]
-
-Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
-
-
   [RFC3490]  Faltstrom, P., Hoffman, P., and A. Costello,
              "Internationalizing Domain Names in Applications (IDNA)",
              RFC 3490, March 2003.

+   [RFC3833]  Atkins, D., and R. Austein, "Threat Analysis of the Domain
+              Name System (DNS)", RFC 3833, August 2004.
+
   [DNSSEC-U] Weiler, S., and D. Blacka, "Clarifications and
              Implementation Notes for DNSSECbis",
-              draft-ietf-dnsext-dnssec-bis-updates-09 (work in
-              progress), September 2009.
+              draft-ietf-dnsext-dnssec-bis-updates-10 (work in
+              progress), March 2010.


 Authors' Addresses
@@ -1552,20 +1567,5 @@ Editorial Note: Discussion  [[ to be removed by RFC-Editor ]]



-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lewis & Hoenes            Expires July 18, 2010                [Page 28]
+Lewis & Hoenes         Expires September 26, 2010              [Page 28]

--- a/doc/draft/draft-ietf-dnsext-dns-tcp-requirements-03.txt
+++ b/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]

--- a/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-10.txt
+++ b/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-10.txt
@@ -5,12 +5,18 @@ 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                           March 8, 2010
+Expires: September 9, 2010


         Clarifications and Implementation Notes for DNSSECbis
-                draft-ietf-dnsext-dnssec-bis-updates-09
+                draft-ietf-dnsext-dnssec-bis-updates-10
+
+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

@@ -33,32 +39,30 @@ 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 March 9, 2010.
+   This Internet-Draft will expire on September 9, 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
-   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



-Weiler & Blacka           Expires March 9, 2010                 [Page 1]
+Weiler & Blacka         Expires September 9, 2010               [Page 1]

-Internet-Draft       DNSSECbis Implementation Notes       September 2009
+Internet-Draft       DNSSECbis Implementation Notes           March 2010


-   DNSSECbis document set.  It is meant to serve as a resource to
-   implementors as well as a repository of DNSSECbis errata.
+   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
@@ -68,56 +72,54 @@ Table of Contents
     1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Important Additions to DNSSSECbis  . . . . . . . . . . . . . .  3
     2.1.  NSEC3 Support  . . . . . . . . . . . . . . . . . . . . . .  3
-     2.2.  SHA-256 Support  . . . . . . . . . . . . . . . . . . . . .  3
+     2.2.  SHA-256 Support  . . . . . . . . . . . . . . . . . . . . .  4
   3.  Security Concerns  . . . . . . . . . . . . . . . . . . . . . .  4
     3.1.  Clarifications on Non-Existence Proofs . . . . . . . . . .  4
-     3.2.  Validating Responses to an ANY Query . . . . . . . . . . .  4
+     3.2.  Validating Responses to an ANY Query . . . . . . . . . . .  5
     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.2.  Unknown DS Message Digest Algorithms . . . . . . . . . . .  6
     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
+     4.7.  Setting the AD Bit on Queries  . . . . . . . . . . . . . .  8
+     4.8.  Setting the AD Bit on Replies  . . . . . . . . . . . . . .  8
+     4.9.  Setting the CD bit on Requests . . . . . . . . . . . . . .  8
+     4.10. Nested Trust Anchors . . . . . . . . . . . . . . . . . . .  8
+       4.10.1.  Closest Encloser  . . . . . . . . . . . . . . . . . .  9
+       4.10.2.  Accept Any Success  . . . . . . . . . . . . . . . . .  9
+       4.10.3.  Preference Based on Source  . . . . . . . . . . . . . 10
+   5.  Minor Corrections and Clarifications . . . . . . . . . . . . . 10
+     5.1.  Finding Zone Cuts  . . . . . . . . . . . . . . . . . . . . 10
+     5.2.  Clarifications on DNSKEY Usage . . . . . . . . . . . . . . 10
+     5.3.  Errors in Examples . . . . . . . . . . . . . . . . . . . . 11
+     5.4.  Errors in RFC 5155 . . . . . . . . . . . . . . . . . . . . 11
+   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
+   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
+   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
+     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
+     8.2.  Informative References . . . . . . . . . . . . . . . . . . 13
+   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 13
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14




-
-
-
-
-
-
-
-
-Weiler & Blacka           Expires March 9, 2010                 [Page 2]
+Weiler & Blacka         Expires September 9, 2010               [Page 2]

-Internet-Draft       DNSSECbis Implementation Notes       September 2009
+Internet-Draft       DNSSECbis Implementation Notes           March 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,24 +157,30 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009
   [RFC5155] should be considered part of the DNS Security Document
   Family as described by [RFC4033], Section 10.

+   Note that the algorithm identifiers defined in RFC5155 (DSA-NSEC3-
+   SHA1 and RSASHA1-NSEC3-SHA1) signal that a zone MAY be using NSEC3,
+   rather than NSEC.  The zone MAY indeed be using either and validators
+   supporting these algorithms MUST support both NSEC3 and NSEC
+
+
+
+Weiler & Blacka         Expires September 9, 2010               [Page 3]
+
+Internet-Draft       DNSSECbis Implementation Notes           March 2010
+
+
+   responses.
+
 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.
+   [RFC4509] describes the use of SHA-256 as a digest algorithm in
+   Delegation Signer (DS) RRs.  [RFC5702] describes the use of the
+   RSASHA256 algorithm in DNSKEY and RRSIG RRs.  Validator
+   implementations are strongly encouraged to include support for this
+   algorithm for DS, DNSKEY, and RRSIG records.

-
-
-Weiler & Blacka           Expires March 9, 2010                 [Page 3]
-
-Internet-Draft       DNSSECbis Implementation Notes       September 2009
-
-
-   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.
+   Both [RFC4509] and [RFC5702] should also be considered part of the
+   DNS Security Document Family as described by [RFC4033], Section 10.


 3.  Security Concerns
@@ -205,6 +214,17 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009
   to assume the non-existence of any subdomain of that NSEC/NSEC3 RR's
   (original) owner name.

+
+
+
+
+
+
+Weiler & Blacka         Expires September 9, 2010               [Page 4]
+
+Internet-Draft       DNSSECbis Implementation Notes           March 2010
+
+
 3.2.  Validating Responses to an ANY Query

   [RFC4035] does not address how to validate responses when QTYPE=*.
@@ -217,14 +237,6 @@ 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=*.
@@ -261,6 +273,14 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009
   [RFC4034] Section 6.2 item 3 has a list of resource record types for
   which DNS names in the RDATA are downcased for purposes of DNSSEC
   canonical form (for both ordering and signing).  That list
+
+
+
+Weiler & Blacka         Expires September 9, 2010               [Page 5]
+
+Internet-Draft       DNSSECbis Implementation Notes           March 2010
+
+
   erroneously contains NSEC and RRSIG.  According to [RFC3755], DNS
   names in the RDATA of NSEC and RRSIG should not be downcased.

@@ -273,14 +293,6 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009
   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
@@ -317,6 +329,14 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009
   If no private algorithms appear in the DS set or if any supported
   algorithm appears in the DS set, no special processing will be
   needed.  In the remaining cases, the security status of the zone
+
+
+
+Weiler & Blacka         Expires September 9, 2010               [Page 6]
+
+Internet-Draft       DNSSECbis Implementation Notes           March 2010
+
+
   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
@@ -329,14 +349,6 @@ 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
@@ -369,14 +381,27 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009

 4.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
+
+
+
+Weiler & Blacka         Expires September 9, 2010               [Page 7]
+
+Internet-Draft       DNSSECbis Implementation Notes           March 2010
+
+
+4.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.
+
+4.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 +410,29 @@ 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.

+4.9.  Setting the CD bit on Requests

+   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.

-Weiler & Blacka           Expires March 9, 2010                 [Page 7]
-
-Internet-Draft       DNSSECbis Implementation Notes       September 2009
+   For efficiency, a validator may wish to set the CD bit on all
+   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).

-
-   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
+4.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,13 +441,95 @@ 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.

-   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.
+
+
+Weiler & Blacka         Expires September 9, 2010               [Page 8]
+
+Internet-Draft       DNSSECbis Implementation Notes           March 2010
+
+
+   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 4.10.2 while exposing other policies as
+   configuration options.
+
+4.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.
+
+4.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.
+
+   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
+
+
+
+Weiler & Blacka         Expires September 9, 2010               [Page 9]
+
+Internet-Draft       DNSSECbis Implementation Notes           March 2010
+
+
+   perpetuity.
+
+4.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.


 5.  Minor Corrections and Clarifications
@@ -438,23 +547,20 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009
   does not already have the parent's NS RRset.  Section 4.2 of
   [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

   Questions of the form "can I use a different DNSKEY for signing this
   RRset" have occasionally arisen.

   The short answer is "yes, absolutely".  You can even use a different
+
+
+
+Weiler & Blacka         Expires September 9, 2010              [Page 10]
+
+Internet-Draft       DNSSECbis Implementation Notes           March 2010
+
+
   DNSKEY for each RRset in a zone, subject only to practical limits on
   the size of the DNSKEY RRset.  However, be aware that there is no way
   to tell resolvers what a particularly DNSKEY is supposed to be used
@@ -498,18 +604,19 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009

   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
   or more of the preceding element.  This means that there must be at
   least one window block.  If this window block has no types, it
+
+
+
+Weiler & Blacka         Expires September 9, 2010              [Page 11]
+
+Internet-Draft       DNSSECbis Implementation Notes           March 2010
+
+
   contradicts with the first statement.  Therefore, the correct text in
   RFC 5155 3.2.1 should be:

@@ -538,29 +645,19 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009

 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.
-
   [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]
-
-Internet-Draft       DNSSECbis Implementation Notes       September 2009
-
-
   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Resource Records for the DNS Security Extensions",
              RFC 4034, March 2005.
@@ -569,6 +666,13 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009
              Rose, "Protocol Modifications for the DNS Security
              Extensions", RFC 4035, March 2005.

+
+
+Weiler & Blacka         Expires September 9, 2010              [Page 12]
+
+Internet-Draft       DNSSECbis Implementation Notes           March 2010
+
+
   [RFC4509]  Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
              (DS) Resource Records (RRs)", RFC 4509, May 2006.

@@ -576,6 +680,10 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009
              Security (DNSSEC) Hashed Authenticated Denial 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.
+
 8.2.  Informative References

   [RFC3755]  Weiler, S., "Legacy Resolver Compatibility for Delegation
@@ -587,6 +695,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

@@ -607,22 +721,22 @@ Appendix A.  Acknowledgments
   contributed text for Section 4.5.

   The bug relating to delegation NSEC RR's in Section 3.1 was found by
-   Roy Badami.  Roy Arends found the related problem with DNAME.



-
-Weiler & Blacka           Expires March 9, 2010                [Page 11]
+Weiler & Blacka         Expires September 9, 2010              [Page 13]

-Internet-Draft       DNSSECbis Implementation Notes       September 2009
+Internet-Draft       DNSSECbis Implementation Notes           March 2010


+   Roy Badami.  Roy Arends found the related problem with DNAME.
+
   The errors in the [RFC4035] examples were found by Roy Arends, who
   also contributed text for Section 5.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, and Scott Rose for their
+   substantive comments on the text of this document.


 Authors' Addresses
@@ -666,7 +780,6 @@ Authors' Addresses



-
-
-Weiler & Blacka           Expires March 9, 2010                [Page 12]
+Weiler & Blacka         Expires September 9, 2010              [Page 14]

+
--- a/doc/draft/draft-ietf-dnsext-dnssec-gost-07.txt
+++ b/doc/draft/draft-ietf-dnsext-dnssec-gost-07.txt
@@ -1,12 +1,12 @@
 DNS Extensions working group                             V.Dolmatov, Ed.  
 Internet-Draft                                            Cryptocom Ltd.    
-Intended status: Standards Track                      December 12, 2009
-Expires: June 12, 2010                                 
+Intended status: Standards Track                         March 06, 2010
+Expires: September 06, 2010                                 


 Use of GOST signature algorithms in DNSKEY and RRSIG Resource Records
                               for DNSSEC
-                 draft-ietf-dnsext-dnssec-gost-06
+                 draft-ietf-dnsext-dnssec-gost-07

 Status of this Memo

@@ -29,7 +29,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 June 12 2010.
+   This Internet-Draft will expire on September 06 2010.

 Copyright Notice

@@ -37,19 +37,23 @@ Copyright Notice
   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.
+   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.

 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 June 12, 2010               [Page 1]
+   This document describes how to produce signature and hash using
+   GOST (R 34.10-2001, R 34.11-94) algorithms foor DNSKEY, RRSIG and DS
+   resource records for use in the Domain Name System Security
+   Extensions (DNSSEC). 
+   
+V.Dolmatov              Expires September 06, 2010            [Page 1]

 Table of Contents

@@ -98,7 +102,8 @@ Table of Contents

   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. 
+   GOST R 34.10-2001[DRAFT1], GOST R 34.11-94[DRAFT2], 
+   GOST 28147-89[DRAFT3].
   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.

@@ -106,7 +111,7 @@ Table of Contents
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

-V.Dolmatov              Expires June 12, 2010                [Page 2]
+V.Dolmatov              Expires September 06, 2010             [Page 2]

 2.  DNSKEY Resource Records

@@ -155,12 +160,12 @@ V.Dolmatov              Expires June 12, 2010                [Page 2]
   private key file it must be in one line):

   Private-key-format: v1.2
-   Algorithm: {TBA1} (GOST)
+   Algorithm: {TBA1} (ECC-GOST)
   GostAsn1: MEUCAQAwHAYGKoUDAgITMBIGByqFAwICIwEGByqFAwICHgEEIgQgp9c
             t2LQaNS1vMKPLEN9zHYjLPNMIQN6QB9vt3AghZFA=
 

-V.Dolmatov              Expires June 12, 2010                [Page 3]
+V.Dolmatov              Expires September 06, 2010             [Page 3]

   The following DNSKEY RR stores a DNS zone key for example.net
 
@@ -215,11 +220,11 @@ V.Dolmatov              Expires June 12, 2010                [Page 3]
                                  Vy466khKuWEUoVvSkqI+9tvMQySQgZcEmS0W
                                  HRFSm0XS5YST5g== )
 
-V.Dolmatov              Expires June 12, 2010                [Page 4]
+V.Dolmatov              Expires September 06, 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.
+  Note: Several ECC-GOST signatures calculated for the same message text 
+  will differ because of using of a random element is used in signature 
+  generation process.

 4.  DS Resource Records

@@ -269,25 +274,25 @@ V.Dolmatov              Expires June 12, 2010                [Page 4]

 6.1.  Support for GOST signatures

-   DNSSEC aware implementations SHOULD be able to support RRSIG and
+   DNSSEC aware implementations MAY be able to support RRSIG and
   DNSKEY resource records created with the GOST algorithms as
   defined in this document.

-V.Dolmatov              Expires June 12, 2010                [Page 5]
+V.Dolmatov              Expires September 06, 2010             [Page 5]

 6.2.  Support for NSEC3 Denial of Existence

-    Any DNSSEC-GOST implementation is required to have either NSEC or
-    NSEC3 support.
+    Any DNSSEC-GOST implementation MUST support both NSEC[RFC4035] and
+    NSEC3 [RFC5155]

 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.
+    cryptographic libraries are returning GOST blobs without 
+    transformation from 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

@@ -307,12 +312,12 @@ V.Dolmatov              Expires June 12, 2010                [Page 5]
 8.  IANA Considerations

   This document updates the IANA registry "DNS Security Algorithm 
-   Numbers [RFC4034]"
+   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
+   {TBA1} GOST R 34.10-2001 ECC-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
@@ -329,7 +334,7 @@ V.Dolmatov              Expires June 12, 2010                [Page 5]
   contributors to these documents are gratefully acknowledged for 
   their hard work.

-V.Dolmatov              Expires June 12, 2010                [Page 6]
+V.Dolmatov              Expires September 06, 2010             [Page 6]

   The following people provided additional feedback and text: Dmitry 
   Burkov, Jaap Akkerhuis, Olafur Gundmundsson, Jelte Jansen 
@@ -385,8 +390,11 @@ V.Dolmatov              Expires June 12, 2010                [Page 6]
             Infrastructure Certificate and CRL Profile", RFC 4491,
             May 2006. 

-V.Dolmatov              Expires June 12, 2010               [Page 7]
-
+V.Dolmatov              Expires September 06, 2010            [Page 7]
+ 
+[RFC5155] B. Laurie, G. Sisson, R. Arends and D. Blacka, "DNS 
+             Security (DNSSEC) Hashed Authenticated Denial of 
+             Existence", RFC 5155, February 2008.

 10.2.  Informative References

@@ -395,21 +403,21 @@ V.Dolmatov              Expires June 12, 2010               [Page 7]

   [DRAFT1]   Dolmatov V., Kabelev D., Ustinov I., Vyshensky S.,
              "GOST R 34.10-2001 digital signature algorithm"
-              draft-dolmatov-cryptocom-gost34102001-07, 12.12.09
+              draft-dolmatov-cryptocom-gost34102001-08, 12.12.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-06, 12.12.09
+              draft-dolmatov-cryptocom-gost341194-07, 12.12.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-06, 12.12.09
+              draft-dolmatov-cryptocom-gost2814789-08, 12.12.09
              work in progress.

-V.Dolmatov              Expires June 12, 2010                [Page 8]
+V.Dolmatov              Expires September 06, 2010             [Page 8]


 Authors' Addresses
@@ -436,9 +444,5 @@ Moscow, 117218, Russian Federation

 EMail: igus@cryptocom.ru

-V.Dolmatov              Expires June 12, 2010                [Page 9]
-
-
-
-
+V.Dolmatov              Expires September 06, 2010             [Page 9]

--- a/doc/draft/draft-ietf-dnsext-rfc2672bis-dname-19.txt
+++ b/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]

-
--- a/doc/draft/draft-ietf-dnsop-default-local-zones-10.txt
+++ b/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]

-
--- a/doc/private/SRCID
+++ b/doc/private/SRCID
@@ -1,6 +1,6 @@
-# $Id: SRCID,v 1.17.4.42 2010/03/03 22:17:15 tbox Exp $
+# $Id: SRCID,v 1.17.4.53 2010/04/21 05:15:57 tbox Exp $
 # 
 # This file must follow /bin/sh rules.  It is imported directly via
 # configure.
 #
-SRCID="( $Date: 2010/03/03 22:17:15 $ )"
+SRCID="( $Date: 2010/04/21 05:15:57 $ )"
--- a/lib/dns/api
+++ b/lib/dns/api
@@ -1,3 +1,3 @@
 LIBINTERFACE = 38
-LIBREVISION = 0
+LIBREVISION = 1
 LIBAGE = 0
--- a/lib/dns/validator.c
+++ b/lib/dns/validator.c
@@ -15,7 +15,7 @@
 * PERFORMANCE OF THIS SOFTWARE.
 */

-/* $Id: validator.c,v 1.119.18.53 2010/02/26 23:46:37 tbox Exp $ */
+/* $Id: validator.c,v 1.119.18.54 2010/04/21 04:23:47 marka Exp $ */

 /*! \file */

@@ -2322,7 +2322,7 @@ nsecvalidate(dns_validator_t *val, isc_boolean_t resume) {
 		return (ISC_R_SUCCESS);
 	}

-	if (val->authcount == val->authfail)
+	if (val->authfail != 0 && val->authcount == val->authfail)
 		return (DNS_R_BROKENCHAIN);
 	validator_log(val, ISC_LOG_DEBUG(3),
 		      "nonexistence proof(s) not found");
--- a/4
+++ b/4
@@ -1,4 +1,4 @@
-# $Id: version,v 1.29.134.29 2010/03/04 00:25:25 marka Exp $
+# $Id: version,v 1.29.134.30 2010/05/10 01:56:40 marka Exp $
 #
 # This file must follow /bin/sh rules.  It is imported directly via
 # configure.
@@ -7,4 +7,4 @@ MAJORVER=9
 MINORVER=4
 PATCHVER=
 RELEASETYPE=-ESV
-RELEASEVER=-R1
+RELEASEVER=-R2
Author	SHA1	Message	Date
Mark Andrews	078580a74d	9.4-ESV-R2	2010-05-10 01:56:40 +00:00
Automatic Updater	34bb4bfe2c	update	2010-04-21 05:15:57 +00:00
Mark Andrews	af9bcac6c5	2876. [bug] Named could return SERVFAIL for negative responses from unsigned zones. [RT #21131]	2010-04-21 04:23:47 +00:00
Automatic Updater	0f980b0250	update	2010-04-21 02:16:31 +00:00
Automatic Updater	294d4ecf16	sync	2010-04-21 01:23:27 +00:00
cvs2git	b7d8c679b3	This commit was manufactured by cvs2git to create branch 'v9_4'.	2010-04-21 00:42:59 +00:00
Mark Andrews	7fb2b51201	new draft	2010-04-21 00:42:57 +00:00
Automatic Updater	f6034c5012	update	2010-04-21 00:21:17 +00:00
Automatic Updater	0a199807e7	update copyright notice	2010-04-20 23:51:12 +00:00
Automatic Updater	644973f327	newcopyrights	2010-04-20 23:31:42 +00:00
Automatic Updater	fe28c38a24	update	2010-04-20 20:16:49 +00:00
Rob Austein	0c23dd6c9c	Add contact information to copyright page, fix page style and numbering for copyright page and table of contents.	2010-04-20 19:16:48 +00:00
Automatic Updater	804754e626	update	2010-04-20 08:20:07 +00:00
Mark Andrews	1e9848fb2b	2874. [bug] Cache lack of EDNS support only after the server successfully responds to the query using plain DNS. [RT #20930]	2010-04-20 07:28:52 +00:00
Automatic Updater	7ac3315851	update	2010-04-20 03:21:43 +00:00
Rob Austein	b008ad3de2	Update logo	2010-04-20 02:30:06 +00:00
Automatic Updater	f603422ae3	auto update	2010-04-15 23:19:43 +00:00
Automatic Updater	71dc0e9e72	update	2010-04-14 22:16:42 +00:00
Tatuya JINMEI 神明達哉	c45d848e2a	2873. [bug] Canceling a dynamic update via the dns/client module could trigger an assertion failure. [RT #21133]	2010-04-14 22:08:47 +00:00
Automatic Updater	bf766b1599	update	2010-04-14 00:20:45 +00:00
Automatic Updater	0abd3cca60	update copyright notice	2010-04-13 23:50:58 +00:00
Automatic Updater	e77e6219d3	newcopyrights	2010-04-13 23:31:32 +00:00
Automatic Updater	ee0be9c2a0	auto update	2010-04-13 23:19:30 +00:00
Automatic Updater	73b2849f2a	update	2010-04-13 19:17:27 +00:00
Shawn Routhier	7dc38ccd52	Modify dns/client.c:dns_client_createx() to only require one of IPv6 or IPv6 rather than both. [RT #21122]	2010-04-13 19:06:48 +00:00
Automatic Updater	97118b9653	update	2010-04-10 02:27:36 +00:00
Automatic Updater	2507f39f8d	sync	2010-04-10 01:23:13 +00:00
Automatic Updater	95a5f28754	update	2010-04-10 00:20:55 +00:00
Automatic Updater	127e1bde3a	update copyright notice	2010-04-09 23:51:01 +00:00
Automatic Updater	8f1b19fb7e	newcopyrights	2010-04-09 23:31:25 +00:00
Automatic Updater	93afb677c0	update	2010-04-09 06:20:53 +00:00
Tatuya JINMEI 神明達哉	ce164dbd9c	2871. [bug] Type mismatch in mem_api.c between the definition and the header file, causing build failure with --enable-exportlib. [RT #21138] 9.8.0 and 9.7.1.	2010-04-09 06:09:35 +00:00
Automatic Updater	a821347c7f	update	2010-04-09 02:18:23 +00:00
cvs2git	bcd3f57ab4	This commit was manufactured by cvs2git to create branch 'v9_4'.	2010-04-09 02:07:32 +00:00
Mark Andrews	c854efc784	new draft	2010-04-09 02:07:30 +00:00
Automatic Updater	fdb544b336	auto update	2010-04-08 23:18:57 +00:00
Automatic Updater	33497e72d0	update	2010-04-08 00:21:15 +00:00
Automatic Updater	f15cde2b63	update copyright notice	2010-04-07 23:51:06 +00:00
Automatic Updater	2178b22c8f	newcopyrights	2010-04-07 23:31:42 +00:00
Automatic Updater	c2020d90fb	update	2010-04-07 07:28:53 +00:00
Mark Andrews	c6217b2899	s/addresses/address/	2010-04-07 07:13:09 +00:00
Mark Andrews	86077a2e87	2870. [maint] Add AAAA addresses for L.ROOT-SERVERS.NET.	2010-04-07 07:05:38 +00:00
Automatic Updater	1b88e475da	update	2010-04-02 02:16:27 +00:00
Automatic Updater	d0bcfab89f	sync	2010-04-02 01:23:19 +00:00
Automatic Updater	b254e67fd1	update	2010-04-01 14:16:45 +00:00
cvs2git	4cd8350768	This commit was manufactured by cvs2git to create branch 'v9_4'.	2010-04-01 13:32:32 +00:00
Mark Andrews	2c6198111f	new draft	2010-04-01 13:32:30 +00:00
Automatic Updater	ada2e77c0d	update	2010-04-01 02:16:31 +00:00
Automatic Updater	0b75db38ed	sync	2010-04-01 01:23:26 +00:00
Automatic Updater	35baf2aace	update	2010-03-31 04:20:53 +00:00
cvs2git	37e02c9abe	This commit was manufactured by cvs2git to create branch 'v9_4'.	2010-03-31 04:12:22 +00:00
Mark Andrews	c94f40fc0a	new draft	2010-03-31 04:12:20 +00:00
Automatic Updater	af090ae702	update	2010-03-27 02:16:23 +00:00
Automatic Updater	e098fd8eae	sync	2010-03-27 01:23:23 +00:00
Automatic Updater	8391ea7dd9	update	2010-03-26 17:16:49 +00:00
Mark Andrews	b8d036c434	2869. [bug] Fix arguments to dns_keytable_findnextkeynode() call. [RT #20877]	2010-03-26 17:12:48 +00:00
cvs2git	42e0b30356	This commit was manufactured by cvs2git to create branch 'v9_4'.	2010-03-26 16:35:09 +00:00
Mark Andrews	b1fa56e8da	new draft	2010-03-26 16:35:07 +00:00
Automatic Updater	24a27fc3e4	update	2010-03-26 02:16:26 +00:00
Automatic Updater	a6b6482e1f	sync	2010-03-26 01:23:24 +00:00
Automatic Updater	ce7c7cb24d	update	2010-03-25 22:16:44 +00:00
cvs2git	43152c0b07	This commit was manufactured by cvs2git to create branch 'v9_4'.	2010-03-25 21:48:13 +00:00
Mark Andrews	26351a2c19	new draft	2010-03-25 21:48:11 +00:00
Automatic Updater	d862c289f2	update	2010-03-24 02:16:24 +00:00
Automatic Updater	125a6afaec	sync	2010-03-24 01:23:39 +00:00
Automatic Updater	0e38f474fc	update	2010-03-23 08:21:16 +00:00
cvs2git	b448c168e6	This commit was manufactured by cvs2git to create branch 'v9_4'.	2010-03-23 08:13:44 +00:00
Mark Andrews	8d02d21009	new draft	2010-03-23 08:13:42 +00:00
Mark Andrews	b24330955a	new draft	2010-03-23 07:58:26 +00:00
Automatic Updater	e2c5a3e25b	update	2010-03-19 00:20:56 +00:00
Automatic Updater	7da0a5ddc6	update copyright notice	2010-03-18 23:50:57 +00:00
Automatic Updater	bb43709356	newcopyrights	2010-03-18 23:31:45 +00:00
Automatic Updater	8997cd5560	update	2010-03-18 14:17:17 +00:00
Mark Andrews	c4e59874fb	regen	2010-03-18 13:30:36 +00:00
Mark Andrews	003fd2f720	2868. [cleanup] Run "make clean" at the end of configure to ensure any changes made by configure are integrated. Use --with-make-clean=no to disable. [RT #20994]	2010-03-18 13:28:32 +00:00
Automatic Updater	1ef202408e	update	2010-03-17 02:16:34 +00:00
Automatic Updater	b0d55c2695	sync	2010-03-17 01:23:16 +00:00
Automatic Updater	e63dcf7530	auto update	2010-03-16 23:18:38 +00:00
Automatic Updater	daa021383a	update	2010-03-16 01:16:29 +00:00
cvs2git	477120039e	This commit was manufactured by cvs2git to create branch 'v9_4'.	2010-03-16 01:09:22 +00:00
Mark Andrews	49eadb2f98	new draft	2010-03-16 01:09:20 +00:00
Automatic Updater	873dc64585	auto update	2010-03-15 23:19:51 +00:00
Automatic Updater	8f3a7f332a	update	2010-03-13 00:21:01 +00:00
Automatic Updater	230987e819	update copyright notice	2010-03-12 23:51:11 +00:00
Automatic Updater	957a8884fb	newcopyrights	2010-03-12 23:31:28 +00:00
Automatic Updater	bf685734ec	auto update	2010-03-12 23:19:25 +00:00
Automatic Updater	d32a806351	update	2010-03-12 04:20:46 +00:00
Mark Andrews	a80d26914a	2867. [bug] Don't set GSS_C_SEQUENCE_FLAG as Windows DNS servers don't like it. [RT #20986]	2010-03-12 03:47:08 +00:00
Mark Andrews	c19f322914	2866. [bug] Windows does not like the TSIG name being compressed. [RT #20986]	2010-03-12 03:34:56 +00:00
Mark Andrews	ff9301990d	2865. [bug] memset to zero event.data. [RT #20986 ]	2010-03-12 03:22:57 +00:00
Automatic Updater	f3c46d66e3	update	2010-03-12 02:19:48 +00:00
Mark Andrews	fa2cb8d61d	2864. [bug] Direct SIG/RRSIG queries were not handled correctly. [RT #21050]	2010-03-12 01:48:35 +00:00
Automatic Updater	d24d074ee4	update	2010-03-11 05:17:45 +00:00
Mark Andrews	08fb52ec8c	2863. [port] linux: disable IPv6 PMTUD and use network minimum MTU. [RT #21056]	2010-03-11 04:43:57 +00:00
Automatic Updater	b9df4728f1	auto update	2010-03-10 23:19:27 +00:00
Automatic Updater	8da33254f4	update	2010-03-10 03:22:17 +00:00
Mark Andrews	9537e40e79	cast isc_buffer_usedlength() to (int)	2010-03-10 02:17:52 +00:00
Automatic Updater	58416c69a3	update	2010-03-10 01:16:34 +00:00
Automatic Updater	83f43b00a5	regen HEAD	2010-03-10 01:14:18 +00:00
Automatic Updater	7354bb18cf	update	2010-03-10 00:21:03 +00:00
Automatic Updater	3767befe3a	update copyright notice	2010-03-09 23:51:06 +00:00
Automatic Updater	58be84825d	newcopyrights	2010-03-09 23:31:36 +00:00
Automatic Updater	27eb2ffd3b	update	2010-03-09 04:21:01 +00:00
Mark Andrews	64c43af4f4	2862. [bug] nsupdate didn't default to the parent zone when updating DS records. [RT #20896]	2010-03-09 03:46:12 +00:00
Mark Andrews	c5259c013b	2861. [doc] dnssec-settime man pages didn't correctly document the inactivation time. [RT #21039] 2860. [bug] named-checkconf's usage was out of date. [RT #21039]	2010-03-09 03:38:18 +00:00
Automatic Updater	86004357b7	update	2010-03-09 02:16:33 +00:00
Automatic Updater	5fc3ea8558	sync	2010-03-09 01:23:32 +00:00
Automatic Updater	3f42eeb121	update	2010-03-08 23:16:45 +00:00
cvs2git	a03b4b3bee	This commit was manufactured by cvs2git to create branch 'v9_4'.	2010-03-08 22:17:05 +00:00
Mark Andrews	39158a4c93	new draft	2010-03-08 22:17:03 +00:00
Automatic Updater	2c244f981f	update	2010-03-08 01:16:27 +00:00
Mark Andrews	0a1d6361d8	new draft	2010-03-08 01:04:29 +00:00
Automatic Updater	b12035d190	auto update	2010-03-06 23:19:03 +00:00
Automatic Updater	44c5f7fe76	update	2010-03-06 06:27:34 +00:00
Mark Andrews	ce0a4906ad	spelling	2010-03-06 05:35:50 +00:00
Mark Andrews	637a4234fa	change numbers	2010-03-06 05:25:36 +00:00
Automatic Updater	a5c06c85fa	update	2010-03-05 04:21:39 +00:00
Mark Andrews	5e95cf76e4	change numbers	2010-03-05 03:36:42 +00:00
Automatic Updater	690a5f9158	update	2010-03-05 01:16:46 +00:00
Automatic Updater	6c8a888822	regen HEAD	2010-03-05 01:14:15 +00:00
Automatic Updater	5488182a69	update	2010-03-05 00:20:54 +00:00
Automatic Updater	4d42b714be	update copyright notice	2010-03-04 23:50:34 +00:00
Automatic Updater	129090f0f6	newcopyrights	2010-03-04 23:32:07 +00:00
Automatic Updater	4db00f967f	update	2010-03-04 23:17:30 +00:00
Mark Andrews	22c4126ba5	2958. [bug] When canceling validation it was possible to leak memory. [RT #20800]	2010-03-04 22:25:31 +00:00
Automatic Updater	017032bb4b	update	2010-03-04 21:17:24 +00:00
Mark Andrews	56c2c3835f	10.53.0.1 through 10.53.0.5 -> 10.53.0.1 through 10.53.0.7	2010-03-04 20:34:16 +00:00
Automatic Updater	fa291c34fb	update	2010-03-04 07:17:29 +00:00
Mark Andrews	b1003ace6f	2957. [bug] RTT estimates were not being adjusted on ICMP errors. [RT #20772]	2010-03-04 06:43:21 +00:00
Automatic Updater	d8c9997a13	update	2010-03-04 06:22:28 +00:00
Mark Andrews	92348098eb	2956. [bug] named-checkconf did not fail on a bad trusted key. [RT #20705]	2010-03-04 06:17:01 +00:00
Mark Andrews	5388178e8a	2955. [bug] The size of a memory allocation was not always properly recorded. [RT #20927]	2010-03-04 05:45:51 +00:00
Mark Andrews	d1a5fdc34a	2955. [bug] The size of a memory allocation was not always properly recorded. [RT #20927]	2010-03-04 05:29:15 +00:00
Mark Andrews	2e20dea9fc	2854. [func] nsupdate will now preserve the entered case of domain names in update requests it sends. [RT #20928]	2010-03-04 05:24:56 +00:00
Mark Andrews	13396661f4	2854. [func] dig: allow the final soa record in a axfr response to be suppressed, dig +onesoa. [RT #20929]	2010-03-04 05:18:04 +00:00
Automatic Updater	56becfac3a	update	2010-03-04 01:16:06 +00:00
Automatic Updater	ddab8bd093	auto update	2010-03-03 23:18:09 +00:00
Automatic Updater	f16199c056	update	2010-03-03 22:24:05 +00:00
Automatic Updater	b8cfef5271	newcopyrights	2010-03-03 22:14:27 +00:00
Automatic Updater	3083bd21de	update	2010-03-03 05:17:54 +00:00
Mark Andrews	6f8edd57ae	dns_resolver_*badcache	2010-03-03 05:13:53 +00:00
Mark Andrews	c76ae1723f	dns_rdataset_expire/dns_rdataset_settrust	2010-03-03 05:11:45 +00:00
Automatic Updater	ae905b0ae1	update	2010-03-01 00:20:37 +00:00