Vendor import of BIND 9.4-ESV-R2vendor/bind9/9.4-ESV-R2

12 files changed, 2349 insertions, 996 deletions

diff --git a/CHANGES b/CHANGES
index 3b209d86e48b..34c8e8243628 100644
--- a/CHANGES
+++ b/CHANGES
@@ -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]
diff --git a/doc/draft/draft-ietf-behave-address-format-07.txt b/doc/draft/draft-ietf-behave-address-format-07.txt
new file mode 100644
index 000000000000..9c35be27085c
--- /dev/null
+++ b/doc/draft/draft-ietf-behave-address-format-07.txt
@@ -0,0 +1,1009 @@
+
+
+
+Network Working Group                                             C. Bao
+Internet-Draft                         CERNET Center/Tsinghua University
+Obsoletes: 2765 (if approved)                                 C. Huitema
+Updates: 4291 (if approved)                        Microsoft Corporation
+Intended status: Standards Track                              M. Bagnulo
+Expires: October 11, 2010                                           UC3M
+                                                            M. Boucadair
+                                                          France Telecom
+                                                                   X. Li
+                                       CERNET Center/Tsinghua University
+                                                           April 9, 2010
+
+
+                IPv6 Addressing of IPv4/IPv6 Translators
+                draft-ietf-behave-address-format-07.txt
+
+Abstract
+
+   This document discusses the algorithmic translation of an IPv6
+   address to a corresponding IPv4 address, and vice versa, using only
+   statically configured information.  It defines a well-known prefix
+   for use in algorithmic translations, while allowing organizations to
+   also use network-specific prefixes when appropriate.  Algorithmic
+   translation is used in IPv4/IPv6 translators, as well as other types
+   of proxies and gateways (e.g., for DNS) used in IPv4/IPv6 scenarios.
+
+Status of this Memo
+
+   This Internet-Draft is submitted in full conformance with the
+   provisions of BCP 78 and BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF).  Note that other groups may also distribute
+   working documents as Internet-Drafts.  The list of current Internet-
+   Drafts is at http://datatracker.ietf.org/drafts/current/.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   This Internet-Draft will expire on October 11, 2010.
+
+Copyright Notice
+
+   Copyright (c) 2010 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+
+
+
+Bao, et al.             Expires October 11, 2010                [Page 1]
+
+Internet-Draft  IPv6 Addressing of IPv4/IPv6 Translators      April 2010
+
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+     1.1.  Applicability Scope  . . . . . . . . . . . . . . . . . . .  3
+     1.2.  Conventions  . . . . . . . . . . . . . . . . . . . . . . .  3
+     1.3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
+   2.  IPv4-Embedded IPv6 Address Prefix and Format . . . . . . . . .  4
+     2.1.  Well Known Prefix  . . . . . . . . . . . . . . . . . . . .  4
+     2.2.  IPv4-Embedded IPv6 Address Format  . . . . . . . . . . . .  4
+     2.3.  Address Translation Algorithms . . . . . . . . . . . . . .  6
+     2.4.  Text Representation  . . . . . . . . . . . . . . . . . . .  6
+   3.  Deployment Guidelines and Choices  . . . . . . . . . . . . . .  7
+     3.1.  Restrictions on the use of the Well-Known Prefix . . . . .  7
+     3.2.  Impact on Inter-Domain Routing . . . . . . . . . . . . . .  8
+     3.3.  Choice of Prefix for Stateless Translation Deployments . .  8
+     3.4.  Choice of Prefix for Stateful Translation Deployments  . . 11
+     3.5.  Choice of Suffix . . . . . . . . . . . . . . . . . . . . . 11
+     3.6.  Choice of the Well-Known Prefix  . . . . . . . . . . . . . 12
+   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
+     4.1.  Protection Against Spoofing  . . . . . . . . . . . . . . . 13
+     4.2.  Secure Configuration . . . . . . . . . . . . . . . . . . . 14
+   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
+   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
+   7.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14
+   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
+     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 16
+     8.2.  Informative References . . . . . . . . . . . . . . . . . . 16
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
+
+
+
+
+
+
+
+
+
+
+
+
+Bao, et al.             Expires October 11, 2010                [Page 2]
+
+Internet-Draft  IPv6 Addressing of IPv4/IPv6 Translators      April 2010
+
+
+1.  Introduction
+
+   This document is part of a series of IPv4/IPv6 translation documents.
+   A framework for IPv4/IPv6 translation is discussed in
+   [I-D.ietf-behave-v6v4-framework], including a taxonomy of scenarios
+   that will be used in this document.  Other documents specify the
+   behavior of various types of translators and gateways, including
+   mechanisms for translating between IP headers and other types of
+   messages that include IP addresses.  This document specifies how an
+   individual IPv6 address is translated to a corresponding IPv4
+   address, and vice versa, in cases where an algorithmic mapping is
+   used.  While specific types of devices are used herein as examples,
+   it is the responsibility of the specification of such devices to
+   reference this document for algorithmic mapping of the addresses
+   themselves.
+
+   Section 2 describes the prefixes and the format of "IPv4-Embedded
+   IPv6 addresses", i.e., IPv6 addresses in which 32 bits contain an
+   IPv4 address.  This format is common to both "IPv4-Converted" and
+   "IPv4-Translatable" IPv6 addresses.  This section also defines the
+   algorithms for translating addresses, and the text representation of
+   IPv4-Embedded IPv6 addresses.
+
+   Section 3 discusses the choice of prefixes, the conditions in which
+   they can be used, and the use of IPv4-Embedded IPv6 addresses with
+   stateless and stateful translation.
+
+   Section 4 discusses security concerns.
+
+   In some scenarios, a dual-stack host will unnecessarily send its
+   traffic through an IPv6/IPv4 translator.  This can be caused by
+   host's default address selection algorithm [RFC3484], referrals, or
+   other reasons.  Optimizing these scenarios for dual-stack hosts is
+   for future study.
+
+1.1.  Applicability Scope
+
+   This document is part of a series defining address translation
+   services.  We understand that the address format could also be used
+   by other interconnection methods between IPv6 and IPv4, e.g., methods
+   based on encapsulation.  If encapsulation methods are developed by
+   the IETF, we expect that their descriptions will document their
+   specific use of IPv4-Embedded IPv6 addresses.
+
+1.2.  Conventions
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+
+
+
+Bao, et al.             Expires October 11, 2010                [Page 3]
+
+Internet-Draft  IPv6 Addressing of IPv4/IPv6 Translators      April 2010
+
+
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+1.3.  Terminology
+
+   This document makes use of the following terms:
+
+   IPv4/IPv6 translator:  an entity that translates IPv4 packets to IPv6
+      packets, and vice versa.  It may do "stateless" translation,
+      meaning that there is no per-flow state required, or "stateful"
+      translation where per-flow state is created when the first packet
+      in a flow is received.
+   Address translator:  any entity that has to derive an IPv4 address
+      from an IPv6 address or vice versa.  This applies not only to
+      devices that do IPv4/IPv6 packet translation, but also to other
+      entities that manipulate addresses, such as name resolution
+      proxies (e.g.  DNS64 [I-D.ietf-behave-dns64]) and possibly other
+      types of Application Layer Gateways (ALGs).
+   Well-Known Prefix:  the IPv6 prefix defined in this document for use
+      in an algorithmic mapping.
+   Network-Specific Prefix:  an IPv6 prefix assigned by an organization
+      for use in algorithmic mapping.  Options for the Network Specific
+      Prefix are discussed in Section 3.3 and Section 3.4.
+   IPv4-Embedded IPv6 addresses:  IPv6 addresses in which 32 bits
+      contain an IPv4 address.  Their format is described in
+      Section 2.2.
+   IPv4-Converted IPv6 addresses:  IPv6 addresses used to represent IPv4
+      nodes in an IPv6 network.  They are a variant of IPv4-Embedded
+      IPv6 addresses, and follow the format described in Section 2.2.
+   IPv4-Translatable IPv6 addresses:  IPv6 addresses assigned to IPv6
+      nodes for use with stateless translation.  They are a variant of
+      IPv4-Embedded IPv6 addresses, and follow the format described in
+      Section 2.2.
+
+
+2.  IPv4-Embedded IPv6 Address Prefix and Format
+
+2.1.  Well Known Prefix
+
+   This document reserves a "Well-Known Prefix" for use in an
+   algorithmic mapping.  The value of this IPv6 prefix is:
+
+      64:FF9B::/96
+
+2.2.  IPv4-Embedded IPv6 Address Format
+
+   IPv4-Converted IPv6 addresses and IPv4-Translatable IPv6 addresses
+   follow the same format, described here as the IPv4-Embedded IPv6
+   address Format.  IPv4-Embedded IPv6 addresses are composed of a
+
+
+
+Bao, et al.             Expires October 11, 2010                [Page 4]
+
+Internet-Draft  IPv6 Addressing of IPv4/IPv6 Translators      April 2010
+
+
+   variable length prefix, the embedded IPv4 address, and a variable
+   length suffix, as presented in the following diagram, in which PL
+   designates the prefix length:
+
+
+    +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+    |PL| 0-------------32--40--48--56--64--72--80--88--96--104-112-120-|
+    +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+    |32|     prefix    |v4(32)         | u | suffix                    |
+    +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+    |40|     prefix        |v4(24)     | u |(8)| suffix                |
+    +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+    |48|     prefix            |v4(16) | u | (16)  | suffix            |
+    +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+    |56|     prefix                |(8)| u |  v4(24)   | suffix        |
+    +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+    |64|     prefix                    | u |   v4(32)      | suffix    |
+    +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+    |96|     prefix                                    |    v4(32)     |
+    +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+
+
+                                 Figure 1
+
+   In these addresses, the prefix shall be either the "Well-Known
+   Prefix", or a "Network-Specific Prefix" unique to the organization
+   deploying the address translators.  The prefixes can only have one of
+   the following lengths: 32, 40, 48, 56, 64 or 96.  (The Well-Known
+   prefic is 96 bits long, and can only be used in the last form of the
+   table.)
+
+   Various deployments justify different prefix lengths with Network-
+   Specific prefixes.  The tradeoff between different prefix lengths are
+   discussed in Section 3.3 and Section 3.4.
+
+   Bits 64 to 71 of the address are reserved for compatibility with the
+   host identifier format defined in the IPv6 addressing architecture
+   [RFC4291].  These bits MUST be set to zero.  When using a /96
+   Network-Specific Prefix, the administrators MUST ensure that the bits
+   64 to 71 are set to zero.  A simple way to achieve that is to
+   construct the /96 Network-Specific Prefix by picking a /64 prefix,
+   and then adding four octets set to zero.
+
+   The IPv4 address is encoded following the prefix, most significant
+   bits first.  Depending of the prefix length, the 4 octets of the
+   address may be separated by the reserved octet "u", whose 8 bits MUST
+   be set to zero.  In particular:
+
+
+
+
+Bao, et al.             Expires October 11, 2010                [Page 5]
+
+Internet-Draft  IPv6 Addressing of IPv4/IPv6 Translators      April 2010
+
+
+   o  When the prefix is 32 bits long, the IPv4 address is encoded in
+      positions 32 to 63.
+   o  When the prefix is 40 bits long, 24 bits of the IPv4 address are
+      encoded in positions 40 to 63, with the remaining 8 bits in
+      position 72 to 79.
+   o  When the prefix is 48 bits long, 16 bits of the IPv4 address are
+      encoded in positions 48 to 63, with the remaining 16 bits in
+      position 72 to 87.
+   o  When the prefix is 56 bits long, 8 bits of the IPv4 address are
+      encoded in positions 56 to 63, with the remaining 24 bits in
+      position 72 to 95.
+   o  When the prefix is 64 bits long, the IPv4 address is encoded in
+      positions 72 to 103.
+   o  When the prefix is 96 bits long, the IPv4 address is encoded in
+      positions 96 to 127.
+
+   There are no remaining bits, and thus no suffix, if the prefix is 96
+   bits long.  In the other cases, the remaining bits of the address
+   constitute the suffix.  These bits are reserved for future
+   extensions, and SHOULD be set to zero.
+
+2.3.  Address Translation Algorithms
+
+   IPv4-Embedded IPv6 addresses are composed according to the following
+   algorithm:
+   o  Concatenate the prefix, the 32 bits of the IPv4 address and the
+      null suffix if needed to obtain a 128 bit address.
+   o  If the prefix length is less than 96 bits, insert the null octet
+      "u" at the appropriate position, thus causing the least
+      significant octet to be excluded, as documented in Figure 1.
+
+   The IPv4 addresses are extracted from the IPv4-Embedded IPv6
+   addresses according to the following algorithm:
+   o  If the prefix is 96 bit long, extract the last 32 bits of the IPv6
+      address;
+   o  for the other prefix lengths, extract the "u" octet to obtain a
+      120 bit sequence, then extract the 32 bits following the prefix.
+
+2.4.  Text Representation
+
+   IPv4-Embedded IPv6 addresses will be represented in text in
+   conformity with section 2.2 of [RFC4291].  IPv4-Embedded IPv6
+   addresses constructed using the Well-Known Prefix or a /96 Network-
+   Specific Prefix may be represented using the alternative form
+   presented in section 2.2 of [RFC4291], with the embedded IPv4 address
+   represented in dotted decimal notation.  Examples of such
+   representations are presented in Table 1 and Table 2.
+
+
+
+
+Bao, et al.             Expires October 11, 2010                [Page 6]
+
+Internet-Draft  IPv6 Addressing of IPv4/IPv6 Translators      April 2010
+
+
+   +-----------------------+------------+------------------------------+
+   | Network-Specific      |    IPv4    | IPv4-Embedded IPv6 address   |
+   | Prefix                |   address  |                              |
+   +-----------------------+------------+------------------------------+
+   | 2001:DB8::/32         | 192.0.2.33 | 2001:DB8:C000:221::          |
+   | 2001:DB8:100::/40     | 192.0.2.33 | 2001:DB8:1C0:2:21::          |
+   | 2001:DB8:122::/48     | 192.0.2.33 | 2001:DB8:122:C000:2:2100::   |
+   | 2001:DB8:122:300::/56 | 192.0.2.33 | 2001:DB8:122:3C0:0:221::     |
+   | 2001:DB8:122:344::/64 | 192.0.2.33 | 2001:DB8:122:344:C0:2:2100:: |
+   | 2001:DB8:122:344::/96 | 192.0.2.33 | 2001:DB8:122:344::192.0.2.33 |
+   +-----------------------+------------+------------------------------+
+
+    Table 1: Text representation of IPv4-Embedded IPv6 addresses using
+                         Network-Specific Prefixes
+
+     +-------------------+--------------+----------------------------+
+     | Well Known Prefix | IPv4 address | IPv4-Embedded IPv6 address |
+     +-------------------+--------------+----------------------------+
+     | 64:FF9B::/96      |  192.0.2.33  | 64:FF9B::192.0.2.33        |
+     +-------------------+--------------+----------------------------+
+
+    Table 2: Text representation of IPv4-Embedded IPv6 addresses using
+                           the Well-Known Prefix
+
+   The Network-Specific Prefix examples in Table 1 are derived from the
+   IPv6 prefix reserved for documentation in [RFC3849].  The IPv4
+   address 192.0.2.33 is part of the subnet 192.0.2.0/24 reserved for
+   documentation in [RFC5735].
+
+
+3.  Deployment Guidelines and Choices
+
+3.1.  Restrictions on the use of the Well-Known Prefix
+
+   The Well-Known Prefix MAY be used by organizations deploying
+   translation services, as explained in Section 3.4.
+
+   The Well-Known Prefix SHOULD NOT be used to construct IPv4-
+   Translatable addresses.  The nodes served by IPv4-Translatable IPv6
+   addresses should be able to receive global IPv6 traffic bound to
+   their IPv4-Translatable IPv6 address without incurring intermediate
+   protocol translation.  This is only possible if the specific prefix
+   used to build the IPv4-Translatable IPv6 addresses is advertized in
+   inter-domain routing, but the advertisement of more specific prefixes
+   derived from the Well-Known Prefix is not supported, as explained in
+   Section 3.2.  Network-Specific Prefixes SHOULD be used in these
+   scenarios, as explained in Section 3.3.
+
+
+
+
+Bao, et al.             Expires October 11, 2010                [Page 7]
+
+Internet-Draft  IPv6 Addressing of IPv4/IPv6 Translators      April 2010
+
+
+   The Well-Known Prefix MUST NOT be used to represent non global IPv4
+   addresses, such as those defined in [RFC1918].
+
+3.2.  Impact on Inter-Domain Routing
+
+   The Well-Known Prefix MAY appear in inter-domain routing tables, if
+   service providers decide to provide IPv6-IPv4 interconnection
+   services to peers.  Advertisement of the Well-Known Prefix SHOULD be
+   controlled either by upstream and/or downstream service providers
+   owing to inter-domain routing policies, e.g., through configuration
+   of BGP [RFC4271].  Organizations that advertize the Well-Known Prefix
+   in inter-domain routing MUST be able to provide IPv4/IPv6 translation
+   service.
+
+   When the IPv4/IPv6 translation relies on the Well-Known Prefix,
+   embedded IPv6 prefixes longer than the Well-Known Prefix MUST NOT be
+   advertised in BGP (especially e-BGP) [RFC4271] because this leads to
+   importing the IPv4 routing table into the IPv6 one and therefore
+   induces scalability issues to the global IPv6 routing table.
+   Administrators of BGP nodes SHOULD configure filters that discard
+   advertisements of embedded IPv6 prefixes longer than the Well-Known
+   Prefix.
+
+   When the IPv4/IPv6 translation service relies on Network-Specific
+   Prefixes, the IPv4-Translatable IPv6 prefixes used in stateless
+   translation MUST be advertised with proper aggregation to the IPv6
+   Internet.  Similarly, if translators are configured with multiple
+   Network-Specific Prefixes,these prefixes MUST be advertised to the
+   IPv6 Internet with proper aggregation.
+
+3.3.  Choice of Prefix for Stateless Translation Deployments
+
+   Organizations may deploy translation services using stateless
+   translation.  In these deployments, internal IPv6 nodes are addressed
+   using IPv4-Translatable IPv6 addresses, which enable them to be
+   accessed by IPv4 nodes.  The addresses of these external IPv4 nodes
+   are then represented in IPv4-Converted IPv6 addresses.
+
+   Organizations deploying stateless IPv4/IPv6 translation SHOULD assign
+   a Network-Specific Prefix to their IPv4/IPv6 translation service.
+   IPv4-Translatable and IPv4-Converted IPv6 addresses MUST be
+   constructed as specified in Section 2.2.  IPv4-Translatable IPv6
+   addresses MUST use the selected Network-Specific Prefix.  Both IPv4-
+   Translatable IPv6 addresses and IPv4-Converted IPv6 addresses SHOULD
+   use the same prefix.
+
+   Using the same prefix ensures that IPv6 nodes internal to the
+   organization will use the most efficient paths to reach the nodes
+
+
+
+Bao, et al.             Expires October 11, 2010                [Page 8]
+
+Internet-Draft  IPv6 Addressing of IPv4/IPv6 Translators      April 2010
+
+
+   served by IPv4-Translatable IPv6 addresses.  Specifically, if a node
+   learns the IPv4 address of a target internal node without knowing
+   that this target is in fact located behind the same translator that
+   the node also uses, translation rules will ensure that the IPv6
+   address constructed with the Network-Specific prefix is the same as
+   the IPv4-Translatable IPv6 address assigned to the target.  Standard
+   routing preference (more specific wins) will then ensure that the
+   IPv6 packets are delivered directly, without requiring "hair-pinning"
+   at the translator.
+
+   The intra-domain routing protocol must be able to deliver packets to
+   the nodes served by IPv4-Translatable IPv6 addresses.  This may
+   require routing on some or all of the embedded IPv4 address bits.
+   Security considerations detailed in Section 4 require that routers
+   check the validity of the IPv4-Translatable IPv6 source addresses,
+   using some form of reverse path check.
+
+   The management of stateless address translation can be illustrated
+   with a small example.  We will consider an IPv6 network with the
+   prefix 2001:DB8:122::/48.  The network administrator has selected the
+   Network-Specific prefix 2001:DB8:122:344::/64 for managing stateless
+   IPv4/IPv6 translation.  The IPv4-Translatable address block is 2001:
+   DB8:122:344:C0:2::/96 and this block is visible in IPv4 as the subnet
+   192.0.2.0/24.  In this network, the host A is assigned the IPv4-
+   Translatable IPv6 address 2001:DB8:122:344:C0:2:2100::, which
+   corresponds to the IPv4 address 192.0.2.33.  Host A's address is
+   configured either manually or through DHCPv6.
+
+   In this example, host A is not directly connected to the translator,
+   but instead to a link managed by a router R. The router R is
+   configured to forward to A the packets bound to 2001:DB8:122:344:C0:
+   2:2100::.  To receive these packets, R will advertise reachability of
+   the prefix 2001:DB8:122:344:C0:2:2100::/104 in the intra-domain
+   routing protocol -- or perhaps a shorter prefix if many hosts on link
+   have IPv4-Translatable IPv6 addresses derived from the same IPv4
+   subnet.  If a packet bound to 192.0.2.33 reaches the translator, the
+   destination address will be translated to 2001:DB8:122:344:C0:2:
+   2100::, and the packet will be routed towards R and then to A.
+
+   Let's suppose now that a host B of the same domain learns the IPv4
+   address of A, maybe through an application-specific referral.  If B
+   has translation-aware software, B can compose a destination address
+   by combining the Network-Specific Prefix 2001:DB8:122:344::/64 and
+   the IPv4 address 192.0.2.33, resulting in the address 2001:DB8:122:
+   344:C0:2:2100::.  The packet sent by B will be forwarded towards R,
+   and then to A, avoiding protocol translation.
+
+   Forwarding, and reverse path checks, should be performed on the
+
+
+
+Bao, et al.             Expires October 11, 2010                [Page 9]
+
+Internet-Draft  IPv6 Addressing of IPv4/IPv6 Translators      April 2010
+
+
+   combination of the prefix and the IPv4 address.  In theory, routers
+   should be able to route on prefixes of any length.  However, routing
+   on prefixes larger than 64 bits may be slower on some routers.  But
+   routing efficiency is not the only consideration in the choice of a
+   prefix length.  Organizations also need to consider the availability
+   of prefixes, and the potential impact of all-zeroes identifiers.
+
+   If a /32 prefix is used, all the routing bits are contained in the
+   top 64 bits of the IPv6 address, leading to excellent routing
+   properties.  These prefixes may however be hard to obtain, and
+   allocation of a /32 to a small set of IPv4-Translatable IPv6
+   addresses may be seen as wasteful.  In addition, the /32 prefix and a
+   zero suffix leads to an all-zeroes interface identifier, an issue
+   that we discuss in Section 3.5.
+
+   Intermediate prefix lengths such as /40, /48 or /56 appear as
+   compromises.  Only some of the IPv4 bits are part of the /64
+   prefixes.  Reverse path checks, in particular, may have a limited
+   efficiency.  Reverse path checks limited to the most significant bits
+   of the IPv4 address will reduce the possibility of spoofing external
+   IPv4 addresses, but would allow IPv6 nodes to spoof internal IPv4-
+   Translatable IPv6 addresses.
+
+   We propose here a compromise, based on using no more than 1/256th of
+   an organization's allocation of IPv6 addresses for the IPv4/IPv6
+   translation service.  For example, if the organization is an Internet
+   Service Provider with an allocated IPv6 prefix /32 or shorter, the
+   ISP could dedicate a /40 prefix to the translation service.  An end
+   site with a /48 allocation could dedicate a /56 prefix to the
+   translation service, or possibly a /96 prefix if all IPv4-
+   Translatable IPv6 addresses are located on the same link.
+
+   The recommended prefix length is also a function of the deployment
+   scenario.  The stateless translation can be used for Scenario 1,
+   Scenario 2, Scenario 5, and Scenario 6 defined in
+   [I-D.ietf-behave-v6v4-framework].  For different scenarios, the
+   prefix length recommendations are:
+   o  For scenario 1 (an IPv6 network to the IPv4 Internet) and scenario
+      2 (the IPv4 Internet to an IPv6 network), we recommend using a /40
+      prefix for an ISP holding a /32 allocation, and a /56 prefix for a
+      site holding a /48 allocation.
+   o  For scenario 5 (an IPv6 network to an IPv4 network) and scenario 6
+      (an IPv4 network to an IPv6 network), we recommend using a /64 or
+      a /96 prefix.
+
+   IPv4-Translatable IPv6 addresses SHOULD follow the IPv6 address
+   architecture and SHOULD be compatible with the IPv4 address
+   architecture.  The first IPv4-translatable address is the subnet-
+
+
+
+Bao, et al.             Expires October 11, 2010               [Page 10]
+
+Internet-Draft  IPv6 Addressing of IPv4/IPv6 Translators      April 2010
+
+
+   router anycast address in IPv6 and network identifier in IPv4, the
+   last IPv4-translatable address is the subnet broadcast addresses in
+   IPv4.  Both of them SHOULD NOT be used for IPv6 nodes.  In addition,
+   the minimum IPv4 subnet can be used for hosts is /30 (the router
+   interface needs a valid address for the same subnet) and this rule
+   SHOULD also be applied to the corresponding subnet of the IPv4-
+   translatable addresses.
+
+3.4.  Choice of Prefix for Stateful Translation Deployments
+
+   Organizations may deploy translation services based on stateful
+   translation technology.  An organization may decide to use either a
+   Network-Specific Prefix or the Well-Known Prefix for its stateful
+   IPv4/IPv6 translation service.
+
+   When these services are used, IPv6 nodes are addressed through
+   standard IPv6 addresses, while IPv4 nodes are represented by IPv4-
+   Converted IPv6 addresses, as specified in Section 2.2.
+
+   The stateful nature of the translation creates a potential stability
+   issue when the organization deploys multiple translators.  If several
+   translators use the same prefix, there is a risk that packets
+   belonging to the same connection may be routed to different
+   translators as the internal routing state changes.  This issue can be
+   avoided either by assigning different prefixes to different
+   translators, or by ensuring that all translators using same prefix
+   coordinate their state.
+
+   Stateful translation can be used in scenarios defined in
+   [I-D.ietf-behave-v6v4-framework].  The Well Known Prefix SHOULD be
+   used in these scenarios, with two exceptions:
+   o  In all scenarios, the translation MAY use a Network-Specific
+      Prefix, if deemed appropriate for management reasons.
+   o  The Well-Known Prefix MUST NOT be used for scenario 3 (the IPv6
+      Internet to an IPv4 network), as this would lead to using the
+      Well-Known Prefix with non-global IPv4 addresses.  That means a
+      Network-Specific Prefix MUST be used in that scenario, for example
+      a /96 prefix compatible with the Well-Known prefix format.
+
+3.5.  Choice of Suffix
+
+   The address format described in Section 2.2 recommends a zero suffix.
+   Before making this recommendation, we considered different options:
+   checksum neutrality; the encoding of a port range; and a value
+   different than 0.
+
+   In the case of stateless translation, there would be no need for the
+   translator to recompute a one's complement checksum if both the IPv4-
+
+
+
+Bao, et al.             Expires October 11, 2010               [Page 11]
+
+Internet-Draft  IPv6 Addressing of IPv4/IPv6 Translators      April 2010
+
+
+   Translatable and the IPv4-Converted IPv6 addresses were constructed
+   in a "checksum-neutral" manner, that is if the IPv6 addresses would
+   have the same one's complement checksum as the embedded IPv4 address.
+   In the case of stateful translation, checksum neutrality does not
+   eliminate checksum computation during translation, as only one of the
+   two addresses would be checksum neutral.  We considered reserving 16
+   bits in the suffix to guarantee checksum neutrality, but declined
+   because it would not help with stateful translation, and because
+   checksum neutrality can also be achieved by an appropriate choice of
+   the Network-Specific Prefix, as was done for example with the Well-
+   Known Prefix.
+
+   There have been proposals to complement stateless translation with a
+   port-range feature.  Instead of mapping an IPv4 address to exactly
+   one IPv6 prefix, the options would allow several IPv6 nodes to share
+   an IPv4 address, with each node managing a different range of ports.
+   If a port range extension is needed, it could be defined later, using
+   bits currently reserved as null in the suffix.
+
+   When a /32 prefix is used, an all-zero suffix results in an all-zero
+   interface identifier.  We understand the conflict with Section 2.6.1
+   of RFC4291, which specifies that all zeroes are used for the subnet-
+   router anycast address.  However, in our specification, there would
+   be only one node with an IPv4-Translatable IPv6 address in the /64
+   subnet, and the anycast semantic would not create confusion.  We thus
+   decided to keep the null suffix for now.  This issue does not exist
+   for prefixes larger than 32 bits, such as the /40, /56, /64 and /96
+   prefixes that we recommend in Section 3.3.
+
+3.6.  Choice of the Well-Known Prefix
+
+   Before making our recommendation of the Well-Known Prefix, we were
+   faced with three choices:
+   o  reuse the IPv4-mapped prefix, ::FFFF:0:0/96, as specified in RFC
+      2765 Section 2.1;
+   o  request IANA to allocate a /32 prefix,
+   o  or request allocation of a new /96 prefix.
+
+   We weighted the pros and cons of these choices before settling on the
+   recommended /96 Well-Known Prefix.
+
+   The main advantage of the existing IPv4-mapped prefix is that it is
+   already defined.  Reusing that prefix would require minimal
+   standardization efforts.  However, being already defined is not just
+   an advantage, as there may be side effects of current
+   implementations.  When presented with the IPv4-mapped prefix, current
+   versions of Windows and MacOS generate IPv4 packets, but will not
+   send IPv6 packets.  If we used the IPv4-mapped prefix, these nodes
+
+
+
+Bao, et al.             Expires October 11, 2010               [Page 12]
+
+Internet-Draft  IPv6 Addressing of IPv4/IPv6 Translators      April 2010
+
+
+   would not be able to support translation without modification.  This
+   will defeat the main purpose of the translation techniques.  We thus
+   eliminated the first choice, and decided to not reuse the IPv4-mapped
+   prefix, ::FFFF:0:0/96.
+
+   A /32 prefix would have allowed the embedded IPv4 address to fit
+   within the top 64 bits of the IPv6 address.  This would have
+   facilitated routing and load balancing when an organization deploys
+   several translators.  However, such destination-address based load
+   balancing may not be desirable.  It is not compatible with STUN in
+   the deployments involving multiple stateful translators, each one
+   having a different pool of IPv4 addresses.  STUN compatibility would
+   only be achieved if the translators managed the same pool of IPv4
+   addresses and were able to coordinate their translation state, in
+   which case there is no big advantage to using a /32 prefix rather
+   than a /96 prefix.
+
+   According to Section 2.2 of [RFC4291], in the legal textual
+   representations of IPv6 addresses, dotted decimal can only appear at
+   the end.  The /96 prefix is compatible with that requirement.  It
+   enables the dotted decimal notation without requiring an update to
+   [RFC4291].  This representation makes the address format easier to
+   use, and log files easier to read.
+
+   The prefix that we recommend has the particularity of being "checksum
+   neutral".  The sum of the hexadecimal numbers "0064" and "FF9B" is
+   "FFFF", i.e. a value equal to zero in one's complement arithmetic.
+   An IPv4-Embedded IPv6 address constructed with this prefix will have
+   the same one's complement checksum as the embedded IPv4 address.
+
+
+4.  Security Considerations
+
+4.1.  Protection Against Spoofing
+
+   By and large, IPv4/IPv6 translators can be modeled as special
+   routers, are subject to the same risks, and can implement the same
+   mitigations.  There is however a particular risk that directly
+   derives from the practice of embedding IPv4 addresses in IPv6:
+   address spoofing.
+
+   An attacker could use an IPv4-Embedded IPv6 address as the source
+   address of malicious packets.  After translation, the packets will
+   appear as IPv4 packets from the specified source, and the attacker
+   may be hard to track.  If left without mitigation, the attack would
+   allow malicious IPv6 nodes to spoof arbitrary IPv4 addresses.
+
+   The mitigation is to implement reverse path checks, and to verify
+
+
+
+Bao, et al.             Expires October 11, 2010               [Page 13]
+
+Internet-Draft  IPv6 Addressing of IPv4/IPv6 Translators      April 2010
+
+
+   throughout the network that packets are coming from an authorized
+   location.
+
+4.2.  Secure Configuration
+
+   The prefixes used for address translation are used by IPv6 nodes to
+   send packets to IPv6/IPv4 translators.  Attackers could attempt to
+   fool nodes, DNS gateways, and IPv4/IPv6 translators into using wrong
+   values for these parameters, resulting in network disruption, denial
+   of service, and possible information disclosure.  To mitigate such
+   attacks, network administrators need to ensure that prefixes are
+   configured in a secure way.
+
+   The mechanisms for achieving secure configuration of prefixes are
+   beyond the scope of this document.
+
+
+5.  IANA Considerations
+
+   The IANA is requested to add a note to the documentation of the
+   0000::/8 address block in
+   http://www.iana.org/assignments/ipv6-address-space to document the
+   assignment by the IETF of the Well Known Prefix.  For example:
+
+      The "Well Known Prefix" 64:FF9B::/96 used in an algorithmic
+      mapping between IPv4 to IPv6 addresses is defined out of the
+      0000::/8 address block, per (this document).
+
+
+6.  Acknowledgements
+
+   Many people in the Behave WG have contributed to the discussion that
+   led to this document, including Andrew Sullivan, Andrew Yourtchenko,
+   Brian Carpenter, Dan Wing, Ed Jankiewicz, Fred Baker, Hiroshi Miyata,
+   Iljitsch van Beijnum, John Schnizlein, Keith Moore, Kevin Yin, Magnus
+   Westerlund, Margaret Wasserman, Masahito Endo, Phil Roberts, Philip
+   Matthews, Remi Denis-Courmont, Remi Despres and William Waites.
+
+   Marcelo Bagnulo is partly funded by Trilogy, a research project
+   supported by the European Commission under its Seventh Framework
+   Program.
+
+
+7.  Contributors
+
+   The following individuals co-authored drafts from which text has been
+   incorporated, and are listed in alphabetical order.
+
+
+
+
+Bao, et al.             Expires October 11, 2010               [Page 14]
+
+Internet-Draft  IPv6 Addressing of IPv4/IPv6 Translators      April 2010
+
+
+       Congxiao Bao
+       CERNET Center/Tsinghua University
+       Room 225, Main Building, Tsinghua University
+       Beijing,   100084
+       China
+       Phone: +86 62785983
+       Email: congxiao@cernet.edu.cn
+
+       Dave Thaler
+       Microsoft Corporation
+       One Microsoft Way
+       Redmond, WA  98052
+       USA
+       Phone: +1 425 703 8835
+       Email: dthaler@microsoft.com
+
+       Fred Baker
+       Cisco Systems
+       Santa Barbara, California  93117
+       USA
+       Phone: +1-408-526-4257
+       Fax:   +1-413-473-2403
+       Email: fred@cisco.com
+
+       Hiroshi Miyata
+       Yokogawa Electric Corporation
+       2-9-32 Nakacho
+       Musashino-shi, Tokyo  180-8750
+       JAPAN
+       Email: h.miyata@jp.yokogawa.com
+
+       Marcelo Bagnulo
+       Universidad Carlos III de Madrid
+       Av. Universidad 30
+       Leganes, Madrid  28911
+       ESPANA
+       Email: marcelo@it.uc3m.es
+
+       Xing Li
+       CERNET Center/Tsinghua University
+       Room 225, Main Building, Tsinghua University
+       Beijing,   100084
+       China
+       Phone: +86 62785983
+       Email: xing@cernet.edu.cn
+
+
+
+
+
+
+Bao, et al.             Expires October 11, 2010               [Page 15]
+
+Internet-Draft  IPv6 Addressing of IPv4/IPv6 Translators      April 2010
+
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
+              Architecture", RFC 4291, February 2006.
+
+8.2.  Informative References
+
+   [I-D.ietf-behave-dns64]
+              Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum,
+              "DNS64: DNS extensions for Network Address Translation
+              from IPv6 Clients to IPv4 Servers",
+              draft-ietf-behave-dns64-04 (work in progress),
+              December 2009.
+
+   [I-D.ietf-behave-v6v4-framework]
+              Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
+              IPv4/IPv6 Translation",
+              draft-ietf-behave-v6v4-framework-03 (work in progress),
+              October 2009.
+
+   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
+              E. Lear, "Address Allocation for Private Internets",
+              BCP 5, RFC 1918, February 1996.
+
+   [RFC3484]  Draves, R., "Default Address Selection for Internet
+              Protocol version 6 (IPv6)", RFC 3484, February 2003.
+
+   [RFC3849]  Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix
+              Reserved for Documentation", RFC 3849, July 2004.
+
+   [RFC4271]  Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
+              Protocol 4 (BGP-4)", RFC 4271, January 2006.
+
+   [RFC5735]  Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses",
+              BCP 153, RFC 5735, January 2010.
+
+
+
+
+
+
+
+
+
+
+
+Bao, et al.             Expires October 11, 2010               [Page 16]
+
+Internet-Draft  IPv6 Addressing of IPv4/IPv6 Translators      April 2010
+
+
+Authors' Addresses
+
+   Congxiao Bao
+   CERNET Center/Tsinghua University
+   Room 225, Main Building, Tsinghua University
+   Beijing,   100084
+   China
+
+   Phone: +86 10-62785983
+   Email: congxiao@cernet.edu.cn
+
+
+   Christian Huitema
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052-6399
+   U.S.A.
+
+   Email: huitema@microsoft.com
+
+
+   Marcelo Bagnulo
+   UC3M
+   Av. Universidad 30
+   Leganes, Madrid  28911
+   Spain
+
+   Phone: +34-91-6249500
+   Fax:
+   Email: marcelo@it.uc3m.es
+   URI:   http://www.it.uc3m.es/marcelo
+
+
+   Mohamed Boucadair
+   France Telecom
+   3, Av Francois Chateaux
+   Rennes  350000
+   France
+
+   Email: mohamed.boucadair@orange-ftgroup.com
+
+
+
+
+
+
+
+
+
+
+
+Bao, et al.             Expires October 11, 2010               [Page 17]
+
+Internet-Draft  IPv6 Addressing of IPv4/IPv6 Translators      April 2010
+
+
+   Xing Li
+   CERNET Center/Tsinghua University
+   Room 225, Main Building, Tsinghua University
+   Beijing,   100084
+   China
+
+   Phone: +86 10-62785983
+   Email: xing@cernet.edu.cn
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bao, et al.             Expires October 11, 2010               [Page 18]
+
+
diff --git a/doc/draft/draft-ietf-behave-dns64-06.txt b/doc/draft/draft-ietf-behave-dns64-09.txt
index f648a21029a1..856d7131212c 100644
--- a/doc/draft/draft-ietf-behave-dns64-06.txt
+++ b/doc/draft/draft-ietf-behave-dns64-09.txt
@@ -4,17 +4,17 @@
 BEHAVE WG                                                     M. Bagnulo
 Internet-Draft                                                      UC3M
 Intended status: Standards Track                             A. Sullivan
-Expires: August 19, 2010                                        Shinkuro
+Expires: October 1, 2010                                        Shinkuro
                                                              P. Matthews
                                                           Alcatel-Lucent
                                                           I. van Beijnum
                                                           IMDEA Networks
-                                                       February 15, 2010
+                                                          March 30, 2010
 
 
 DNS64: DNS extensions for Network Address Translation from IPv6 Clients
                             to IPv4 Servers
-                       draft-ietf-behave-dns64-06
+                       draft-ietf-behave-dns64-09
 
 Abstract
 
@@ -47,14 +47,14 @@ 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 August 19, 2010.
+   This Internet-Draft will expire on October 1, 2010.
 
 
 
 
-Bagnulo, et al.          Expires August 19, 2010                [Page 1]
+Bagnulo, et al.          Expires October 1, 2010                [Page 1]
 
-Internet-Draft                    DNS64                    February 2010
+Internet-Draft                    DNS64                       March 2010
 
 
 Copyright Notice
@@ -108,65 +108,121 @@ Copyright Notice
 
 
 
-Bagnulo, et al.          Expires August 19, 2010                [Page 2]
+Bagnulo, et al.          Expires October 1, 2010                [Page 2]
 
-Internet-Draft                    DNS64                    February 2010
+Internet-Draft                    DNS64                       March 2010
 
 
 Table of Contents
 
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
-   2.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
-   3.  Background to DNS64-DNSSEC interaction . . . . . . . . . . . .  7
-   4.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  8
-   5.  DNS64 Normative Specification  . . . . . . . . . . . . . . . .  9
-     5.1.  Resolving AAAA queries and the answer section  . . . . . . 10
-       5.1.1.  The answer when there is AAAA data available . . . . . 10
-       5.1.2.  The answer when there is an error  . . . . . . . . . . 10
-       5.1.3.  Special exclusion set for AAAA records . . . . . . . . 10
-       5.1.4.  Dealing with CNAME and DNAME . . . . . . . . . . . . . 11
-       5.1.5.  Data for the answer when performing synthesis  . . . . 11
-       5.1.6.  Performing the synthesis . . . . . . . . . . . . . . . 12
-       5.1.7.  Querying in parallel . . . . . . . . . . . . . . . . . 12
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
+   2.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
+   3.  Background to DNS64-DNSSEC interaction . . . . . . . . . . . .  8
+   4.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  9
+   5.  DNS64 Normative Specification  . . . . . . . . . . . . . . . . 10
+     5.1.  Resolving AAAA queries and the answer section  . . . . . . 11
+       5.1.1.  The answer when there is AAAA data available . . . . . 11
+       5.1.2.  The answer when there is an error  . . . . . . . . . . 11
+       5.1.3.  Dealing with timeouts  . . . . . . . . . . . . . . . . 12
+       5.1.4.  Special exclusion set for AAAA records . . . . . . . . 12
+       5.1.5.  Dealing with CNAME and DNAME . . . . . . . . . . . . . 12
+       5.1.6.  Data for the answer when performing synthesis  . . . . 13
+       5.1.7.  Performing the synthesis . . . . . . . . . . . . . . . 13
+       5.1.8.  Querying in parallel . . . . . . . . . . . . . . . . . 14
      5.2.  Generation of the IPv6 representations of IPv4
-           addresses  . . . . . . . . . . . . . . . . . . . . . . . . 12
-     5.3.  Handling other RRs and the Additional Section  . . . . . . 13
-       5.3.1.  PTR queries  . . . . . . . . . . . . . . . . . . . . . 13
-       5.3.2.  Handling the additional section  . . . . . . . . . . . 14
-       5.3.3.  Other records  . . . . . . . . . . . . . . . . . . . . 15
-     5.4.  Assembling a synthesized response to a AAAA query  . . . . 15
-     5.5.  DNSSEC processing: DNS64 in recursive server mode  . . . . 16
-   6.  Deployment notes . . . . . . . . . . . . . . . . . . . . . . . 17
-     6.1.  DNS resolvers and DNS64  . . . . . . . . . . . . . . . . . 17
-     6.2.  DNSSEC validators and DNS64  . . . . . . . . . . . . . . . 17
-     6.3.  DNS64 and multihomed and dual-stack hosts  . . . . . . . . 17
-       6.3.1.  IPv6 multihomed hosts  . . . . . . . . . . . . . . . . 17
-       6.3.2.  Accidental dual-stack DNS64 use  . . . . . . . . . . . 18
-       6.3.3.  Intentional dual-stack DNS64 use . . . . . . . . . . . 18
-   7.  Deployment scenarios and examples  . . . . . . . . . . . . . . 19
+           addresses  . . . . . . . . . . . . . . . . . . . . . . . . 14
+     5.3.  Handling other Resource Records and the Additional
+           Section  . . . . . . . . . . . . . . . . . . . . . . . . . 15
+       5.3.1.  PTR Resource Record  . . . . . . . . . . . . . . . . . 15
+       5.3.2.  Handling the additional section  . . . . . . . . . . . 16
+       5.3.3.  Other Resource Records . . . . . . . . . . . . . . . . 16
+     5.4.  Assembling a synthesized response to a AAAA query  . . . . 17
+     5.5.  DNSSEC processing: DNS64 in recursive resolver mode  . . . 17
+   6.  Deployment notes . . . . . . . . . . . . . . . . . . . . . . . 18
+     6.1.  DNS resolvers and DNS64  . . . . . . . . . . . . . . . . . 18
+     6.2.  DNSSEC validators and DNS64  . . . . . . . . . . . . . . . 19
+     6.3.  DNS64 and multihomed and dual-stack hosts  . . . . . . . . 19
+       6.3.1.  IPv6 multihomed hosts  . . . . . . . . . . . . . . . . 19
+       6.3.2.  Accidental dual-stack DNS64 use  . . . . . . . . . . . 20
+       6.3.3.  Intentional dual-stack DNS64 use . . . . . . . . . . . 20
+   7.  Deployment scenarios and examples  . . . . . . . . . . . . . . 21
      7.1.  Example of An-IPv6-network-to-IPv4-Internet setup with
-           DNS64 in DNS server mode . . . . . . . . . . . . . . . . . 20
+           DNS64 in DNS server mode . . . . . . . . . . . . . . . . . 22
      7.2.  An example of an-IPv6-network-to-IPv4-Internet setup
-           with DNS64 in stub-resolver mode . . . . . . . . . . . . . 21
+           with DNS64 in stub-resolver mode . . . . . . . . . . . . . 23
      7.3.  Example of IPv6-Internet-to-an-IPv4-network setup
-           DNS64 in DNS server mode . . . . . . . . . . . . . . . . . 23
-   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 25
-   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 25
-   10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 25
-   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
-   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
-     12.1. Normative References . . . . . . . . . . . . . . . . . . . 26
-     12.2. Informative References . . . . . . . . . . . . . . . . . . 26
+           DNS64 in DNS server mode . . . . . . . . . . . . . . . . . 25
+   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 27
+   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 27
+   10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 27
+   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
+   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
+     12.1. Normative References . . . . . . . . . . . . . . . . . . . 28
+     12.2. Informative References . . . . . . . . . . . . . . . . . . 29
    Appendix A.  Motivations and Implications of synthesizing AAAA
-                RR when real AAAA RR exists . . . . . . . . . . . . . 28
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
+                Resource Records when real AAAA Resource Records
+
+
+
+Bagnulo, et al.          Expires October 1, 2010                [Page 3]
+
+Internet-Draft                    DNS64                       March 2010
+
+
+                exist . . . . . . . . . . . . . . . . . . . . . . . . 30
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
 
 
 
 
-Bagnulo, et al.          Expires August 19, 2010                [Page 3]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bagnulo, et al.          Expires October 1, 2010                [Page 4]
 
-Internet-Draft                    DNS64                    February 2010
+Internet-Draft                    DNS64                       March 2010
 
 
 1.  Introduction
@@ -220,9 +276,9 @@ Internet-Draft                    DNS64                    February 2010
 
 
 
-Bagnulo, et al.          Expires August 19, 2010                [Page 4]
+Bagnulo, et al.          Expires October 1, 2010                [Page 5]
 
-Internet-Draft                    DNS64                    February 2010
+Internet-Draft                    DNS64                       March 2010
 
 
    available to the server).  Each IPv6/IPv4 translator used in
@@ -261,8 +317,9 @@ Internet-Draft                    DNS64                    February 2010
    so that both can algorithmically generate the same IPv6
    representation for a given IPv4 address.  In addition, it is required
    that IPv6 packets addressed to an IPv6 destination address that
-   contains the Pref64::/n be delivered to an IPv6/IPv4 translator, so
-   they can be translated into IPv4 packets.
+   contains the Pref64::/n be delivered to an IPv6/IPv4 translator that
+   has that particular Pref64::/n configured, so they can be translated
+   into IPv4 packets.
 
    Once the DNS64 has synthesized the AAAA RRs, the synthetic AAAA RRs
    are passed back to the IPv6 initiator, which will initiate an IPv6
@@ -272,15 +329,15 @@ Internet-Draft                    DNS64                    February 2010
 
    In general, the only shared state between the DNS64 and the IPv6/IPv4
    translator is the Pref64::/n and an optional set of static
-   parameters.  The Pref64::/n and the set of static parameters must be
 
 
 
-Bagnulo, et al.          Expires August 19, 2010                [Page 5]
+Bagnulo, et al.          Expires October 1, 2010                [Page 6]
 
-Internet-Draft                    DNS64                    February 2010
+Internet-Draft                    DNS64                       March 2010
 
 
+   parameters.  The Pref64::/n and the set of static parameters must be
    configured to be the same on both; there is no communication between
    the DNS64 device and IPv6/IPv4 translator functions.  The mechanism
    to be used for configuring the parameters of the DNS64 is beyond the
@@ -305,11 +362,12 @@ Internet-Draft                    DNS64                    February 2010
    has been assigned for the specific purpose of representing IPv4
    addresses in IPv6 address space.
 
-   The DNS64 function can be performed in any of three places.
+   The DNS64 function can be performed in any of three places.  The
+   terms below are more formally defined in Section 4.
 
    The first option is to locate the DNS64 function in authoritative
    servers for a zone.  In this case, the authoritative server provides
-   a synthetic AAAA RRs for an IPv4-only host in its zone.  This is one
+   synthetic AAAA RRs for an IPv4-only host in its zone.  This is one
    type of DNS64 server.
 
    Another option is to locate the DNS64 function in recursive name
@@ -318,41 +376,42 @@ Internet-Draft                    DNS64                    February 2010
    server can perform the synthesis of AAAA RRs and pass them back to
    the IPv6-only initiator.  The main advantage of this mode is that
    current IPv6 nodes can use this mechanism without requiring any
-   modification.  This mode is called "DNS64 in DNS recursive mode".
-   This is a second type of DNS64 server, and it is also one type of
-   DNS64 resolver.
+   modification.  This mode is called "DNS64 in DNS recursive resolver
+   mode" .  This is a second type of DNS64 server, and it is also one
+   type of DNS64 resolver.
 
    The last option is to place the DNS64 function in the end hosts,
    coupled to the local (stub) resolver.  In this case, the stub
    resolver will try to obtain (real) AAAA RRs and in case they are not
    available, the DNS64 function will synthesize AAAA RRs for internal
    usage.  This mode is compatible with some advanced functions like
-   DNSSEC validation in the end host.  The main drawback of this mode is
-   its deployability, since it requires changes in the end hosts.  This
 
 
 
-Bagnulo, et al.          Expires August 19, 2010                [Page 6]
+Bagnulo, et al.          Expires October 1, 2010                [Page 7]
 
-Internet-Draft                    DNS64                    February 2010
+Internet-Draft                    DNS64                       March 2010
 
 
+   DNSSEC validation in the end host.  The main drawback of this mode is
+   its deployability, since it requires changes in the end hosts.  This
    mode is called "DNS64 in stub-resolver mode".  This is the second
    type of DNS64 resolver.
 
 
 3.  Background to DNS64-DNSSEC interaction
 
-   DNSSEC presents a special challenge for DNS64, because DNSSEC is
-   designed to detect changes to DNS answers, and DNS64 may alter
-   answers coming from an authoritative server.
+   DNSSEC ([RFC4033], [RFC4034], [RFC4035]) presents a special challenge
+   for DNS64, because DNSSEC is designed to detect changes to DNS
+   answers, and DNS64 may alter answers coming from an authoritative
+   server.
 
    A recursive resolver can be security-aware or security-oblivious.
-   Moreover, a security-aware recursive name server can be validating or
+   Moreover, a security-aware recursive resolver can be validating or
    non-validating, according to operator policy.  In the cases below,
-   the recursive server is also performing DNS64, and has a local policy
-   to validate.  We call this general case vDNS64, but in all the cases
-   below the DNS64 functionality should be assumed needed.
+   the recursive resolver is also performing DNS64, and has a local
+   policy to validate.  We call this general case vDNS64, but in all the
+   cases below the DNS64 functionality should be assumed needed.
 
    DNSSEC includes some signaling bits that offer some indicators of
    what the query originator understands.
@@ -382,17 +441,17 @@ Internet-Draft                    DNS64                    February 2010
        non-DNS64 case: the server doesn't support it, so the querying
        agent is out of luck.
 
-   3.  A security-aware and non-validating DNS64 receives a query with
-       the DO bit set and the CD bit clear.  Such a resolver is not
-       validating responses, likely due to local policy (see [RFC4035],
 
 
 
-Bagnulo, et al.          Expires August 19, 2010                [Page 7]
+Bagnulo, et al.          Expires October 1, 2010                [Page 8]
 
-Internet-Draft                    DNS64                    February 2010
+Internet-Draft                    DNS64                       March 2010
 
 
+   3.  A security-aware and non-validating DNS64 receives a query with
+       the DO bit set and the CD bit clear.  Such a resolver is not
+       validating responses, likely due to local policy (see [RFC4035],
        section 4.2).  For that reason, this case amounts to the same as
        the previous case, and no validation happens.
 
@@ -435,19 +494,19 @@ Internet-Draft                    DNS64                    February 2010
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
    document are to be interpreted as described in RFC 2119 [RFC2119].
 
-   Authoritative server:  A DNS server that can answer authoritatively a
-      given DNS question.
-
 
 
 
 
 
 
-Bagnulo, et al.          Expires August 19, 2010                [Page 8]
+Bagnulo, et al.          Expires October 1, 2010                [Page 9]
 
-Internet-Draft                    DNS64                    February 2010
+Internet-Draft                    DNS64                       March 2010
+
 
+   Authoritative server:  A DNS server that can answer authoritatively a
+      given DNS question.
 
    DNS64:  A logical function that synthesizes DNS resource records (e.g
       AAAA records containing IPv6 addresses) from DNS resource records
@@ -494,17 +553,17 @@ Internet-Draft                    DNS64                    February 2010
    multicast address handling is out of the scope of this document.  A
    possible approach is specified in [I-D.venaas-behave-mcast46].
 
-   DNS64 also responds to PTR queries involving addresses containing any
-   of the IPv6 prefixes it uses for synthesis of AAAA RRs.
 
 
 
-
-Bagnulo, et al.          Expires August 19, 2010                [Page 9]
+Bagnulo, et al.          Expires October 1, 2010               [Page 10]
 
-Internet-Draft                    DNS64                    February 2010
+Internet-Draft                    DNS64                       March 2010
 
 
+   DNS64 also responds to PTR queries involving addresses containing any
+   of the IPv6 prefixes it uses for synthesis of AAAA RRs.
+
 5.1.  Resolving AAAA queries and the answer section
 
    When the DNS64 receives a query for RRs of type AAAA and class IN, it
@@ -520,7 +579,7 @@ Internet-Draft                    DNS64                    February 2010
    section, the result is returned to the requesting client as per
    normal DNS semantics, except in the case where any of the AAAA
    records match a special exclusion set of prefixes, considered in
-   Section 5.1.3.  If there is (non-excluded) AAAA data available, DNS64
+   Section 5.1.4.  If there is (non-excluded) AAAA data available, DNS64
    SHOULD NOT include synthetic AAAA RRs in the response (see Appendix A
    for an analysis of the motivations for and the implications of not
    complying with this recommendation).  By default DNS64
@@ -548,19 +607,26 @@ Internet-Draft                    DNS64                    February 2010
    of the meaning of RCODE 3, and it is expected that they will decline
    in use as IPv6 deployment increases.
 
-5.1.3.  Special exclusion set for AAAA records
 
-   Some IPv6 addresses are not actually usable by IPv6-only hosts.  If
-   they are returned to IPv6-only querying agents as AAAA records,
-   therefore, the goal of decreasing the number of failure modes will
 
 
 
-Bagnulo, et al.          Expires August 19, 2010               [Page 10]
+
+Bagnulo, et al.          Expires October 1, 2010               [Page 11]
 
-Internet-Draft                    DNS64                    February 2010
+Internet-Draft                    DNS64                       March 2010
+
+
+5.1.3.  Dealing with timeouts
 
+   If the query receives no answer before the timeout, it is treated as
+   RCODE=2 (Server failure).
 
+5.1.4.  Special exclusion set for AAAA records
+
+   Some IPv6 addresses are not actually usable by IPv6-only hosts.  If
+   they are returned to IPv6-only querying agents as AAAA records,
+   therefore, the goal of decreasing the number of failure modes will
    not be attained.  Examples include AAAA records with addresses in the
    ::ffff:0:0/96 network, and possibly (depending on the context) AAAA
    records with the site's Pref::64/n or the Well-Known Prefix (see
@@ -585,7 +651,7 @@ Internet-Draft                    DNS64                    February 2010
    answer, and proceed accordingly.  It MUST NOT return the offending
    AAAA records as part of a response.
 
-5.1.4.  Dealing with CNAME and DNAME
+5.1.5.  Dealing with CNAME and DNAME
 
    If the response contains a CNAME or a DNAME, then the CNAME or DNAME
    chain is followed until the first terminating A or AAAA record is
@@ -594,35 +660,36 @@ Internet-Draft                    DNS64                    February 2010
    AAAA record to follow.  The resulting AAAA or A record is treated
    like any other AAAA or A case, as appropriate.
 
-   When assembling the answer section, the original CNAME or DNAME RR is
-   included as part of the answer, and the synthetic AAAA, if
-   appropriate, is included.
+   When assembling the answer section, any chains of CNAME or DNAME RRs
+   are included as part of the answer along with the synthetic AAAA (if
+   appropriate).
+
+
+
+
+
+Bagnulo, et al.          Expires October 1, 2010               [Page 12]
+
+Internet-Draft                    DNS64                       March 2010
 
-5.1.5.  Data for the answer when performing synthesis
+
+5.1.6.  Data for the answer when performing synthesis
 
    If the query results in no error but an empty answer section in the
    response, the DNS64 attempts to retrieve A records for the name in
    question, either by performing another query or, in the case of an
-   authortiative server, by examining its own results.  If this new A RR
+   authoritative server, by examining its own results.  If this new A RR
    query results in an empty answer or in an error, then the empty
    result or error is used as the basis for the answer returned to the
    querying client.  (Transient errors may result in retrying the query,
    depending on the mode and operation of the underlying resolver; this
    is just as in Section 5.1.2.)  If instead the query results in one or
-
-
-
-Bagnulo, et al.          Expires August 19, 2010               [Page 11]
-
-Internet-Draft                    DNS64                    February 2010
-
-
    more A RRs, the DNS64 synthesizes AAAA RRs based on the A RRs
-   according to the procedure outlined in Section 5.1.6.  The DNS64
+   according to the procedure outlined in Section 5.1.7.  The DNS64
    returns the synthesized AAAA records in the answer section, removing
    the A records that form the basis of the synthesis.
 
-5.1.6.  Performing the synthesis
+5.1.7.  Performing the synthesis
 
    A synthetic AAAA record is created from an A record as follows:
 
@@ -637,7 +704,12 @@ Internet-Draft                    DNS64                    February 2010
       RR and the SOA RR for the queried domain.  (Note that in order to
       obtain the TTL of the SOA RR, the DNS64 does not need to perform a
       new query, but it can remember the TTL from the SOA RR in the
-      negative response to the AAAA query.)
+      negative response to the AAAA query.  If the SOA RR was not
+      delivered with the negative response to the AAAA query, then the
+      DNS64 SHOULD use a default value of 600 seconds.  It is possible
+      instead to query explicitly for the SOA RR and use the result of
+      that query, but this will increase query load and time to
+      resolution for little additional benefit.)
 
    o  The RDLENGTH field is set to 16
 
@@ -648,7 +720,16 @@ Internet-Draft                    DNS64                    February 2010
       See Section 5.2 for discussion of the algorithms to be used in
       effecting the transformation.
 
-5.1.7.  Querying in parallel
+
+
+
+
+Bagnulo, et al.          Expires October 1, 2010               [Page 13]
+
+Internet-Draft                    DNS64                       March 2010
+
+
+5.1.8.  Querying in parallel
 
    The DNS64 MAY perform the query for the AAAA RR and for the A RR in
    parallel, in order to minimize the delay.  However, this would result
@@ -665,14 +746,6 @@ Internet-Draft                    DNS64                    February 2010
 
    DNS64 supports multiple algorithms for the generation of the IPv6
    representation of an IPv4 address.  The constraints imposed on the
-
-
-
-Bagnulo, et al.          Expires August 19, 2010               [Page 12]
-
-Internet-Draft                    DNS64                    February 2010
-
-
    generation algorithms are the following:
 
       The same algorithm to create an IPv6 address from an IPv4 address
@@ -694,16 +767,24 @@ Internet-Draft                    DNS64                    February 2010
 
          For each prefix Pref64::/n, n MUST the less than or equal to
          96.  If one or more Pref64::/n are configured in the DNS64
-         through any means in the DNS64 (such as manually configured, or
-         other automatic means not specified in this document), the
-         default algorithm MUST use these prefixes (and not use the
-         Well-Know Prefix).  If no prefix is available, the algorithm
-         MUST use the Well-Known prefix 64:FF9B::/96 defined in
+         through any means (such as manually configured, or other
+         automatic means not specified in this document), the default
+         algorithm MUST use these prefixes (and not use the Well-Known
+         Prefix).  If no prefix is available, the algorithm MUST use the
+         Well-Known Prefix 64:FF9B::/96 defined in
          [I-D.ietf-behave-address-format] to represent the IPv4 unicast
          address range
 
-      [[anchor9: Note in document: The value 64:FF9B::/96 is proposed as
+      [[anchor8: Note in document: The value 64:FF9B::/96 is proposed as
       the value for the Well-Known prefix and needs to be confirmed
+
+
+
+Bagnulo, et al.          Expires October 1, 2010               [Page 14]
+
+Internet-Draft                    DNS64                       March 2010
+
+
       whenis published as RFC.]][I-D.ietf-behave-address-format]
 
    A DNS64 MUST support the algorithm for generating IPv6
@@ -715,56 +796,58 @@ Internet-Draft                    DNS64                    February 2010
    algorithm and its application to different scenarios is provided in
    Section 7 for illustration purposes.
 
-5.3.  Handling other RRs and the Additional Section
+5.3.  Handling other Resource Records and the Additional Section
 
-5.3.1.  PTR queries
+5.3.1.  PTR Resource Record
 
    If a DNS64 server receives a PTR query for a record in the IP6.ARPA
    domain, it MUST strip the IP6.ARPA labels from the QNAME, reverse the
-
-
-
-Bagnulo, et al.          Expires August 19, 2010               [Page 13]
-
-Internet-Draft                    DNS64                    February 2010
-
-
    address portion of the QNAME according to the encoding scheme
    outlined in section 2.5 of [RFC3596], and examine the resulting
    address to see whether its prefix matches any of the locally-
    configured Pref64::/n.  There are two alternatives for a DNS64 server
    to respond to such PTR queries.  A DNS64 server MUST provide one of
    these, and SHOULD NOT provide both at the same time unless different
-   IP6.ARPA zones require answers of different sorts.
-
-   The first option is for the DNS64 server to respond authoritatively
-   for its prefixes.  If the address prefix matches any Pref64::/n used
-   in the site, either a NSP or the Well-Known Prefix (i.e. 64:
-   FF9B::/96), then the DNS64 server MAY answer the query using locally-
-   appropriate RDATA.  The DNS64 server MAY use the same RDATA for all
-   answers.  Note that the requirement is to match any Pref64::/n used
-   at the site, and not merely the locally-configured Pref64::/n.  This
-   is because end clients could ask for a PTR record matching an address
-   received through a different (site-provided) DNS64, and if this
-   strategy is in effect, those queries should never be sent to the
-   global DNS.  The advantage of this strategy is that it makes plain to
-   the querying client that the prefix is one operated by the (DNS64)
-   site, and that the answers the client is getting are generated by
-   DNS64.  The disadvantage is that any useful reverse-tree information
-   that might be in the global DNS is unavailable to the clients
-   querying the DNS64.
-
-   The second option is for the DNS64 nameserver to synthesize a CNAME
-   mapping the IP6.ARPA namespace to the corresponding IN-ADDR.ARPA
-   name.  The rest of the response would be the normal DNS processing.
-   The CNAME can be signed on the fly if need be.  The advantage of this
-   approach is that any useful information in the reverse tree is
-   available to the querying client.  The disadvantage is that it adds
-   additional load to the DNS64 (because CNAMEs have to be synthesized
-   for each PTR query that matches the Pref64::/n), and that it may
-   require signing on the fly.  In addition, the generated CNAME could
-   correspond to an unpopulated in-addr.arpa zone, so the CNAME would
-   provide a reference to a non-existent record.
+   IP6.ARPA zones require answers of different sorts:
+
+   1.  The first option is for the DNS64 server to respond
+       authoritatively for its prefixes.  If the address prefix matches
+       any Pref64::/n used in the site, either a NSP or the Well-Known
+       Prefix (i.e. 64:FF9B::/96), then the DNS64 server MAY answer the
+       query using locally-appropriate RDATA.  The DNS64 server MAY use
+       the same RDATA for all answers.  Note that the requirement is to
+       match any Pref64::/n used at the site, and not merely the
+       locally-configured Pref64::/n.  This is because end clients could
+       ask for a PTR record matching an address received through a
+       different (site-provided) DNS64, and if this strategy is in
+       effect, those queries should never be sent to the global DNS.
+       The advantage of this strategy is that it makes plain to the
+       querying client that the prefix is one operated by the (DNS64)
+       site, and that the answers the client is getting are generated by
+       DNS64.  The disadvantage is that any useful reverse-tree
+       information that might be in the global DNS is unavailable to the
+       clients querying the DNS64.
+
+   2.  The second option is for the DNS64 nameserver to synthesize a
+       CNAME mapping the IP6.ARPA namespace to the corresponding IN-
+       ADDR.ARPA name.  The rest of the response would be the normal DNS
+       processing.  The CNAME can be signed on the fly if need be.  The
+       advantage of this approach is that any useful information in the
+
+
+
+Bagnulo, et al.          Expires October 1, 2010               [Page 15]
+
+Internet-Draft                    DNS64                       March 2010
+
+
+       reverse tree is available to the querying client.  The
+       disadvantage is that it adds additional load to the DNS64
+       (because CNAMEs have to be synthesized for each PTR query that
+       matches the Pref64::/n), and that it may require signing on the
+       fly.  In addition, the generated CNAME could correspond to an
+       unpopulated in-addr.arpa zone, so the CNAME would provide a
+       reference to a non-existent record.
 
    If the address prefix does not match any Pref64::/n, then the DNS64
    server MUST process the query as though it were any other query; i.e.
@@ -778,13 +861,6 @@ Internet-Draft                    DNS64                    February 2010
    additional section of synthesized answers.  The DNS64 MUST pass the
    additional section unchanged.
 
-
-
-Bagnulo, et al.          Expires August 19, 2010               [Page 14]
-
-Internet-Draft                    DNS64                    February 2010
-
-
    It may appear that adding synthetic records to the additional section
    is desirable, because clients sometimes use the data in the
    additional section to proceed without having to re-query.  There is
@@ -804,12 +880,22 @@ Internet-Draft                    DNS64                    February 2010
    NAT64 in question.  The result in this case will be resolution
    failure anyway, only later in the resolution operation.
 
-5.3.3.  Other records
+5.3.3.  Other Resource Records
 
    If the DNS64 is in recursive resolver mode, then considerations
    outlined in [I-D.ietf-dnsop-default-local-zones] may be relevant.
 
-   All other RRs MUST be returned unchanged.
+   All other RRs MUST be returned unchanged.  This includes responses to
+   queries for A RRs.
+
+
+
+
+
+Bagnulo, et al.          Expires October 1, 2010               [Page 16]
+
+Internet-Draft                    DNS64                       March 2010
+
 
 5.4.  Assembling a synthesized response to a AAAA query
 
@@ -820,30 +906,20 @@ Internet-Draft                    DNS64                    February 2010
    an error, an answer that can be used as a basis for synthesis, or an
    empty (authoritative) answer.  If there is an empty answer, then the
    DNS64 responds to the original querying client with the answer the
-   DNS64 received to the original AAAA query.  Otherwise, the response
-   is assembled as follows.
+   DNS64 received to the original (initiator's) query.  Otherwise, the
+   response is assembled as follows.
 
    The header fields are set according to the usual rules for recursive
    or authoritative servers, depending on the role that the DNS64 is
-   serving.  The question section is copied from the original AAAA
-   query.  The answer section is populated according to the rules in
-   Section 5.1.6.  The authority and additional sections are copied from
-   the response to the A query that the DNS64 performed.
-
-
-
-
-
-
-
-Bagnulo, et al.          Expires August 19, 2010               [Page 15]
-
-Internet-Draft                    DNS64                    February 2010
+   serving.  The question section is copied from the original
+   (initiator's) query.  The answer section is populated according to
+   the rules in Section 5.1.7.  The authority and additional sections
+   are copied from the response to the final query that the DNS64
+   performed, and used as the basis for synthesis.
 
+5.5.  DNSSEC processing: DNS64 in recursive resolver mode
 
-5.5.  DNSSEC processing: DNS64 in recursive server mode
-
-   We consider the case where a recursive server that is performing
+   We consider the case where a recursive resolver that is performing
    DNS64 also has a local policy to validate the answers according to
    the procedures outlined in [RFC4035] Section 5.  We call this general
    case vDNS64.
@@ -853,7 +929,9 @@ Internet-Draft                    DNS64                    February 2010
    accordingly:
 
    1.  If CD is not set and DO is not set, vDNS64 SHOULD perform
-       validation and do synthesis as needed.
+       validation and do synthesis as needed.  See the next item for
+       rules about how to do validation and synthesis.  In this case,
+       however, vDNS64 MUST NOT set the AD bit in any response.
 
    2.  If CD is not set and DO is set, then vDNS64 SHOULD perform
        validation.  Whenever vDNS64 performs validation, it MUST
@@ -867,6 +945,14 @@ Internet-Draft                    DNS64                    February 2010
        answer to the client.  This is acceptable, because [RFC4035],
        section 3.2.3 says that the AD bit is set by the name server side
        of a security-aware recursive name server if and only if it
+
+
+
+Bagnulo, et al.          Expires October 1, 2010               [Page 17]
+
+Internet-Draft                    DNS64                       March 2010
+
+
        considers all the RRSets in the Answer and Authority sections to
        be authentic.  In this case, the name server has reason to
        believe the RRSets are all authentic, so it SHOULD set the AD
@@ -889,14 +975,6 @@ Internet-Draft                    DNS64                    February 2010
        resolver, and depend on the client to do the validation and the
        synthesis itself.
        The disadvantage to this approach is that an end point that is
-
-
-
-Bagnulo, et al.          Expires August 19, 2010               [Page 16]
-
-Internet-Draft                    DNS64                    February 2010
-
-
        translation-oblivious but security-aware and validating will not
        be able to use the DNS64 functionality.  In this case, the end
        point will not have the desired benefit of NAT64.  In effect,
@@ -923,6 +1001,14 @@ Internet-Draft                    DNS64                    February 2010
    point obtain IPv4-only glue records and attempt to use them for
    resolution.  The result that is returned will contain only A records,
    and without the ability to perform the DNS64 function the resolver
+
+
+
+Bagnulo, et al.          Expires October 1, 2010               [Page 18]
+
+Internet-Draft                    DNS64                       March 2010
+
+
    will be unable to answer the necessary AAAA queries.
 
 6.2.  DNSSEC validators and DNS64
@@ -945,19 +1031,19 @@ Internet-Draft                    DNS64                    February 2010
    will receive answers from a DNS64 without all of them being connected
    via a NAT64.  For instance, suppose a system has two interfaces, i1
    and i2.  Whereas i1 is connected to the IPv4 Internet via NAT64, i2
-
-
-
-Bagnulo, et al.          Expires August 19, 2010               [Page 17]
-
-Internet-Draft                    DNS64                    February 2010
-
-
    has native IPv6 connectivity only.  I1 might receive a AAAA answer
    from a DNS64 that is configured for a particular NAT64; the IPv6
    address contained in that AAAA answer will not connect with anything
    via i2.
 
+             +---------------+                 +-------------+
+             |      i1 (IPv6)+----NAT64--------+IPv4 Internet|
+             |               |                 +-------------+
+             | host          |
+             |               |                 +-------------+
+             |      i2 (IPv6)+-----------------+IPv6 Internet|
+             +---------------+                 +-------------+
+
    This example illustrates why it is generally preferable that hosts
    treat DNS answers from one interface as local to that interface.  The
    answer received on one interface will not work on the other
@@ -969,6 +1055,16 @@ Internet-Draft                    DNS64                    February 2010
    there are two networks involved.  The same results could be achieved
    with a single interface routed to two different networks.
 
+
+
+
+
+
+Bagnulo, et al.          Expires October 1, 2010               [Page 19]
+
+Internet-Draft                    DNS64                       March 2010
+
+
 6.3.2.  Accidental dual-stack DNS64 use
 
    Similarly, suppose that i1 has IPv6 connectivity and can connect to
@@ -977,40 +1073,55 @@ Internet-Draft                    DNS64                    February 2010
    that would better be reached via native IPv4.  Again, it is worth
    emphasising that this arises because there are two networks involved.
 
-   Since it is most likely that the host will attempt AAAA resolution
-   first, in this arrangement the host will often use the NAT64 when
-   native IPv4 would be preferable.  For this reason, hosts with IPv4
-   connectivity to the Internet should avoid using DNS64.  This can be
-   partly resolved by ISPs when providing DNS resolvers to clients, but
-   that is not a guarantee that the NAT64 will never be used when a
-   native IPv4 connection should be used.  There is no general-purpose
-   mechanism to ensure that native IPv4 transit will always be
-   preferred, because to a DNS64-oblivious host, the DNS64 looks just
-   like an ordinary DNS server.  Operators of a NAT64 should expect
-   traffic to pass through the NAT64 even when it is not necessary.
+             +---------------+                 +-------------+
+             |      i1 (IPv6)+----NAT64--------+IPv4 Internet|
+             |               |                 +-------------+
+             | host          |
+             |               |                 +-------------+
+             |      i2 (IPv4)+-----------------+IPv4 Internet|
+             +---------------+                 +-------------+
+
+   The default configuration of dual-stack hosts is that IPv6 is
+   preferred over IPv4 ([RFC3484]).  In that arrangement the host will
+   often use the NAT64 when native IPv4 would be more desirable.  For
+   this reason, hosts with IPv4 connectivity to the Internet should
+   avoid using DNS64.  This can be partly resolved by ISPs when
+   providing DNS resolvers to clients, but that is not a guarantee that
+   the NAT64 will never be used when a native IPv4 connection should be
+   used.  There is no general-purpose mechanism to ensure that native
+   IPv4 transit will always be preferred, because to a DNS64-oblivious
+   host, the DNS64 looks just like an ordinary DNS server.  Operators of
+   a NAT64 should expect traffic to pass through the NAT64 even when it
+   is not necessary.
 
 6.3.3.  Intentional dual-stack DNS64 use
 
    Finally, consider the case where the IPv4 connectivity on i2 is only
-   to a LAN, with an IPv6-only connection on i1 to the Internet,
-   connecting to the IPv4 Internet via NAT64.  Traffic to the LAN may
-   not be routable from the global Internet, as is often the case (for
-   instance) with LANs using RFC1918 addresses.  In this case, it is
-   critical that the DNS64 not synthesize AAAA responses for hosts in
-   the LAN, or else that the DNS64 be aware of hosts in the LAN and
-   provide context-sensitive answers ("split view" DNS answers) for
-   hosts inside the LAN.  As with any split view DNS arrangement,
-   operators must be prepared for data to leak from one context to
-
-
-
-Bagnulo, et al.          Expires August 19, 2010               [Page 18]
+   with a LAN, and not with the IPv4 Internet.  The IPv4 Internet is
+   only accessible using the NAT64.  In this case, it is critical that
+   the DNS64 not synthesize AAAA responses for hosts in the LAN, or else
+   that the DNS64 be aware of hosts in the LAN and provide context-
+   sensitive answers ("split view" DNS answers) for hosts inside the
+   LAN.  As with any split view DNS arrangement, operators must be
+   prepared for data to leak from one context to another, and for
+   failures to occur because nodes accessible from one context are not
+   accessible from the other.
+
+             +---------------+                 +-------------+
+             |      i1 (IPv6)+----NAT64--------+IPv4 Internet|
+             |               |                 +-------------+
+             | host          |
+             |               |
+             |      i2 (IPv4)+---(local LAN only)
+
+
+
+Bagnulo, et al.          Expires October 1, 2010               [Page 20]
 
-Internet-Draft                    DNS64                    February 2010
+Internet-Draft                    DNS64                       March 2010
 
 
-   another, and for failures to occur because nodes accessible from one
-   context are not accessible from the other.
+             +---------------+
 
    It is important for deployers of DNS64 to realise that, in some
    circumstances, making the DNS64 available to a dual-stack host will
@@ -1040,7 +1151,7 @@ Internet-Draft                    DNS64                    February 2010
       communication from these IPv6-only connected hosts to the IPv4
       Internet.  This case is called An-IPv6-network-to-IPv4-Internet
       [I-D.ietf-behave-v6v4-framework].  In this case, the IPv6/IPv4
-      Translator is used to connect the end site or the ISP to the IPv4
+      translator is used to connect the end site or the ISP to the IPv4
       Internet and the DNS64 function is provided by the end site or the
       ISP.
 
@@ -1060,9 +1171,10 @@ Internet-Draft                    DNS64                    February 2010
 
 
 
-Bagnulo, et al.          Expires August 19, 2010               [Page 19]
+
+Bagnulo, et al.          Expires October 1, 2010               [Page 21]
 
-Internet-Draft                    DNS64                    February 2010
+Internet-Draft                    DNS64                       March 2010
 
 
    1.  An-IPv6-network-to-IPv4-Internet setup with DNS64 in DNS server
@@ -1116,9 +1228,9 @@ Internet-Draft                    DNS64                    February 2010
 
 
 
-Bagnulo, et al.          Expires August 19, 2010               [Page 20]
+Bagnulo, et al.          Expires October 1, 2010               [Page 22]
 
-Internet-Draft                    DNS64                    February 2010
+Internet-Draft                    DNS64                       March 2010
 
 
    For this example, assume the typical DNS situation where IPv6 hosts
@@ -1172,9 +1284,9 @@ Internet-Draft                    DNS64                    February 2010
 
 
 
-Bagnulo, et al.          Expires August 19, 2010               [Page 21]
+Bagnulo, et al.          Expires October 1, 2010               [Page 23]
 
-Internet-Draft                    DNS64                    February 2010
+Internet-Draft                    DNS64                       March 2010
 
 
              +---------------------+         +---------------+
@@ -1228,9 +1340,9 @@ Internet-Draft                    DNS64                    February 2010
 
 
 
-Bagnulo, et al.          Expires August 19, 2010               [Page 22]
+Bagnulo, et al.          Expires October 1, 2010               [Page 24]
 
-Internet-Draft                    DNS64                    February 2010
+Internet-Draft                    DNS64                       March 2010
 
 
        IPv6 address in the AAAA record contains the prefix assigned to
@@ -1284,9 +1396,9 @@ Internet-Draft                    DNS64                    February 2010
 
 
 
-Bagnulo, et al.          Expires August 19, 2010               [Page 23]
+Bagnulo, et al.          Expires October 1, 2010               [Page 25]
 
-Internet-Draft                    DNS64                    February 2010
+Internet-Draft                    DNS64                       March 2010
 
 
    is recommended over the second option (i.e. the synthesis upon
@@ -1340,9 +1452,9 @@ Internet-Draft                    DNS64                    February 2010
 
 
 
-Bagnulo, et al.          Expires August 19, 2010               [Page 24]
+Bagnulo, et al.          Expires October 1, 2010               [Page 26]
 
-Internet-Draft                    DNS64                    February 2010
+Internet-Draft                    DNS64                       March 2010
 
 
    1.  H1 does a DNS lookup for h2.example.com.  H1 does this by sending
@@ -1369,8 +1481,16 @@ Internet-Draft                    DNS64                    February 2010
 
 8.  Security Considerations
 
-   See the discussion on the usage of DNSSEC and DNS64 described in
-   section 3, section 5.5, and section 6.2. .
+   DNS64 functions in combination with the DNS, and is therefore subject
+   to whatever security considerations are appropriate to the DNS mode
+   in which the DNS64 is operating (i.e. authoritative, recursive, or
+   stub resolver mode).
+
+   DNS64 has the potential to interfere with the functioning of DNSSEC,
+   because DNS64 by its very functioning modifies DNS answers, and
+   DNSSEC is designed to detect such modification and to treat modified
+   answers as bogus.  See the discussion above in Section 3,
+   Section 5.5, and Section 6.2.
 
 
 9.  IANA Considerations
@@ -1384,30 +1504,31 @@ Internet-Draft                    DNS64                    February 2010
 
       Microsoft
 
-      dthaler@windows.microsoft.com
 
 
-11.  Acknowledgements
 
-   This draft contains the result of discussions involving many people,
-   including the participants of the IETF BEHAVE Working Group.  The
-   following IETF participants made specific contributions to parts of
-   the text, and their help is gratefully acknowledged: Mark Andrews,
 
+Bagnulo, et al.          Expires October 1, 2010               [Page 27]
+
+Internet-Draft                    DNS64                       March 2010
 
 
-Bagnulo, et al.          Expires August 19, 2010               [Page 25]
-
-Internet-Draft                    DNS64                    February 2010
+      dthaler@windows.microsoft.com
 
 
-   Jari Arkko, Rob Austein, Timothy Baldwin, Fred Baker, Doug Barton,
-   Marc Blanchet, Cameron Byrne, Brian Carpenter, Hui Deng, Francis
-   Dupont, Patrik Faltstrom, Ed Jankiewicz, Peter Koch, Suresh Krishnan,
-   Ed Lewis, Xing Li, Bill Manning, Matthijs Mekking, Hiroshi Miyata,
-   Simon Perrault, Teemu Savolainen, Jyrki Soini, Dave Thaler, Mark
-   Townsley, Rick van Rein, Stig Venaas, Magnus Westerlund, Florian
-   Weimer, Dan Wing, Xu Xiaohu, Xiangsong Cui.
+11.  Acknowledgements
+
+   This draft contains the result of discussions involving many people,
+   including the participants of the IETF BEHAVE Working Group.  The
+   following IETF participants made specific contributions to parts of
+   the text, and their help is gratefully acknowledged: Jaap Akkerhuis,
+   Mark Andrews, Jari Arkko, Rob Austein, Timothy Baldwin, Fred Baker,
+   Doug Barton, Marc Blanchet, Cameron Byrne, Brian Carpenter, Zhen Cao,
+   Hui Deng, Francis Dupont, Patrik Faltstrom, Ed Jankiewicz, Peter
+   Koch, Suresh Krishnan, Ed Lewis, Xing Li, Bill Manning, Matthijs
+   Mekking, Hiroshi Miyata, Simon Perrault, Teemu Savolainen, Jyrki
+   Soini, Dave Thaler, Mark Townsley, Rick van Rein, Stig Venaas, Magnus
+   Westerlund, Florian Weimer, Dan Wing, Xu Xiaohu, Xiangsong Cui.
 
    Marcelo Bagnulo and Iljitsch van Beijnum are partly funded by
    Trilogy, a research project supported by the European Commission
@@ -1432,10 +1553,21 @@ Internet-Draft                    DNS64                    February 2010
               RFC 4787, January 2007.
 
    [I-D.ietf-behave-address-format]
-              Huitema, C., Bao, C., Bagnulo, M., Boucadair, M., and X.
+              Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
               Li, "IPv6 Addressing of IPv4/IPv6 Translators",
-              draft-ietf-behave-address-format-04 (work in progress),
-              January 2010.
+              draft-ietf-behave-address-format-06 (work in progress),
+              March 2010.
+
+
+
+
+
+
+
+Bagnulo, et al.          Expires October 1, 2010               [Page 28]
+
+Internet-Draft                    DNS64                       March 2010
+
 
 12.2.  Informative References
 
@@ -1443,20 +1575,13 @@ Internet-Draft                    DNS64                    February 2010
               Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful
               NAT64: Network Address and Protocol Translation from IPv6
               Clients to IPv4 Servers",
-              draft-ietf-behave-v6v4-xlate-stateful-08 (work in
-              progress), January 2010.
+              draft-ietf-behave-v6v4-xlate-stateful-10 (work in
+              progress), March 2010.
 
    [RFC2136]  Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
               "Dynamic Updates in the Domain Name System (DNS UPDATE)",
               RFC 2136, April 1997.
 
-
-
-Bagnulo, et al.          Expires August 19, 2010               [Page 26]
-
-Internet-Draft                    DNS64                    February 2010
-
-
    [RFC3484]  Draves, R., "Default Address Selection for Internet
               Protocol version 6 (IPv6)", RFC 3484, February 2003.
 
@@ -1476,18 +1601,14 @@ Internet-Draft                    DNS64                    February 2010
               Rose, "Protocol Modifications for the DNS Security
               Extensions", RFC 4035, March 2005.
 
-   [RFC4966]  Aoun, C. and E. Davies, "Reasons to Move the Network
-              Address Translator - Protocol Translator (NAT-PT) to
-              Historic Status", RFC 4966, July 2007.
-
-   [RFC5735]  Cotton, M. and L. Vegoda, "iSpecial Use IPv4 Addresses",
+   [RFC5735]  Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses",
               BCP 153, RFC 5735, January 2010.
 
    [I-D.ietf-behave-v6v4-framework]
               Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
               IPv4/IPv6 Translation",
-              draft-ietf-behave-v6v4-framework-06 (work in progress),
-              February 2010.
+              draft-ietf-behave-v6v4-framework-08 (work in progress),
+              March 2010.
 
    [I-D.venaas-behave-mcast46]
               Venaas, S., Asaeda, H., SUZUKI, S., and T. Fujisaki, "An
@@ -1496,28 +1617,29 @@ Internet-Draft                    DNS64                    February 2010
               July 2009.
 
    [I-D.ietf-dnsop-default-local-zones]
-              Andrews, M., "Locally-served DNS Zones",
-              draft-ietf-dnsop-default-local-zones-09 (work in
-              progress), November 2009.
 
-   [I-D.savolainen-mif-dns-server-selection]
-              Savolainen, T., "DNS Server Selection on Multi-Homed
-              Hosts", draft-savolainen-mif-dns-server-selection-01 (work
-              in progress), October 2009.
 
 
+Bagnulo, et al.          Expires October 1, 2010               [Page 29]
+
+Internet-Draft                    DNS64                       March 2010
 
 
-Bagnulo, et al.          Expires August 19, 2010               [Page 27]
-
-Internet-Draft                    DNS64                    February 2010
+              Andrews, M., "Locally-served DNS Zones",
+              draft-ietf-dnsop-default-local-zones-10 (work in
+              progress), March 2010.
+
+   [I-D.savolainen-mif-dns-server-selection]
+              Savolainen, T., "DNS Server Selection on Multi-Homed
+              Hosts", draft-savolainen-mif-dns-server-selection-02 (work
+              in progress), February 2010.
 
 
-Appendix A.  Motivations and Implications of synthesizing AAAA RR when
-             real AAAA RR exists
+Appendix A.  Motivations and Implications of synthesizing AAAA Resource
+             Records when real AAAA Resource Records exist
 
-   The motivation for synthesizing AAAA RRs when a real AAAA RRs exist
-   is to support the following scenario:
+   The motivation for synthesizing AAAA RRs when real AAAA RRs exist is
+   to support the following scenario:
 
       An IPv4-only server application (e.g. web server software) is
       running on a dual-stack host.  There may also be dual-stack server
@@ -1538,7 +1660,7 @@ Appendix A.  Motivations and Implications of synthesizing AAAA RR when
    a DNS64 service may want to enable the synthesis of AAAA RRs even
    when real AAAA RRs exist.
 
-   The implication of including synthetic AAAA RR when real AAAA RR
+   The implication of including synthetic AAAA RRs when real AAAA RRs
    exist is that translated connectivity may be preferred over native
    connectivity in some cases where the DNS64 is operated in DNS server
    mode.
@@ -1551,28 +1673,28 @@ Appendix A.  Motivations and Implications of synthesizing AAAA RR when
    [I-D.ietf-behave-address-format]) is used, then a synthetic AAAA RR
    is likely to be preferred.
 
-   This means that without further configuration:
 
-      In "An IPv6 network to the IPv4 Internet" scenario , the host will
-      prefer translated connectivity if an NSP is used.  If the Well-
-      Known Prefix defined in [I-D.ietf-behave-address-format] is used,
-      it will probably prefer native connectivity.
 
-      In the "IPv6 Internet to an IPv4 network" scenario, it is possible
-      to bias the selection towards the real AAAA RR if the DNS64
-      resolver returns the real AAAA first in the DNS reply, when an NSP
 
+Bagnulo, et al.          Expires October 1, 2010               [Page 30]
+
+Internet-Draft                    DNS64                       March 2010
 
 
-Bagnulo, et al.          Expires August 19, 2010               [Page 28]
-
-Internet-Draft                    DNS64                    February 2010
+   This means that without further configuration:
 
+      In the "An IPv6 network to the IPv4 Internet" scenario, the host
+      will prefer translated connectivity if an NSP is used.  If the
+      Well-Known Prefix defined in [I-D.ietf-behave-address-format] is
+      used, it will probably prefer native connectivity.
 
+      In the "IPv6 Internet to an IPv4 network" scenario, it is possible
+      to bias the selection towards the real AAAA RR if the DNS64
+      resolver returns the real AAAA first in the DNS reply, when an NSP
       is used (the Well-Known Prefix usage is not supported in this
       case)
 
-      In "an IPv6 network to IPv4 network" scenario, for local
+      In the "An IPv6 network to IPv4 network" scenario, for local
       destinations (i.e., target hosts inside the local site), it is
       likely that the NSP and the destination prefix are the same, so we
       can use the order of RR in the DNS reply to bias the selection
@@ -1605,24 +1727,24 @@ Authors' Addresses
    URI:   http://www.it.uc3m.es/marcelo
 
 
-   Andrew Sullivan
-   Shinkuro
-   4922 Fairmont Avenue, Suite 250
-   Bethesda, MD  20814
-   USA
 
-   Phone: +1 301 961 3131
-   Email: ajs@shinkuro.com
 
 
 
 
+Bagnulo, et al.          Expires October 1, 2010               [Page 31]
+
+Internet-Draft                    DNS64                       March 2010
 
 
+   Andrew Sullivan
+   Shinkuro
+   4922 Fairmont Avenue, Suite 250
+   Bethesda, MD  20814
+   USA
 
-Bagnulo, et al.          Expires August 19, 2010               [Page 29]
-
-Internet-Draft                    DNS64                    February 2010
+   Phone: +1 301 961 3131
+   Email: ajs@shinkuro.com
 
 
    Philip Matthews
@@ -1666,15 +1788,5 @@ Internet-Draft                    DNS64                    February 2010
 
 
 
-
-
-
-
-
-
-
-
-
-
-Bagnulo, et al.          Expires August 19, 2010               [Page 30]
+Bagnulo, et al.          Expires October 1, 2010               [Page 32]
 
diff --git a/doc/draft/draft-ietf-dnsext-axfr-clarify-13.txt b/doc/draft/draft-ietf-dnsext-axfr-clarify-14.txt
index 935c709bcc21..f33a3fa96de7 100644
--- a/doc/draft/draft-ietf-dnsext-axfr-clarify-13.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,8 +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.
 
 
 
@@ -335,9 +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]
 
diff --git a/doc/draft/draft-ietf-dnsext-dns-tcp-requirements-02.txt b/doc/draft/draft-ietf-dnsext-dns-tcp-requirements-03.txt
index 757e82a88c46..a6d80baa2409 100644
--- a/doc/draft/draft-ietf-dnsext-dns-tcp-requirements-02.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,32 +311,35 @@ 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
-   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.
+   unknown sources.  In the case of UDP traffic this will help protect
 
 
 
-
-Bellis                    Expires July 10, 2010                 [Page 6]
+Bellis                 Expires September 23, 2010               [Page 6]
 
-Internet-Draft                DNS over TCP                  January 2010
+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.
 
 
 8.  IANA Considerations
@@ -342,12 +347,19 @@ Internet-Draft                DNS over TCP                  January 2010
    This document requests no IANA actions.
 
 
-9.  References
+9.  Acknowledgements
+
+   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.
 
-9.1.  Normative References
 
-   [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]
 
diff --git a/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-09.txt b/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-10.txt
index 0953e28b471f..eef3308e9270 100644
--- a/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-09.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
-
-
-
-
-
-
-
-
-
-
-
-
-Weiler & Blacka           Expires March 9, 2010                 [Page 2]
+     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 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.
 
-2.2.  SHA-256 Support
-
-   [RFC4509] describes the use of SHA-256 as a digest algorithm for use
-   with Delegation Signer (DS) RRs.  [I-D.ietf-dnsext-dnssec-rsasha256]
-   describes the use of the RSASHA256 algorithm for use in DNSKEY and
-   RRSIG RRs.  Validator implementations are strongly encouraged to
-   include support for this algorithm for DS, DNSKEY, and RRSIG records.
+   Note that the algorithm identifiers defined in RFC5155 (DSA-NSEC3-
+   SHA1 and RSASHA1-NSEC3-SHA1) 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 March 9, 2010                 [Page 3]
+Weiler & Blacka         Expires September 9, 2010               [Page 3]
 
-Internet-Draft       DNSSECbis Implementation Notes       September 2009
+Internet-Draft       DNSSECbis Implementation Notes           March 2010
+
 
+   responses.
+
+2.2.  SHA-256 Support
 
-   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.
+   [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.
+
+   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.
+
+
+
+
+Weiler & Blacka         Expires September 9, 2010               [Page 7]
+
+Internet-Draft       DNSSECbis Implementation Notes           March 2010
+
 
-4.7.  Setting the AD bit on Replies
+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
-
-
-   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.
+   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).
 
-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.
 
+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 March 9, 2010                 [Page 8]
+Weiler & Blacka         Expires September 9, 2010              [Page 10]
 
-Internet-Draft       DNSSECbis Implementation Notes       September 2009
+Internet-Draft       DNSSECbis Implementation Notes           March 2010
 
 
-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
    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]
 
+
diff --git a/doc/draft/draft-ietf-dnsext-dnssec-gost-06.txt b/doc/draft/draft-ietf-dnsext-dnssec-gost-07.txt
index f651d1351ec1..7bb5ab72f8d2 100644
--- a/doc/draft/draft-ietf-dnsext-dnssec-gost-06.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]
 
diff --git a/doc/draft/draft-ietf-dnsext-rfc2672bis-dname-18.txt b/doc/draft/draft-ietf-dnsext-rfc2672bis-dname-19.txt
index 3b9a35aeaf7f..34723c4f73e8 100644
--- a/doc/draft/draft-ietf-dnsext-rfc2672bis-dname-18.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
 
-   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]
+
+
+Rose & Wijngaards       Expires October 22, 2010                [Page 6]
 
-Internet-Draft              DNAME Redirection              November 2009
+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
    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]
 
-
diff --git a/doc/draft/draft-ietf-dnsop-default-local-zones-09.txt b/doc/draft/draft-ietf-dnsop-default-local-zones-10.txt
index 7e81e4c4bf55..e137ef351994 100644
--- a/doc/draft/draft-ietf-dnsop-default-local-zones-09.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.
 
-4.4.  IPv6 Locally Assigned Local Addresses
-
-   Section 4.4 of [RFC4193] already required special treatment of:
 
 
 
 
 
-Andrews                   Expires May 23, 2010                  [Page 7]
+Andrews                Expires September 26, 2010               [Page 7]
 
-Internet-Draft          Locally-served DNS Zones           November 2009
+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:
+
                              +--------------+
                              | 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.
 
-   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]
+Andrews                Expires September 26, 2010               [Page 8]
 
-Internet-Draft          Locally-served DNS Zones           November 2009
+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
    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.
 
-   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]
+Andrews                Expires September 26, 2010               [Page 9]
 
-Internet-Draft          Locally-served DNS Zones           November 2009
+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
    unsigned responses from the Internet.
 
 
@@ -551,15 +554,15 @@ Internet-Draft          Locally-served DNS Zones           November 2009
    [RFC4159]  Huston, G., "Deprecation of "ip6.int"", BCP 109, RFC 4159,
               August 2005.
 
-   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
-              Addresses", RFC 4193, October 2005.
 
 
-
-Andrews                   Expires May 23, 2010                 [Page 10]
+Andrews                Expires September 26, 2010              [Page 10]
 
-Internet-Draft          Locally-served DNS Zones           November 2009
+Internet-Draft          Locally-served DNS Zones              March 2010
+
 
+   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
+              Addresses", RFC 4193, October 2005.
 
    [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
 
-   editorial, reference updates
 
-A.3.  draft-ietf-dnsop-default-local-zones-07.txt
 
-   none, expiry prevention
 
-A.4.  draft-ietf-dnsop-default-local-zones-06.txt
 
-   add IPv6 example prefix
 
+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.4.  draft-ietf-dnsop-default-local-zones-07.txt
 
-Andrews                   Expires May 23, 2010                 [Page 11]
-
-Internet-Draft          Locally-served DNS Zones           November 2009
+   none, expiry prevention
 
+A.5.  draft-ietf-dnsop-default-local-zones-06.txt
 
-A.5.  draft-ietf-dnsop-default-local-zones-05.txt
+   add IPv6 example prefix
+
+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"
 
-   Add note that these zone are expected to seed the IANA registry.
-
-   Title changed.
-
-A.11.  draft-andrews-full-service-resolvers-03.txt
-
-   Added "Proposed Status".
-
 
 
+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.
 
-Andrews                   Expires May 23, 2010                 [Page 12]
-
-Internet-Draft          Locally-served DNS Zones           November 2009
+A.12.  draft-andrews-full-service-resolvers-03.txt
 
+   Added "Proposed Status".
 
-A.12.  draft-andrews-full-service-resolvers-02.txt
+A.13.  draft-andrews-full-service-resolvers-02.txt
 
    Added 0.IN-ADDR.ARPA.
 
@@ -692,9 +700,7 @@ Author's Address
    Redwood City, CA  94063
    US
 
-   Email: Mark_Andrews@isc.org
-
-
+   Email: marka@isc.org
 
 
 
@@ -718,12 +724,5 @@ Author's Address
 
 
 
-
-
-
-
-
-
-Andrews                   Expires May 23, 2010                 [Page 13]
+Andrews                Expires September 26, 2010              [Page 13]
 
-
diff --git a/lib/dns/api b/lib/dns/api
index baac976c8071..121147fe7c2a 100644
--- a/lib/dns/api
+++ b/lib/dns/api
@@ -1,3 +1,3 @@
 LIBINTERFACE = 38
-LIBREVISION = 0
+LIBREVISION = 1
 LIBAGE = 0
diff --git a/lib/dns/validator.c b/lib/dns/validator.c
index 9642791ad1ac..20843464a223 100644
--- 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");
diff --git a/version b/version
index 61b21455d9b1..38dd602a15ec 100644
--- a/version
+++ b/version
@@ -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