vendor/bind9/9.4-ESV-R3

6 files changed, 3851 insertions, 882 deletions

diff --git a/doc/draft/draft-ietf-behave-dns64-09.txt b/doc/draft/draft-ietf-behave-dns64-10.txt
index 856d7131212c..3d8200f961f3 100644
--- a/doc/draft/draft-ietf-behave-dns64-09.txt
+++ b/doc/draft/draft-ietf-behave-dns64-10.txt
@@ -4,17 +4,17 @@
 BEHAVE WG                                                     M. Bagnulo
 Internet-Draft                                                      UC3M
 Intended status: Standards Track                             A. Sullivan
-Expires: October 1, 2010                                        Shinkuro
+Expires: January 6, 2011                                        Shinkuro
                                                              P. Matthews
                                                           Alcatel-Lucent
                                                           I. van Beijnum
                                                           IMDEA Networks
-                                                          March 30, 2010
+                                                            July 5, 2010
 
 
 DNS64: DNS extensions for Network Address Translation from IPv6 Clients
                             to IPv4 Servers
-                       draft-ietf-behave-dns64-09
+                       draft-ietf-behave-dns64-10
 
 Abstract
 
@@ -28,41 +28,35 @@ Abstract
 
 Status of this Memo
 
-   This Internet-Draft is submitted to IETF in full conformance with the
+   This Internet-Draft is submitted in full conformance with the
    provisions of BCP 78 and BCP 79.
 
    Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
+   Task Force (IETF).  Note that other groups may also distribute
+   working documents as Internet-Drafts.  The list of current Internet-
+   Drafts is at http://datatracker.ietf.org/drafts/current/.
 
    Internet-Drafts are draft documents valid for a maximum of six months
    and may be updated, replaced, or obsoleted by other documents at any
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."
 
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
+   This Internet-Draft will expire on January 6, 2011.
 
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
+Copyright Notice
 
-   This Internet-Draft will expire on October 1, 2010.
+   Copyright (c) 2010 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
 
+   This document is subject to BCP 78 and the IETF Trust's Legal
 
 
 
-Bagnulo, et al.          Expires October 1, 2010                [Page 1]
+Bagnulo, et al.          Expires January 6, 2011                [Page 1]
 
-Internet-Draft                    DNS64                       March 2010
-
+Internet-Draft                    DNS64                        July 2010
 
-Copyright Notice
 
-   Copyright (c) 2010 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
    Provisions Relating to IETF Documents
    (http://trustee.ietf.org/license-info) in effect on the date of
    publication of this document.  Please review these documents
@@ -70,7 +64,8 @@ Copyright Notice
    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.
+   described in the Simplified BSD License.
+
 
 
 
@@ -108,9 +103,14 @@ Copyright Notice
 
 
 
-Bagnulo, et al.          Expires October 1, 2010                [Page 2]
+
+
+
+
+
+Bagnulo, et al.          Expires January 6, 2011                [Page 2]
 
-Internet-Draft                    DNS64                       March 2010
+Internet-Draft                    DNS64                        July 2010
 
 
 Table of Contents
@@ -135,11 +135,11 @@ Table of Contents
            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.3.3.  Other Resource Records . . . . . . . . . . . . . . . . 17
      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.1.  DNS resolvers and DNS64  . . . . . . . . . . . . . . . . . 19
      6.2.  DNSSEC validators and DNS64  . . . . . . . . . . . . . . . 19
      6.3.  DNS64 and multihomed and dual-stack hosts  . . . . . . . . 19
        6.3.1.  IPv6 multihomed hosts  . . . . . . . . . . . . . . . . 19
@@ -151,25 +151,25 @@ Table of Contents
      7.2.  An example of an-IPv6-network-to-IPv4-Internet setup
            with DNS64 in stub-resolver mode . . . . . . . . . . . . . 23
      7.3.  Example of IPv6-Internet-to-an-IPv4-network setup
-           DNS64 in DNS server mode . . . . . . . . . . . . . . . . . 25
+           DNS64 in DNS server mode . . . . . . . . . . . . . . . . . 24
    8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 27
    9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 27
    10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 27
-   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
+   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
    12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
      12.1. Normative References . . . . . . . . . . . . . . . . . . . 28
-     12.2. Informative References . . . . . . . . . . . . . . . . . . 29
+     12.2. Informative References . . . . . . . . . . . . . . . . . . 28
    Appendix A.  Motivations and Implications of synthesizing AAAA
                 Resource Records when real AAAA Resource Records
 
 
 
-Bagnulo, et al.          Expires October 1, 2010                [Page 3]
+Bagnulo, et al.          Expires January 6, 2011                [Page 3]
 
-Internet-Draft                    DNS64                       March 2010
+Internet-Draft                    DNS64                        July 2010
 
 
-                exist . . . . . . . . . . . . . . . . . . . . . . . . 30
+                exist . . . . . . . . . . . . . . . . . . . . . . . . 29
    Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
 
 
@@ -220,9 +220,9 @@ Internet-Draft                    DNS64                       March 2010
 
 
 
-Bagnulo, et al.          Expires October 1, 2010                [Page 4]
+Bagnulo, et al.          Expires January 6, 2011                [Page 4]
 
-Internet-Draft                    DNS64                       March 2010
+Internet-Draft                    DNS64                        July 2010
 
 
 1.  Introduction
@@ -276,9 +276,9 @@ Internet-Draft                    DNS64                       March 2010
 
 
 
-Bagnulo, et al.          Expires October 1, 2010                [Page 5]
+Bagnulo, et al.          Expires January 6, 2011                [Page 5]
 
-Internet-Draft                    DNS64                       March 2010
+Internet-Draft                    DNS64                        July 2010
 
 
    available to the server).  Each IPv6/IPv4 translator used in
@@ -332,9 +332,9 @@ Internet-Draft                    DNS64                       March 2010
 
 
 
-Bagnulo, et al.          Expires October 1, 2010                [Page 6]
+Bagnulo, et al.          Expires January 6, 2011                [Page 6]
 
-Internet-Draft                    DNS64                       March 2010
+Internet-Draft                    DNS64                        July 2010
 
 
    parameters.  The Pref64::/n and the set of static parameters must be
@@ -388,9 +388,9 @@ Internet-Draft                    DNS64                       March 2010
 
 
 
-Bagnulo, et al.          Expires October 1, 2010                [Page 7]
+Bagnulo, et al.          Expires January 6, 2011                [Page 7]
 
-Internet-Draft                    DNS64                       March 2010
+Internet-Draft                    DNS64                        July 2010
 
 
    DNSSEC validation in the end host.  The main drawback of this mode is
@@ -444,9 +444,9 @@ Internet-Draft                    DNS64                       March 2010
 
 
 
-Bagnulo, et al.          Expires October 1, 2010                [Page 8]
+Bagnulo, et al.          Expires January 6, 2011                [Page 8]
 
-Internet-Draft                    DNS64                       March 2010
+Internet-Draft                    DNS64                        July 2010
 
 
    3.  A security-aware and non-validating DNS64 receives a query with
@@ -458,10 +458,11 @@ Internet-Draft                    DNS64                       March 2010
    4.  A security-aware and non-validating DNS64 receives a query with
        the DO bit set and the CD bit set.  In this case, the resolver is
        supposed to pass on all the data it gets to the query initiator
-       (see section 3.2.2 of [RFC4035]).  This case will be problematic
-       with DNS64.  If the DNS64 server modifies the record, the client
-       will get the data back and try to validate it, and the data will
-       be invalid as far as the client is concerned.
+       (see section 3.2.2 of [RFC4035]).  This case will not work with
+       DNS64, unless the validating resolver is prepared to do DNS64
+       itself.  If the DNS64 server modifies the record, the client will
+       get the data back and try to validate it, and the data will be
+       invalid as far as the client is concerned.
 
    5.  A security-aware and validating DNS64 node receives a query with
        the DO bit clear and CD clear.  In this case, the resolver
@@ -473,16 +474,17 @@ Internet-Draft                    DNS64                       March 2010
        set DO and CD), cannot tell that DNS64 is involved.
 
    6.  A security-aware and validating DNS64 node receives a query with
-       the DO bit set and CD clear.  This ought to work like the
-       previous case, except that the resolver should also set the
-       "Authentic Data" (AD) bit on the response.
+       the DO bit set and CD clear.  This works like the previous case,
+       except that the resolver should also set the "Authentic Data"
+       (AD) bit on the response.
 
    7.  A security-aware and validating DNS64 node receives a query with
        the DO bit set and CD set.  This is effectively the same as the
        case where a security-aware and non-validating recursive resolver
        receives a similar query, and the same thing will happen: the
        downstream validator will mark the data as invalid if DNS64 has
-       performed synthesis.
+       performed synthesis.  The node needs to do DNS64 itself, or else
+       communication will fail.
 
 
 4.  Terminology
@@ -498,11 +500,9 @@ Internet-Draft                    DNS64                       March 2010
 
 
 
-
-
-Bagnulo, et al.          Expires October 1, 2010                [Page 9]
+Bagnulo, et al.          Expires January 6, 2011                [Page 9]
 
-Internet-Draft                    DNS64                       March 2010
+Internet-Draft                    DNS64                        July 2010
 
 
    Authoritative server:  A DNS server that can answer authoritatively a
@@ -538,29 +538,33 @@ Internet-Draft                    DNS64                       March 2010
    be familiar with DNS terminology from [RFC1034], [RFC1035] and
    current NAT terminology from [RFC4787].  Some parts of this document
    assume familiarity with the terminology of the DNS security
-   extensions outlined in [RFC4035].
+   extensions outlined in [RFC4035].  It is worth emphasizing that while
+   DNS64 is a logical function separate from the DNS, it is nevertheless
+   closely associated with that protocol.  It depends on the DNS
+   protocol, and some behavior of DNS64 will interact with regular DNS
+   responses.
 
 
 5.  DNS64 Normative Specification
 
    DNS64 is a logical function that synthesizes AAAA records from A
    records.  The DNS64 function may be implemented in a stub resolver,
-   in a recursive resolver, or in an authoritative name server.
-
-   The implementation SHOULD support mapping of separate IPv4 address
-   ranges to separate IPv6 prefixes for AAAA record synthesis.  This
-   allows handling of special use IPv4 addresses [RFC5735].  Support of
-   multicast address handling is out of the scope of this document.  A
-   possible approach is specified in [I-D.venaas-behave-mcast46].
+   in a recursive resolver, or in an authoritative name server.  It
+   works within those DNS functions, and appears on the network as
+   though it were a "plain" DNS resolver or name server conforming to
+   [RFC1034], and [RFC1035].
 
 
 
-
-Bagnulo, et al.          Expires October 1, 2010               [Page 10]
+Bagnulo, et al.          Expires January 6, 2011               [Page 10]
 
-Internet-Draft                    DNS64                       March 2010
+Internet-Draft                    DNS64                        July 2010
 
 
+   The implementation SHOULD support mapping of separate IPv4 address
+   ranges to separate IPv6 prefixes for AAAA record synthesis.  This
+   allows handling of special use IPv4 addresses [RFC5735].
+
    DNS64 also responds to PTR queries involving addresses containing any
    of the IPv6 prefixes it uses for synthesis of AAAA RRs.
 
@@ -569,7 +573,8 @@ Internet-Draft                    DNS64                       March 2010
    When the DNS64 receives a query for RRs of type AAAA and class IN, it
    first attempts to retrieve non-synthetic RRs of this type and class,
    either by performing a query or, in the case of an authoritative
-   server, by examining its own results.  DNS64 operation for classes
+   server, by examining its own results.  The query may be answered from
+   a local cache, if one is available.  DNS64 operation for classes
    other than IN is undefined, and a DNS64 MUST behave as though no
    DNS64 function is configured.
 
@@ -599,28 +604,31 @@ Internet-Draft                    DNS64                       March 2010
    Any other RCODE is treated as though the RCODE were 0 and the answer
    section were empty.  This is because of the large number of different
    responses from deployed name servers when they receive AAAA queries
-   without a AAAA record being available.
-
-   It is important to note that, as of this writing, some servers
-   respond with RCODE=3 to a AAAA query even if there is an A record
-   available for that owner name.  Those servers are in clear violation
-   of the meaning of RCODE 3, and it is expected that they will decline
-   in use as IPv6 deployment increases.
+   without a AAAA record being available (see [RFC4074]).  Note that
+   this means, for practical purposes, that several different classes of
+   error in the DNS are all treated as though a AAAA record is not
+   available for that owner name.
 
 
 
 
-
-
-Bagnulo, et al.          Expires October 1, 2010               [Page 11]
+Bagnulo, et al.          Expires January 6, 2011               [Page 11]
 
-Internet-Draft                    DNS64                       March 2010
+Internet-Draft                    DNS64                        July 2010
+
 
+   It is important to note that, as of this writing, some servers
+   respond with RCODE=3 to a AAAA query even if there is an A record
+   available for that owner name.  Those servers are in clear violation
+   of the meaning of RCODE 3, and it is expected that they will decline
+   in use as IPv6 deployment increases.
 
 5.1.3.  Dealing with timeouts
 
-   If the query receives no answer before the timeout, it is treated as
-   RCODE=2 (Server failure).
+   If the query receives no answer before the timeout (which might be
+   the timeout from every authoritative server, depending on whether the
+   DNS64 is in recursive resolver mode), it is treated as RCODE=2
+   (Server failure). .
 
 5.1.4.  Special exclusion set for AAAA records
 
@@ -657,21 +665,20 @@ Internet-Draft                    DNS64                       March 2010
    chain is followed until the first terminating A or AAAA record is
    reached.  This may require the DNS64 to ask for an A record, in case
    the response to the original AAAA query is a CNAME or DNAME without a
-   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, 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 January 6, 2011               [Page 12]
+
+Internet-Draft                    DNS64                        July 2010
 
 
-Bagnulo, et al.          Expires October 1, 2010               [Page 12]
-
-Internet-Draft                    DNS64                       March 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, any chains of CNAME or DNAME RRs
+   are included as part of the answer along with the synthetic AAAA (if
+   appropriate).
 
 5.1.6.  Data for the answer when performing synthesis
 
@@ -681,13 +688,11 @@ Internet-Draft                    DNS64                       March 2010
    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
-   more A RRs, the DNS64 synthesizes AAAA RRs based on the A RRs
-   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.
+   querying client.  If instead the query results in one or more A RRs,
+   the DNS64 synthesizes AAAA RRs based on the A RRs 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.7.  Performing the synthesis
 
@@ -709,25 +714,25 @@ Internet-Draft                    DNS64                       March 2010
       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.)
+      resolution for little additional benefit.)  This is in keeping
+      with the approach used in negative caching ([RFC2308]
 
    o  The RDLENGTH field is set to 16
 
    o  The RDATA field is set to the IPv6 representation of the IPv4
       address from the RDATA field of the A record.  The DNS64 SHOULD
-      check each A RR against configured IPv4 address ranges and select
-      the corresponding IPv6 prefix to use in synthesizing the AAAA RR.
-      See Section 5.2 for discussion of the algorithms to be used in
-      effecting the transformation.
 
 
 
-
-
-Bagnulo, et al.          Expires October 1, 2010               [Page 13]
+Bagnulo, et al.          Expires January 6, 2011               [Page 13]
 
-Internet-Draft                    DNS64                       March 2010
+Internet-Draft                    DNS64                        July 2010
+
 
+      check each A RR against configured IPv4 address ranges and select
+      the corresponding IPv6 prefix to use in synthesizing the AAAA RR.
+      See Section 5.2 for discussion of the algorithms to be used in
+      effecting the transformation.
 
 5.1.8.  Querying in parallel
 
@@ -765,26 +770,26 @@ Internet-Draft                    DNS64                       March 2010
       configured in the DNS64 and in the NAT64 (such as fixed string to
       be used as a suffix).
 
-         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 (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
-
-      [[anchor8: Note in document: The value 64:FF9B::/96 is proposed as
-      the value for the Well-Known prefix and needs to be confirmed
+         For each prefix Pref64::/n, n MUST be less than or equal to 96.
+         If one or more Pref64::/n are configured in the DNS64 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
 
 
 
-Bagnulo, et al.          Expires October 1, 2010               [Page 14]
+Bagnulo, et al.          Expires January 6, 2011               [Page 14]
 
-Internet-Draft                    DNS64                       March 2010
+Internet-Draft                    DNS64                        July 2010
+
 
+         [I-D.ietf-behave-address-format] to represent the IPv4 unicast
+         address range
 
+      [[anchor8: Note in document: The value 64:FF9B::/96 is proposed as
+      the value for the Well-Known prefix and needs to be confirmed
       whenis published as RFC.]][I-D.ietf-behave-address-format]
 
    A DNS64 MUST support the algorithm for generating IPv6
@@ -828,19 +833,19 @@ Internet-Draft                    DNS64                       March 2010
        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]
+Bagnulo, et al.          Expires January 6, 2011               [Page 15]
 
-Internet-Draft                    DNS64                       March 2010
+Internet-Draft                    DNS64                        July 2010
 
 
+   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
        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
@@ -880,22 +885,25 @@ Internet-Draft                    DNS64                       March 2010
    NAT64 in question.  The result in this case will be resolution
    failure anyway, only later in the resolution operation.
 
-5.3.3.  Other Resource Records
+   The prohibition on synthetic data in the additional section reduces,
+   but does not eliminate, the possibility of resolution failures due to
+   cached DNS data from behind the DNS64.  See Section 6.
 
-   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.  This includes responses to
-   queries for A RRs.
 
 
+Bagnulo, et al.          Expires January 6, 2011               [Page 16]
+
+Internet-Draft                    DNS64                        July 2010
 
 
+5.3.3.  Other Resource Records
 
-Bagnulo, et al.          Expires October 1, 2010               [Page 16]
-
-Internet-Draft                    DNS64                       March 2010
+   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.  This includes responses to
+   queries for A RRs.
 
 5.4.  Assembling a synthesized response to a AAAA query
 
@@ -917,6 +925,9 @@ Internet-Draft                    DNS64                       March 2010
    are copied from the response to the final query that the DNS64
    performed, and used as the basis for synthesis.
 
+   The final response from the DNS64 is subject to all the standard DNS
+   rules, including truncation [RFC1035] and EDNS0 handling [RFC2671].
+
 5.5.  DNSSEC processing: DNS64 in recursive resolver mode
 
    We consider the case where a recursive resolver that is performing
@@ -933,6 +944,15 @@ Internet-Draft                    DNS64                       March 2010
        rules about how to do validation and synthesis.  In this case,
        however, vDNS64 MUST NOT set the AD bit in any response.
 
+
+
+
+
+Bagnulo, et al.          Expires January 6, 2011               [Page 17]
+
+Internet-Draft                    DNS64                        July 2010
+
+
    2.  If CD is not set and DO is set, then vDNS64 SHOULD perform
        validation.  Whenever vDNS64 performs validation, it MUST
        validate the negative answer for AAAA queries before proceeding
@@ -945,14 +965,6 @@ Internet-Draft                    DNS64                       March 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
@@ -989,6 +1001,14 @@ Internet-Draft                    DNS64                       March 2010
    deployment in an internetworking environment with some IPv4-only and
    IPv6-only networks, it is important to realise that it is
    incompatible with some things that may be deployed in an IPv4-only or
+
+
+
+Bagnulo, et al.          Expires January 6, 2011               [Page 18]
+
+Internet-Draft                    DNS64                        July 2010
+
+
    dual-stack context.
 
 6.1.  DNS resolvers and DNS64
@@ -1001,19 +1021,11 @@ Internet-Draft                    DNS64                       March 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
 
-   Existing DNSSEC validators (i.e. that are unaware of DNS64) might
+   An existing DNSSEC validator (i.e. that is unaware of DNS64) might
    reject all the data that comes from DNS64 as having been tampered
    with (even if it did not set CD when querying).  If it is necessary
    to have validation behind the DNS64, then the validator must know how
@@ -1044,27 +1056,25 @@ Internet-Draft                    DNS64                       March 2010
              |      i2 (IPv6)+-----------------+IPv6 Internet|
              +---------------+                 +-------------+
 
+                      Figure 1: IPv6 multihomed hosts
+
+
+
+Bagnulo, et al.          Expires January 6, 2011               [Page 19]
+
+Internet-Draft                    DNS64                        July 2010
+
+
    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
    interface.  Hosts that attempt to use DNS answers globally may
-   encounter surprising failures in these cases.  For more discussion of
-   this topic, see [I-D.savolainen-mif-dns-server-selection].
+   encounter surprising failures in these cases.
 
    Note that the issue is not that there are two interfaces, but that
    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
@@ -1081,6 +1091,8 @@ Internet-Draft                    DNS64                       March 2010
              |      i2 (IPv4)+-----------------+IPv4 Internet|
              +---------------+                 +-------------+
 
+                 Figure 2: Accidental dual-stack DNS64 use
+
    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
@@ -1101,6 +1113,14 @@ Internet-Draft                    DNS64                       March 2010
    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-
+
+
+
+Bagnulo, et al.          Expires January 6, 2011               [Page 20]
+
+Internet-Draft                    DNS64                        July 2010
+
+
    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
@@ -1113,16 +1133,10 @@ Internet-Draft                    DNS64                       March 2010
              | host          |
              |               |
              |      i2 (IPv4)+---(local LAN only)
-
-
-
-Bagnulo, et al.          Expires October 1, 2010               [Page 20]
-
-Internet-Draft                    DNS64                       March 2010
-
-
              +---------------+
 
+                Figure 3: Intentional dual-stack DNS64 use
+
    It is important for deployers of DNS64 to realise that, in some
    circumstances, making the DNS64 available to a dual-stack host will
    cause the host to prefer to send packets via NAT64 instead of via
@@ -1141,50 +1155,27 @@ Internet-Draft                    DNS64                       March 2010
    Section 5 and the normative definition of the address transformation
    algorithm is provided in [I-D.ietf-behave-address-format].
 
-   There are two main different setups where DNS64 is expected to be
-   used (other setups are possible as well, but these two are the main
-   ones identified at the time of this writing).
-
-      One possible setup that is expected to be common is the case of an
-      end site or an ISP that is providing IPv6-only connectivity or
-      connectivity to IPv6-only hosts that wants to allow the
-      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
-      Internet and the DNS64 function is provided by the end site or the
-      ISP.
-
-      The other possible setup that is expected is an IPv4 site that
-      wants that its IPv4 servers to be reachable from the IPv6
-      Internet.  This case is called IPv6-Internet-to-an-IPv4-network
-      [I-D.ietf-behave-v6v4-framework].  It should be noted that the
-      IPv4 addresses used in the IPv4 site can be either public or
-      private.  In this case, the IPv6/IPv4 translator is used to
-      connect the IPv4 end site to the IPv6 Internet and the DNS64
-      function is provided by the IPv4 end site itself.
-
-   In this section we illustrate how the DNS64 behaves in the different
-   scenarios that are expected to be common.  We consider then 3
-   possible scenarios, namely:
+   In this section we illustrate how the DNS64 behaves in different
+   scenarios that are expected to be common.  In particular we will
+   consider the following scenarios defined in
+   [I-D.ietf-behave-v6v4-framework]: the an-IPv6-network-to-IPv4-
+   Internet scenario (both with DNS64 in DNS server mode and in stub-
+   resolver mode) and the IPv6-Internet-to-an-IPv4-network setup (with
+   DNS64 in DNS server mode only).
 
+   In all the examples below, there is a IPv6/IPv4 translator connecting
+   the IPv6 domain to the IPv4 one.  Also there is a name server that is
+   a dual-stack node, so it can communicate with IPv6 hosts using IPv6
+   and with IPv4 nodes using IPv4.  In addition, we assume that in the
+   examples, the DNS64 function learns which IPv6 prefix it needs to use
+   to map the IPv4 address space through manual configuration.
 
 
 
-
-Bagnulo, et al.          Expires October 1, 2010               [Page 21]
+Bagnulo, et al.          Expires January 6, 2011               [Page 21]
 
-Internet-Draft                    DNS64                       March 2010
-
-
-   1.  An-IPv6-network-to-IPv4-Internet setup with DNS64 in DNS server
-       mode
+Internet-Draft                    DNS64                        July 2010
 
-   2.  An-IPv6-network-to-IPv4-Internet setup with DNS64 in stub-
-       resolver mode
-
-   3.  IPv6-Internet-to-an-IPv4-network setup with DNS64 in DNS server
-       mode
 
 7.1.  Example of An-IPv6-network-to-IPv4-Internet setup with DNS64 in
       DNS server mode
@@ -1198,40 +1189,28 @@ Internet-Draft                    DNS64                       March 2010
 
              +---------------------+         +---------------+
              |IPv6 network         |         |    IPv4       |
-             |           |  +-------------+  |  Network      |
+             |           |  +-------------+  |  Internet     |
              |           |--| Name server |--|               |
              |           |  | with DNS64  |  |  +----+       |
              |  +----+   |  +-------------+  |  | H2 |       |
              |  | H1 |---|         |         |  +----+       |
-             |  +----+   |      +-------+    |  192.0.2.1    |
-             |           |------| NAT64 |----|               |
-             |           |      +-------+    |               |
+             |  +----+   |   +------------+  |  192.0.2.1    |
+             |           |---| IPv6/IPv4  |--|               |
+             |           |   | Translator |  |               |
+             |           |   +------------+  |               |
              |           |         |         |               |
              +---------------------+         +---------------+
 
+    Figure 4: An-IPv6-network-to-IPv4-Internet setup with DNS64 in DNS
+                                server mode
+
    The figure shows an IPv6 node H1 and an IPv4 node H2 with IPv4
    address 192.0.2.1 and FQDN h2.example.com
 
-   A IPv6/IPv4 Translator connects the IPv6 network to the IPv4
-   Internet.  This IPv6/IPv4 Translator has an IPv4 address 203.0.113.1
-   assigned to its IPv4 interface and it is using the WKP 64:FF9B::/96
-   to create IPv6 representations of IPv4 addresses, as defined in
-   [I-D.ietf-behave-address-format].
-
-   The other element involved is the local name server.  The name server
-   is a dual-stack node, so that H1 can contact it via IPv6, while it
-   can contact IPv4-only name servers via IPv4.
-
-   The local name server is configured to represent the whole IPv4
-   unicast space with using the WKP 64:FF9B::/96.  For the purpose of
-   this example, we assume it learns this through manual configuration.
-
-
-
-Bagnulo, et al.          Expires October 1, 2010               [Page 22]
-
-Internet-Draft                    DNS64                       March 2010
-
+   The IPv6/IPv4 Translator has an IPv4 address 203.0.113.1 assigned to
+   its IPv4 interface and it is using the WKP 64:FF9B::/96 to create
+   IPv6 representations of IPv4 addresses.  The same prefix is
+   configured in the DNS64 function in the local name server.
 
    For this example, assume the typical DNS situation where IPv6 hosts
    have only stub resolvers, and they are configured with the IP address
@@ -1245,15 +1224,25 @@ Internet-Draft                    DNS64                       March 2010
        server.  The recursive name server implements DNS64
        functionality.
 
+
+
+
+
+Bagnulo, et al.          Expires January 6, 2011               [Page 22]
+
+Internet-Draft                    DNS64                        July 2010
+
+
    2.  The recursive name server resolves the query, and discovers that
        there are no AAAA records for H2.
 
-   3.  The recursive name server queries for A records for H2 and gets
-       back a single A records containing the IPv4 address 192.0.2.1.
-       The name server then synthesizes a AAAA records.  The IPv6
-       address in the AAAA record contains the prefix assigned to the
-       IPv6/IPv4 Translator in the upper 96 bits then the received IPv4
-       address i.e. the resulting IPv6 address is 64:FF9B::192.0.2.1
+   3.  The recursive name server performs an A-record query for H2 and
+       gets back an RRset containing a single A record with the IPv4
+       address 192.0.2.1.  The name server then synthesizes a AAAA
+       record.  The IPv6 address in the AAAA record contains the prefix
+       assigned to the IPv6/IPv4 Translator in the upper 96 bits and the
+       received IPv4 address in the lower 32 bits i.e. the resulting
+       IPv6 address is 64:FF9B::192.0.2.1
 
    4.  H1 receives the synthetic AAAA record and sends a packet towards
        H2.  The packet is sent to the destination address 64:FF9B::
@@ -1269,59 +1258,44 @@ Internet-Draft                    DNS64                       March 2010
    This case is depicted in the following figure:
 
 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Bagnulo, et al.          Expires October 1, 2010               [Page 23]
-
-Internet-Draft                    DNS64                       March 2010
-
-
              +---------------------+         +---------------+
              |IPv6 network         |         |    IPv4       |
-             |           |     +--------+    |  Network      |
+             |           |     +--------+    |  Internet     |
              |           |-----| Name   |----|               |
              | +-----+   |     | server |    |  +----+       |
              | | H1  |   |     +--------+    |  | H2 |       |
              | |with |---|         |         |  +----+       |
-             | |DNS64|   |      +-------+    |  192.0.2.1    |
-             | +----+    |------| NAT64 |----|               |
-             |           |      +-------+    |               |
+             | |DNS64|   |   +------------+  |  192.0.2.1    |
+             | +----+    |---| IPv6/IPv4  |--|               |
+             |           |   | Translator |  |               |
+             |           |   +------------+  |               |
              |           |         |         |               |
              +---------------------+         +---------------+
 
 
+   Figure 5: An-IPv6-network-to-IPv4-Internet setup with DNS64 in stub-
+                               resolver mode
+
    The figure shows an IPv6 node H1 implementing the DNS64 function and
    an IPv4 node H2 with IPv4 address 192.0.2.1 and FQDN h2.example.com
 
-   A IPv6/IPv4 Translator connects the IPv6 network to the IPv4
-   Internet.  This IPv6/IPv4 Translator is using the WKP 64:FF9B::/96
-   and an IPv4 address T 203.0.113.1 assigned to its IPv4 interface.
+   The IPv6/IPv4 Translator has an IPv4 address 203.0.113.1 assigned to
+   its IPv4 interface and it is using the WKP 64:FF9B::/96 to create
+
+
+
+Bagnulo, et al.          Expires January 6, 2011               [Page 23]
+
+Internet-Draft                    DNS64                        July 2010
 
-   H1 needs to know the prefix assigned to the local IPv6/IPv4
-   Translator (64:FF9B::/96).  For the purpose of this example, we
-   assume it learns this through manual configuration.
 
-   Also shown is a name server.  For the purpose of this example, we
-   assume that the name server is a dual-stack node, so that H1 can
-   contact it via IPv6, while it can contact IPv4-only name servers via
-   IPv4.
+   IPv6 representations of IPv4 addresses.  The same prefix is
+   configured in the DNS64 function in H1.
 
-   For this example, assume the typical situation where IPv6 hosts have
-   only stub resolvers and always query a name server that provides
-   recursive lookups (henceforth called "the recursive name server").
+   For this example, assume the typical DNS situation where IPv6 hosts
+   have only stub resolvers, and they are configured with the IP address
+   of a name server that they always have to query and that performs
+   recursive lookups (henceforth called "the recursive nameserver").
    The recursive name server does not perform the DNS64 function.
 
    The steps by which H1 establishes communication with H2 are:
@@ -1337,14 +1311,6 @@ Internet-Draft                    DNS64                       March 2010
    3.  The stub resolver at H1 then queries for an A record for H2 and
        gets back an A record containing the IPv4 address 192.0.2.1.  The
        DNS64 function within H1 then synthesizes a AAAA record.  The
-
-
-
-Bagnulo, et al.          Expires October 1, 2010               [Page 24]
-
-Internet-Draft                    DNS64                       March 2010
-
-
        IPv6 address in the AAAA record contains the prefix assigned to
        the IPv6/IPv4 translator in the upper 96 bits, then the received
        IPv4 address i.e. the resulting IPv6 address is 64:FF9B::
@@ -1365,21 +1331,28 @@ Internet-Draft                    DNS64                       March 2010
    the IPv4 site.
 
    In some cases, this scenario can be addressed without using any form
-   of DNS64 function.  This is so because in principle it is possible to
-   assign a fixed IPv6 address to each of the IPv4 nodes.  Such an IPv6
-   address would be constructed using the address transformation
-   algorithm defined in [I-D.ietf-behave-address-format] that takes as
-   input the Pref64::/96 and the IPv4 address of the IPv4 node.  Note
-   that the IPv4 address can be a public or a private address; the
-   latter does not present any additional difficulty, since an NSP must
-   be used as Pref64::/96 (in this scenario the usage of the Well-Known
-   prefix is not supported as discussed in
-   [I-D.ietf-behave-address-format]).  Once these IPv6 addresses have
-   been assigned to represent the IPv4 nodes in the IPv6 Internet, real
-   AAAA RRs containing these addresses can be published in the DNS under
-   the site's domain.  This is the recommended approach to handle this
-   scenario, because it does not involve synthesizing AAAA records at
-   the time of query.
+   of DNS64 function.  This is so because it is possible to assign a
+   fixed IPv6 address to each of the IPv4 nodes.  Such an IPv6 address
+   would be constructed using the address transformation algorithm
+   defined in [I-D.ietf-behave-address-format] that takes as input the
+   Pref64::/96 and the IPv4 address of the IPv4 node.  Note that the
+   IPv4 address can be a public or a private address; the latter does
+
+
+
+Bagnulo, et al.          Expires January 6, 2011               [Page 24]
+
+Internet-Draft                    DNS64                        July 2010
+
+
+   not present any additional difficulty, since an NSP must be used as
+   Pref64::/96 (in this scenario the usage of the Well-Known prefix is
+   not supported as discussed in [I-D.ietf-behave-address-format]).
+   Once these IPv6 addresses have been assigned to represent the IPv4
+   nodes in the IPv6 Internet, real AAAA RRs containing these addresses
+   can be published in the DNS under the site's domain.  This is the
+   recommended approach to handle this scenario, because it does not
+   involve synthesizing AAAA records at the time of query.
 
    However, there are some more dynamic scenarios, where synthesizing
    AAAA RRs in this setup may be needed.  In particular, when DNS Update
@@ -1393,33 +1366,47 @@ Internet-Draft                    DNS64                       March 2010
    constraints, upon the receipt of a DNS query for the AAAA RR.  The
    first option -- in which the AAAA is synthesized when the DNS update
    message is received, and the data published in the relevant zone --
+   is recommended over the second option (i.e. the synthesis upon
+   receipt of the AAAA DNS query).  This is because it is usually easier
+   to solve problems of misconfiguration when the DNS responses are not
+   being generated dynamically.  However, it may be the case where the
+   primary server (that receives all the updates) cannot be upgraded for
+   whatever reason, but where a secondary can be upgraded in order to
+   handle the (comparatively small amount) of AAAA queries.  In such
+   case, it is possible to use the DNS64 as described next.  The DNS64
+   behavior that we describe in this section covers the case of
+   synthesizing the AAAA RR when the DNS query arrives.
+
+   The scenario for this case is depicted in the following figure:
+
+
+
+
+
 
 
 
-Bagnulo, et al.          Expires October 1, 2010               [Page 25]
-
-Internet-Draft                    DNS64                       March 2010
 
 
-   is recommended over the second option (i.e. the synthesis upon
-   receipt of the AAAA DNS query).  This is because it is usually easier
-   to solve problems of misconfiguration and so on when the DNS
-   responses are not being generated dynamically.  However, it may be
-   the case where the primary server (that receives all the updates)
-   cannot be upgraded for whatever reason, but where a secondary can be
-   upgraded in order to handle the (comparatively small amount) of AAAA
-   queries.  In such case, it is possible to use the DNS64 as described
-   next.  The DNS64 behavior that we describe in this section covers the
-   case of synthesizing the AAAA RR when the DNS query arrives.
 
-   The scenario for this case is depicted in the following figure:
+
+
+
+
+
+
+
+Bagnulo, et al.          Expires January 6, 2011               [Page 25]
+
+Internet-Draft                    DNS64                        July 2010
 
 
               +-----------+          +----------------------+
               |           |          |   IPv4 site          |
-              |   IPv6    |      +-------+     |   +----+   |
-              | Internet  |------| NAT64 |-----|---| H2 |   |
-              |           |      +-------+     |   +----+   |
+              |   IPv6    |    +------------+  |   +----+   |
+              | Internet  |----| IPv6/IPv4  |--|---| H2 |   |
+              |           |    | Translator |  |   +----+   |
+              |           |    +------------+  |            |
               |           |          |         | 192.0.2.1  |
               |           |    +------------+  |            |
               |           |----| Name server|--|            |
@@ -1430,33 +1417,20 @@ Internet-Draft                    DNS64                       March 2010
               | H1 |                 +----------------------+
               +----+
 
-   The figure shows an IPv6 node H1 and an IPv4 node H2 with IPv4
-   address X 192.0.2.1 and FQDN h2.example.com.
-
-   A IPv6/IPv4 translator connects the IPv4 network to the IPv6
-   Internet.  This IPv6/IPv4 translator has a NSP 2001:DB8::/96.
+   Figure 6: IPv6-Internet-to-an-IPv4-network setup DNS64 in DNS server
+                                   mode
 
-   Also shown is the authoritative name server for the local domain with
-   DNS64 functionality.  For the purpose of this example, we assume that
-   the name server is a dual-stack node, so that H1 or a recursive
-   resolver acting on the request of H1 can contact it via IPv6, while
-   it can be contacted by IPv4-only nodes to receive dynamic DNS updates
-   via IPv4.
+   The figure shows an IPv6 node H1 and an IPv4 node H2 with IPv4
+   address 192.0.2.1 and FQDN h2.example.com.
 
-   The local name server needs to know the prefix assigned to the local
-   IPv6/IPv4 Translator (2001:DB8::/96).  For the purpose of this
-   example, we assume it learns this through manual configuration.
+   The IPv6/IPv4 Translator is using a NSP 2001:DB8::/96 to create IPv6
+   representations of IPv4 addresses.  The same prefix is configured in
+   the DNS64 function in the local name server.  The name server that
+   implements the DNS64 function is the authoritative name server for
+   the local domain.
 
    The steps by which H1 establishes communication with H2 are:
 
-
-
-
-Bagnulo, et al.          Expires October 1, 2010               [Page 26]
-
-Internet-Draft                    DNS64                       March 2010
-
-
    1.  H1 does a DNS lookup for h2.example.com.  H1 does this by sending
        a DNS query for a AAAA record for H2.  The query is eventually
        forwarded to the server in the IPv4 site.
@@ -1474,6 +1448,15 @@ Internet-Draft                    DNS64                       March 2010
        H2.  The packet is sent to the destination address 2001:DB8::
        192.0.2.1.
 
+
+
+
+
+Bagnulo, et al.          Expires January 6, 2011               [Page 26]
+
+Internet-Draft                    DNS64                        July 2010
+
+
    5.  The packet is routed through the IPv6 Internet to the IPv6
        interface of the IPv6/IPv4 translator and the communication flows
        using the IPv6/IPv4 translator mechanisms.
@@ -1481,16 +1464,15 @@ Internet-Draft                    DNS64                       March 2010
 
 8.  Security Considerations
 
-   DNS64 functions in combination with the DNS, and is therefore subject
+   DNS64 operates 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.
+   because DNS64 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
@@ -1504,15 +1486,6 @@ Internet-Draft                    DNS64                       March 2010
 
       Microsoft
 
-
-
-
-
-Bagnulo, et al.          Expires October 1, 2010               [Page 27]
-
-Internet-Draft                    DNS64                       March 2010
-
-
       dthaler@windows.microsoft.com
 
 
@@ -1524,13 +1497,22 @@ Internet-Draft                    DNS64                       March 2010
    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.
+   Hui Deng, Francis Dupont, Patrik Faltstrom, David Harrington, Ed
+   Jankiewicz, Peter Koch, Suresh Krishnan, Martti Kuparinen, 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, Jeff Westhead, Florian
+   Weimer, Dan Wing, Xu Xiaohu, Xiangsong Cui.
 
    Marcelo Bagnulo and Iljitsch van Beijnum are partly funded by
+
+
+
+Bagnulo, et al.          Expires January 6, 2011               [Page 27]
+
+Internet-Draft                    DNS64                        July 2010
+
+
    Trilogy, a research project supported by the European Commission
    under its Seventh Framework Program.
 
@@ -1552,22 +1534,14 @@ Internet-Draft                    DNS64                       March 2010
               (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
               RFC 4787, January 2007.
 
+   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
+              RFC 2671, August 1999.
+
    [I-D.ietf-behave-address-format]
               Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
               Li, "IPv6 Addressing of IPv4/IPv6 Translators",
-              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
-
+              draft-ietf-behave-address-format-08 (work in progress),
+              May 2010.
 
 12.2.  Informative References
 
@@ -1575,16 +1549,26 @@ Internet-Draft                    DNS64                       March 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-10 (work in
+              draft-ietf-behave-v6v4-xlate-stateful-11 (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.
 
+   [RFC2308]  Andrews, M., "Negative Caching of DNS Queries (DNS
+              NCACHE)", RFC 2308, March 1998.
+
    [RFC3484]  Draves, R., "Default Address Selection for Internet
               Protocol version 6 (IPv6)", RFC 3484, February 2003.
 
+
+
+Bagnulo, et al.          Expires January 6, 2011               [Page 28]
+
+Internet-Draft                    DNS64                        July 2010
+
+
    [RFC3596]  Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
               "DNS Extensions to Support IP Version 6", RFC 3596,
               October 2003.
@@ -1601,38 +1585,22 @@ Internet-Draft                    DNS64                       March 2010
               Rose, "Protocol Modifications for the DNS Security
               Extensions", RFC 4035, March 2005.
 
+   [RFC4074]  Morishita, Y. and T. Jinmei, "Common Misbehavior Against
+              DNS Queries for IPv6 Addresses", RFC 4074, May 2005.
+
    [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-08 (work in progress),
-              March 2010.
-
-   [I-D.venaas-behave-mcast46]
-              Venaas, S., Asaeda, H., SUZUKI, S., and T. Fujisaki, "An
-              IPv4 - IPv6 multicast translator",
-              draft-venaas-behave-mcast46-01 (work in progress),
-              July 2009.
+              draft-ietf-behave-v6v4-framework-09 (work in progress),
+              May 2010.
 
    [I-D.ietf-dnsop-default-local-zones]
-
-
-
-Bagnulo, et al.          Expires October 1, 2010               [Page 29]
-
-Internet-Draft                    DNS64                       March 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.
+              draft-ietf-dnsop-default-local-zones-13 (work in
+              progress), April 2010.
 
 
 Appendix A.  Motivations and Implications of synthesizing AAAA Resource
@@ -1643,12 +1611,20 @@ Appendix A.  Motivations and Implications of synthesizing AAAA Resource
 
       An IPv4-only server application (e.g. web server software) is
       running on a dual-stack host.  There may also be dual-stack server
-      applications also running on the same host.  That host has fully
+      applications running on the same host.  That host has fully
       routable IPv4 and IPv6 addresses and hence the authoritative DNS
-      server has an A and a AAAA record as a result.
+      server has an A and a AAAA record.
 
       An IPv6-only client (regardless of whether the client application
       is IPv6-only, the client stack is IPv6-only, or it only has an
+
+
+
+Bagnulo, et al.          Expires January 6, 2011               [Page 29]
+
+Internet-Draft                    DNS64                        July 2010
+
+
       IPv6 address) wants to access the above server.
 
       The client issues a DNS query to a DNS64 resolver.
@@ -1673,14 +1649,6 @@ Appendix A.  Motivations and Implications of synthesizing AAAA Resource
    [I-D.ietf-behave-address-format]) is used, then a synthetic AAAA RR
    is likely to be preferred.
 
-
-
-
-Bagnulo, et al.          Expires October 1, 2010               [Page 30]
-
-Internet-Draft                    DNS64                       March 2010
-
-
    This means that without further configuration:
 
       In the "An IPv6 network to the IPv4 Internet" scenario, the host
@@ -1701,16 +1669,16 @@ Internet-Draft                    DNS64                       March 2010
       through native connectivity.  If the Well-Known Prefix is used,
       the longest prefix match rule will select native connectivity.
 
-   So this option introduces problems in the following cases:
+   The problem can be solved by properly configuring the RFC3484
+   [RFC3484] policy table.
 
-      An IPv6 network to the IPv4 internet with an NSP
 
-      IPv6 to IPv4 in the same network when reaching external
-      destinations and an NSP is used.
 
-   In any case, the problem can be solved by properly configuring the
-   RFC3484 [RFC3484] policy table, but this requires effort on the part
-   of the site operator.
+
+
+Bagnulo, et al.          Expires January 6, 2011               [Page 30]
+
+Internet-Draft                    DNS64                        July 2010
 
 
 Authors' Addresses
@@ -1727,16 +1695,6 @@ Authors' Addresses
    URI:   http://www.it.uc3m.es/marcelo
 
 
-
-
-
-
-
-Bagnulo, et al.          Expires October 1, 2010               [Page 31]
-
-Internet-Draft                    DNS64                       March 2010
-
-
    Andrew Sullivan
    Shinkuro
    4922 Fairmont Avenue, Suite 250
@@ -1774,19 +1732,5 @@ Internet-Draft                    DNS64                       March 2010
 
 
 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Bagnulo, et al.          Expires October 1, 2010               [Page 32]
+Bagnulo, et al.          Expires January 6, 2011               [Page 31]
 
diff --git a/doc/draft/draft-ietf-dnsext-dnssec-gost-07.txt b/doc/draft/draft-ietf-dnsext-dnssec-gost-07.txt
deleted file mode 100644
index 7bb5ab72f8d2..000000000000
--- a/doc/draft/draft-ietf-dnsext-dnssec-gost-07.txt
+++ /dev/null
@@ -1,448 +0,0 @@
-DNS Extensions working group                             V.Dolmatov, Ed.  
-Internet-Draft                                            Cryptocom Ltd.    
-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-07
-
-Status of this Memo
-
-   This Internet-Draft is submitted to IETF in full conformance with the
-   provisions of BCP 78 and BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on September 06 2010.
-
-Copyright Notice
-
-   Copyright (c) 2009 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents 
-   (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 (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
-
-   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
-   2.  DNSKEY Resource Records . . . . . . . . . . . . . . . . . . . . 3
-     2.1.  Using a public key with existing cryptographic libraries. . 3
-     2.2.  GOST DNSKEY RR Example  . . . . . . . . . . . . . . . . . . 3
-   3.  RRSIG Resource Records  . . . . . . . . . . . . . . . . . . . . 4
-     3.1 RRSIG RR Example  . . . . . . . . . . . . . . . . . . . . . . 4
-   4.  DS Resource Records . . . . . . . . . . . . . . . . . . . . . . 5
-     4.1 DS RR Example . . . . . . . . . . . . . . . . . . . . . . . . 5
-   5.  Deployment Considerations . . . . . . . . . . . . . . . . . . . 5
-     5.1.  Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . . 5
-     5.2.  Signature Sizes . . . . . . . . . . . . . . . . . . . . . . 5
-     5.3.  Digest Sizes  . . . . . . . . . . . . . . . . . . . . . . . 5
-   6.  Implementation Considerations . . . . . . . . . . . . . . . . . 5
-     6.1.  Support for GOST signatures . . . . . . . . . . . . . . . . 5
-     6.2.  Support for NSEC3 Denial of Existence . . . . . . . . . . . 5
-     6.3.  Byte order  . . . . . . . . . . . . . . . . . . . . . . . . 5
-   7. Security consideration . . . . . . . . . . . . . . . . . . . . . 5
-   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
-   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
-   10.  References   . . . . . . . . . . . . . . . . . . . . . . . . . 6
-     10.1.  Normative References . . . . . . . . . . . . . . . . . . . 6
-     10.2.  Informative References . . . . . . . . . . . . . . . . . . 7
-   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9
-
-1.  Introduction
-
-   The Domain Name System (DNS) is the global hierarchical distributed
-   database for Internet Naming.  The DNS has been extended to use
-   cryptographic keys and digital signatures for the verification of the
-   authenticity and integrity of its data.  RFC 4033 [RFC4033], RFC 4034
-   [RFC4034], and RFC 4035 [RFC4035] describe these DNS Security
-   Extensions, called DNSSEC.
-
-   RFC 4034 describes how to store DNSKEY and RRSIG resource records,
-   and specifies a list of cryptographic algorithms to use.  This
-   document extends that list with the signature and hash algorithms 
-   GOST [GOST3410, GOST3411],
-   and specifies how to store DNSKEY data and how to produce
-   RRSIG resource records with these hash algorithms.
-
-   Familiarity with DNSSEC  and GOST signature and hash
-   algorithms is assumed in this document.
-
-   The term "GOST" is not officially defined, but is usually used to
-   refer to the collection of the Russian cryptographic algorithms
-   GOST R 34.10-2001[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.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-V.Dolmatov              Expires September 06, 2010             [Page 2]
-
-2.  DNSKEY Resource Records
-
-   The format of the DNSKEY RR can be found in RFC 4034 [RFC4034].
-
-   GOST R 34.10-2001 public keys are stored with the algorithm number 
-   {TBA1}.
-      
-   The wire format of the public key is compatible with 
-   RFC 4491 [RFC4491]:
-
-   According to [GOST3410], a public key is a point on the elliptic
-   curve Q = (x,y).
-
-   The wire representation of a public key MUST contain 64 octets, 
-   where the first 32 octets contain the little-endian representation
-   of x and the second 32 octets contain the little-endian 
-   representation of y. 
-   This corresponds to the binary representation of (<y>256||<x>256) 
-   from [GOST3410], ch.  5.3.
-
-   Corresponding public key parameters are those identified by
-   id-GostR3410-2001-CryptoPro-A-ParamSet (1.2.643.2.2.35.1) [RFC4357],
-   and the digest parameters are those identified by
-   id-GostR3411-94-CryptoProParamSet (1.2.643.2.2.30.1) [RFC4357].
-
-2.1.  Using a public key with existing cryptographic libraries
-
-   Existing GOST-aware cryptographic libraries at the time of this 
-   document writing are capable to read GOST public keys via a generic
-   X509 API if the key is encoded according to RFC 4491 [RFC4491],
-   section 2.3.2.
-
-   To make this encoding from the wire format of a GOST public key 
-   with the parameters used in this document, prepend the 64 octets
-   of key data with the following 37-byte sequence:
-
-   0x30 0x63 0x30 0x1c 0x06 0x06 0x2a 0x85 0x03 0x02 0x02 0x13 0x30 
-   0x12 0x06 0x07 0x2a 0x85 0x03 0x02 0x02 0x23 0x01 0x06 0x07 0x2a
-   0x85 0x03 0x02 0x02 0x1e 0x01 0x03 0x43 0x00 0x04 0x40
-  
-2.2.  GOST DNSKEY RR Example
-
-   Given a private key with the following value (the value of GostAsn1
-   field is split here into two lines to simplify reading; in the 
-   private key file it must be in one line):
-
-   Private-key-format: v1.2
-   Algorithm: {TBA1} (ECC-GOST)
-   GostAsn1: MEUCAQAwHAYGKoUDAgITMBIGByqFAwICIwEGByqFAwICHgEEIgQgp9c
-             t2LQaNS1vMKPLEN9zHYjLPNMIQN6QB9vt3AghZFA=
- 
-
-V.Dolmatov              Expires September 06, 2010             [Page 3]
-
-   The following DNSKEY RR stores a DNS zone key for example.net
- 
-   example.net. 86400 IN DNSKEY 256 3 {TBA1} (
-                                GtTJjmZKUXV+lHLG/6crB6RCR+EJR51Islpa
-                                6FqfT0MUfKhSn1yAo92+LJ0GDssTiAnj0H0I
-                                9Jrfial/yyc5Og==
-                                ) ; key id = 10805
-
-3.  RRSIG Resource Records
-
-   The value of the signature field in the RRSIG RR follows RFC 4490
-   [RFC4490] and is calculated as follows.  The values for the RDATA 
-   fields that precede the signature data are specified 
-   in RFC 4034 [RFC4034].
-
-   hash = GOSTR3411(data)
-
-   where "data" is the wire format data of the resource record set 
-   that is signed, as specified in RFC 4034 [RFC4034].
-   
-   Hash MUST be calculated with GOST R 34.11-94 parameters identified
-   by id-GostR3411-94-CryptoProParamSet [RFC4357].
-
-   Signature is calculated from the hash according to the 
-   GOST R 34.10-2001 standard and its wire format is compatible with 
-   RFC 4490 [RFC4490].
-
-   Quoting RFC 4490:
-
-   "The signature algorithm GOST R 34.10-2001 generates a digital
-   signature in the form of two 256-bit numbers, r and s.  Its octet
-   string representation consists of 64 octets, where the first 32
-   octets contain the big-endian representation of s and the second 32
-   octets contain the big-endian representation of r."
-
-3.1. RRSIG RR Example
-
-   With the private key from section 2.2 sign the following RRSet, 
-   consisting of one A record:
-
-   www.example.net. 3600 IN A 192.0.2.1
-
-   Setting the inception date to 2000-01-01 00:00:00 UTC and the 
-   expiration date to 2030-01-01 00:00:00 UTC, the following signature
-   should be created (assuming {TBA1}==249 until proper code is 
-   assigned by IANA)
-
-   www.example.net. 3600 IN RRSIG A {TBA1} 3 3600 20300101000000 (
-                                  20000101000000 10805 example.net.
-                                  k3m0r5bm6kFQmcRlHshY3jIj7KL6KTUsPIAp
-                                  Vy466khKuWEUoVvSkqI+9tvMQySQgZcEmS0W
-                                  HRFSm0XS5YST5g== )
- 
-V.Dolmatov              Expires September 06, 2010             [Page 4]
-
-  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
-
-   GOST R 34.11-94 digest algorithm is denoted in DS RRs by the digest
-   type {TBA2}.The wire format of a digest value is compatible with 
-   RFC4490 [RFC4490], that is digest is in little-endian representation. 
-
-
-   The digest MUST always be calculated with GOST R 34.11-94 parameters
-   identified by id-GostR3411-94-CryptoProParamSet [RFC4357].
-
-4.1. DS RR Example
-
-   For key signing key (assuming {TBA1}==249 until proper code is 
-   assigned by IANA)
-
-   example.net. 86400   DNSKEY  257 3 {TBA1} (
-                                1aYdqrVz3JJXEURLMdmeI7H1CyTFfPVFBIGA
-                                EabZFP+7NT5KPYXzjDkRbPWleEFbBilDNQNi
-                                q/q4CwA4WR+ovg==
-                                ) ; key id = 6204
- 
-   The DS RR will be
-
-   example.net. 3600 IN DS 6204 {TBA1} {TBA2} (
-             0E6D6CB303F89DBCF614DA6E21984F7A62D08BDD0A05B3A22CC63D1B
-             553BC61E )
-
-5.  Deployment Considerations
-
-5.1.  Key Sizes
-
-   According to RFC4357 [RFC4357], the key size of GOST public keys
-   MUST be 512 bits.
-
-5.2.  Signature Sizes
-
-   According to the GOST signature algorithm specification [GOST3410],
-   the size of a GOST signature is 512 bits.
-
-5.3.  Digest Sizes
-
-   According to the GOST R 34.11-94 [GOST3411], the size of a GOST 
-   digest is 256 bits.
-
-6.  Implementation Considerations
-
-6.1.  Support for GOST signatures
-
-   DNSSEC aware implementations MAY be able to support RRSIG and
-   DNSKEY resource records created with the GOST algorithms as
-   defined in this document.
-
-V.Dolmatov              Expires September 06, 2010             [Page 5]
-
-6.2.  Support for NSEC3 Denial of Existence
-
-    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 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
-
-    Currently, the cryptographic resistance of the GOST 34.10-2001 
-    digital signature algorithm is estimated as 2**128 operations
-    of multiple elliptic curve point computations on prime modulus
-    of order 2**256.
-
-
-    Currently, the cryptographic resistance of GOST 34.11-94 hash
-    algorithm is estimated as 2**128 operations of computations of a
-    step hash function. (There is known method to reduce this 
-    estimate to 2**105 operations, but it demands padding the 
-    colliding message with 1024 random bit blocks each of 256 bit
-    length, thus it cannot be used in any practical implementation).
-
-8.  IANA Considerations
-
-   This document updates the IANA registry "DNS Security Algorithm 
-   Numbers" [RFC4034]
-   (http://www.iana.org/assignments/dns-sec-alg-numbers).  
-   The following entries are added to the registry:
-                                     Zone    Trans.
-   Value  Algorithm         Mnemonic Signing Sec.  References   Status
-   {TBA1} GOST R 34.10-2001 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
-   algorithm:
-
-   Value   Algorithm        Status
-   {TBA2}  GOST R 34.11-94  OPTIONAL
-
-9. Acknowledgments
-
-   This document is a minor extension to RFC 4034 [RFC4034].  Also, we
-   tried to follow the documents RFC 3110 [RFC3110], RFC 4509 [RFC4509],
-   and RFC 4357 [RFC4357] for consistency. The authors of and 
-   contributors to these documents are gratefully acknowledged for 
-   their hard work.
-
-V.Dolmatov              Expires September 06, 2010             [Page 6]
-
-   The following people provided additional feedback and text: Dmitry 
-   Burkov, Jaap Akkerhuis, Olafur Gundmundsson, Jelte Jansen 
-   and Wouter Wijngaards.
-
-
-10.  References
-
-10.1.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", RFC 2119, March 1997.
-
-   [RFC3110]  Eastlake D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain
-              Name System (DNS)", RFC 3110, May 2001.
-
-   [RFC4033]  Arends R., Austein R., Larson M., Massey D., and S.
-              Rose, "DNS Security Introduction and Requirements",
-              RFC 4033, March 2005.
-
-   [RFC4034]  Arends R., Austein R., Larson M., Massey D., and S.
-              Rose, "Resource Records for the DNS Security Extensions",
-              RFC 4034, March 2005.
-
-   [RFC4035]  Arends R., Austein R., Larson M., Massey D., and S.
-              Rose, "Protocol Modifications for the DNS Security
-              Extensions", RFC 4035, March 2005.
-
-   [GOST3410] "Information technology.  Cryptographic data security.
-              Signature and verification processes of [electronic]
-              digital signature.", GOST R 34.10-2001, Gosudarstvennyi
-              Standard of Russian Federation, Government Committee of
-              the Russia for Standards, 2001.  (In Russian)
-
-   [GOST3411] "Information technology.  Cryptographic Data Security.
-              Hashing function.", GOST R 34.11-94, Gosudarstvennyi
-              Standard of Russian Federation, Government Committee of
-              the Russia for Standards, 1994.  (In Russian)
-
-   [RFC4357] Popov V., Kurepkin I., and S. Leontiev, "Additional
-             Cryptographic Algorithms for Use with GOST 28147-89,
-             GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94
-             Algorithms", RFC 4357, January 2006.
-
-   [RFC4490] S. Leontiev and G. Chudov, "Using the GOST 28147-89, 
-             GOST R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001 
-             Algorithms with Cryptographic Message Syntax (CMS)",
-             RFC 4490, May 2006.
-
-   [RFC4491] S. Leontiev and D. Shefanovski, "Using the GOST 
-             R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 
-             Algorithms with the Internet X.509 Public Key 
-             Infrastructure Certificate and CRL Profile", RFC 4491,
-             May 2006. 
-
-V.Dolmatov              Expires 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
-
-   [RFC4509]  Hardaker W., "Use of SHA-256 in DNSSEC Delegation Signer
-              (DS) Resource Records (RRs)", RFC 4509, May 2006.
-
-   [DRAFT1]   Dolmatov V., Kabelev D., Ustinov I., Vyshensky S.,
-              "GOST R 34.10-2001 digital signature algorithm"
-              draft-dolmatov-cryptocom-gost34102001-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-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-08, 12.12.09
-              work in progress.
-
-V.Dolmatov              Expires September 06, 2010             [Page 8]
-
-
-Authors' Addresses
-
-
-Vasily Dolmatov, Ed.
-Cryptocom Ltd.
-Kedrova 14, bld.2
-Moscow, 117218, Russian Federation
-
-EMail: dol@cryptocom.ru
-
-Artem Chuprina
-Cryptocom Ltd.
-Kedrova 14, bld.2
-Moscow, 117218, Russian Federation
-
-EMail: ran@cryptocom.ru
-
-Igor Ustinov
-Cryptocom Ltd.
-Kedrova 14, bld.2
-Moscow, 117218, Russian Federation
-
-EMail: igus@cryptocom.ru
-
-V.Dolmatov              Expires September 06, 2010             [Page 9]
-
diff --git a/doc/draft/draft-ietf-dnsext-dnssec-registry-fixes-06.txt b/doc/draft/draft-ietf-dnsext-dnssec-registry-fixes-06.txt
new file mode 100644
index 000000000000..5ef96c42735f
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-dnssec-registry-fixes-06.txt
@@ -0,0 +1,448 @@
+
+
+
+DNS Extensions Working Group                                     S. Rose
+Internet-Draft                                                      NIST
+Updates: 2536, 2539, 3110, 4034,                         August 11, 2010
+4398, 5155, 5702, 5933
+(if approved)
+Intended status: Standards Track
+Expires: February 12, 2011
+
+
+  Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm IANA
+                                Registry
+               draft-ietf-dnsext-dnssec-registry-fixes-06
+
+Abstract
+
+   The DNS Security Extensions (DNSSEC) requires the use of
+   cryptographic algorithm suites for generating digital signatures over
+   DNS data.  There is currently an IANA registry for these algorithms
+   that is incomplete in that it lacks the implementation status of each
+   algorithm.  This document provides an applicability statement on
+   algorithm status for DNSSEC implementations.  This document replaces
+   that registry table with a new IANA registry table for Domain Name
+   System Security (DNSSEC) Algorithm Numbers which lists each
+   algorithm's status based on the current reference.  If that status is
+   not defined in the original specification, this document assigns a
+   status.
+
+Status of This Memo
+
+   This Internet-Draft is submitted to IETF in full conformance with the
+   provisions of BCP 78 and BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+
+
+
+Rose                    Expires February 12, 2011               [Page 1]
+
+Internet-Draft             IANA Registry Fixes               August 2010
+
+
+   This Internet-Draft will expire on February 12, 2011.
+
+Copyright Notice
+
+   Copyright (c) 2010 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the BSD License.
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
+     1.1.  Requirements Language . . . . . . . . . . . . . . . . . . . 3
+
+   2.  The DNS Security Algorithm Number Subregistry . . . . . . . . . 3
+     2.1.  Individual Changes  . . . . . . . . . . . . . . . . . . . . 3
+     2.2.  Domain Name System (DNS) Security Algorithm Number
+           Registry Table  . . . . . . . . . . . . . . . . . . . . . . 5
+     2.3.  Specifying New Algorithms and Updating Status of
+           Existing Entries  . . . . . . . . . . . . . . . . . . . . . 6
+
+   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
+
+   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
+
+   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
+     5.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
+     5.2.  Informative References  . . . . . . . . . . . . . . . . . . 8
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rose                    Expires February 12, 2011               [Page 2]
+
+Internet-Draft             IANA Registry Fixes               August 2010
+
+
+1.  Introduction
+
+   The Domain Name System (DNS) Security Extensions (DNSSEC) [RFC4033],
+   [RFC4034], and [RFC4035] uses digital signatures over DNS data to
+   provide source authentication and integrity protection.  DNSSEC uses
+   an IANA registry to allocate codes for digital signature algorithms
+   (consisting of a cryptographic algorithm and one-way hash function).
+
+   The original list of algorithm status is found in [RFC4034].  Other
+   DNSSEC documents have added new algorithms or changed the status of
+   algorithms in the registry.  However, currently implementors must
+   read through all the documents in order to discover the current
+   status of each algorithm in the registry.
+
+   This document replaces the current IANA registry for Domain Name
+   System Security (DNSSEC) Algorithm Numbers with a newly defined
+   registry table.  This new table (Section 2.2 below) contains a column
+   that will list the current status of each digital signature algorithm
+   in the registry at the time of writing and assigns status for some
+   algorithms used with DNSSEC that did not have an identified status in
+   their specification.  This document updates the following: [RFC2536],
+   [RFC2539], [RFC3110], [RFC4034], [RFC4398], [RFC5155], [RFC5702], and
+   [RFC5933].
+
+1.1.  Requirements Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+2.  The DNS Security Algorithm Number Subregistry
+
+   The DNS Security Algorithm Number subregistry (part of the Domain
+   Name System (DNS) Security Number registry) will be replaced with the
+   table below.  This table contains a column that contains the current
+   implementation requirements of the given algorithm.
+
+   There are additional differences to entries that are described in
+   sub-section 2.1.  The overall new registry table is in sub-section
+   2.2.  The values for the status were obtained from [RFC4034] with
+   updates for algorithms specified after the original DNSSEC
+   specification.  If no status was listed in the original
+   specification, this document assigns one.
+
+2.1.  Individual Changes
+
+   This document changes three entries in the Domain Name System
+   Security (DNSSEC) Algorithm Registry.  They are:
+
+
+
+Rose                    Expires February 12, 2011               [Page 3]
+
+Internet-Draft             IANA Registry Fixes               August 2010
+
+
+   The description for assignment number 4 is changed to "Reserved until
+   2020".
+
+   The description for assignment number 9 is changed to "Reserved until
+   2020".
+
+   The description for assignment number 11 is changed to "Reserved
+   until 2020".
+
+   Registry entries 13-251 remains Unassigned.
+
+   The status of RSASHA1-NSEC3-SHA1 and DSA-NSEC3-SHA1 are set to
+   RECOMMENDED and OPTIONAL respectively.  The difference is due to the
+   fact that RSA/SHA-1 is REQUIRED and DSA/SHA-1 is only OPTIONAL.  The
+   status of RSA/SHA-256 and RSA/SHA-512 are set to RECOMMENDED as it is
+   believed that these algorithms will replace older algorithms (e.g.
+   RSA/SHA-1) that have a perceived weakness in their hash algorithm
+   (SHA-1).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rose                    Expires February 12, 2011               [Page 4]
+
+Internet-Draft             IANA Registry Fixes               August 2010
+
+
+2.2.  Domain Name System (DNS) Security Algorithm Number Registry Table
+
+   The Domain Name System (DNS) Security Algorithm Number registry is
+   hereby specified as follows:
+
+                                  Zone  Transaction
+Number  Description    Mnemonic   Sign  Sign     Status       Reference
+------  -----------     ------    ----  -----  ------------   ---------
+  0      Reserved                                             [RFC4398]
+  1      RSA/MD5         RSAMD5     N     Y     MUST NOT      [RFC4034],
+                                                IMPLEMENT     [RFC3110]
+                                                             (this memo)
+  2      Diffie-Hellman   DH        N     Y                   [RFC2539]
+                                                             (this memo)
+  3      DSA/SHA-1       DSASHA1    Y     Y                   [RFC2536],
+                                                              [RFC4034],
+                                                             FIPS 186-3,
+                                                             FIPS 180-3
+                                                             (this memo)
+  4      Reserved until   ECC                                (this memo)
+         2020
+  5      RSA/SHA-1       RSASHA1    Y     Y     REQUIRED      [RFC4034]
+                                                             (this memo)
+  6      DSA-NSEC3-SHA1  DSA-NSEC3  Y     Y                   [RFC5155]
+                         -SHA1                               (this memo)
+  7      RSASHA1-NSEC3   RSASHA1-   Y     Y    RECOMMENDED    [RFC5155]
+         -SHA1           NSEC3-                              (this memo)
+                         SHA1
+  8      RSA/SHA-256     RSASHA256  Y     *    RECOMMENDED     [RFC5702]
+                                                             (this memo)
+  9      Reserved until                                      (this memo)
+         2020
+ 10      RSA/SHA-512     RSASHA512  Y     *    RECOMMENDED    [RFC5702]
+                                                             (this memo)
+ 11      Reserved until                                      (this memo)
+         2020
+ 12      GOST R          GOST-ECC   Y     *                   [RFC5933]
+         34.10-2001                                          (this memo)
+13-251   Unassigned
+ 252     Reserved for    INDIRECT   N     N                   [RFC4034]
+         Indirect keys                                       (this memo)
+ 253     private         PRIVATE    Y     Y                   [RFC4034]
+         algorithm                                           (this memo)
+ 254     private         PRIVATEOID Y     Y                   [RFC4034]
+         algorithm OID                                       (this memo)
+ 255     Reserved
+
+
+
+
+
+Rose                    Expires February 12, 2011               [Page 5]
+
+Internet-Draft             IANA Registry Fixes               August 2010
+
+
+2.3.  Specifying New Algorithms and Updating Status of Existing Entries
+
+   [I-D.ietf-dnsext-dnssec-alg-allocation] establishes a parallel
+   procedure for obtaining an algorithm number for new algorithms other
+   than a standards track document.  Algorithms entered into the
+   registry using that procedure do not have a listed status.
+   Specifications that follow this path do not need to obsolete or
+   update this document.
+
+   Adding a newly specified algorithm to the registry with a status
+   SHALL entail obsoleting this document and replacing the registry
+   table (with the new algorithm entry).  Altering the status column
+   value of any existing algorithm in the registry SHALL entail
+   obsoleting this document and replacing the registry table.
+
+   This document cannot be updated, only made obsolete and replaced by a
+   successor document.
+
+3.  IANA Considerations
+
+   This document replaces the Domain Name System (DNS) Security
+   Algorithm Numbers registry.  The new registry table is in Section
+   2.2.
+
+   The original Domain Name System (DNS) Security Algorithm Number
+   registry is available at http://www.iana.org/assignments/
+   dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml.
+
+4.  Security Considerations
+
+   This document replaces the Domain Name System (DNS) Security
+   Algorithm Numbers registry.  It is not meant to be a discussion on
+   algorithm superiority.  No new security considerations are raised in
+   this document.
+
+5.  References
+
+5.1.  Normative References
+
+   [I-D.ietf-dnsext-dnssec-alg-allocation]  Hoffman, P., "Cryptographic
+                                            Algorithm Identifier
+                                            Allocation for DNSSEC", draf
+                                            t-ietf-dnsext-dnssec-alg-
+                                            allocation-03 (work in
+                                            progress), March 2010.
+
+   [RFC2119]                                Bradner, S., "Key words for
+                                            use in RFCs to Indicate
+
+
+
+Rose                    Expires February 12, 2011               [Page 6]
+
+Internet-Draft             IANA Registry Fixes               August 2010
+
+
+                                            Requirement Levels", BCP 14,
+                                            RFC 2119, March 1997.
+
+   [RFC2536]                                Eastlake, D., "DSA KEYs and
+                                            SIGs in the Domain Name
+                                            System (DNS)", RFC 2536,
+                                            March 1999.
+
+   [RFC2539]                                Eastlake, D., "Storage of
+                                            Diffie-Hellman Keys in the
+                                            Domain Name System (DNS)",
+                                            RFC 2539, March 1999.
+
+   [RFC3110]                                Eastlake, D., "RSA/SHA-1
+                                            SIGs and RSA KEYs in the
+                                            Domain Name System (DNS)",
+                                            RFC 3110, May 2001.
+
+   [RFC4033]                                Arends, R., Austein, R.,
+                                            Larson, M., Massey, D., and
+                                            S. Rose, "DNS Security
+                                            Introduction and
+                                            Requirements", RFC 4033,
+                                            March 2005.
+
+   [RFC4034]                                Arends, R., Austein, R.,
+                                            Larson, M., Massey, D., and
+                                            S. Rose, "Resource Records
+                                            for the DNS Security
+                                            Extensions", RFC 4034,
+                                            March 2005.
+
+   [RFC4035]                                Arends, R., Austein, R.,
+                                            Larson, M., Massey, D., and
+                                            S. Rose, "Protocol
+                                            Modifications for the DNS
+                                            Security Extensions",
+                                            RFC 4035, March 2005.
+
+   [RFC4398]                                Josefsson, S., "Storing
+                                            Certificates in the Domain
+                                            Name System (DNS)",
+                                            RFC 4398, March 2006.
+
+   [RFC5155]                                Laurie, B., Sisson, G.,
+                                            Arends, R., and D. Blacka,
+                                            "DNS Security (DNSSEC)
+                                            Hashed Authenticated Denial
+
+
+
+Rose                    Expires February 12, 2011               [Page 7]
+
+Internet-Draft             IANA Registry Fixes               August 2010
+
+
+                                            of Existence", RFC 5155,
+                                            March 2008.
+
+   [RFC5702]                                Jansen, J., "Use of SHA-2
+                                            Algorithms with RSA in
+                                            DNSKEY and RRSIG Resource
+                                            Records for DNSSEC",
+                                            RFC 5702, October 2009.
+
+   [RFC5933]                                Dolmatov, V., Chuprina, A.,
+                                            and I. Ustinov, "Use of GOST
+                                            Signature Algorithms in
+                                            DNSKEY and RRSIG Resource
+                                            Records for DNSSEC",
+                                            RFC 5933, July 2010.
+
+5.2.  Informative References
+
+   [FIPS.180-3.2008]                        National Institute of
+                                            Standards and Technology,
+                                            "Secure Hash Standard",
+                                            FIPS PUB 180-3,
+                                            October 2008, <http://
+                                            csrc.nist.gov/publications/
+                                            fips/fips180-3/
+                                            fips180-3.pdf>.
+
+   [FIPS.186-3.2009]                        National Institute of
+                                            Standards and Technology,
+                                            "Digital Signature
+                                            Standard", FIPS PUB 186-3,
+                                            June 2009, <http://
+                                            csrc.nist.gov/publications/
+                                            fips/fips186-3/
+                                            fips_186-3.pdf>.
+
+Author's Address
+
+   Scott Rose
+   NIST
+   100 Bureau Dr.
+   Gaithersburg, MD  20899
+   USA
+
+   Phone: +1-301-975-8439
+   EMail: scottr.nist@gmail.com
+
+
+
+
+
+Rose                    Expires February 12, 2011               [Page 8]
+
diff --git a/doc/draft/draft-ietf-dnsop-dnssec-key-timing-00.txt b/doc/draft/draft-ietf-dnsop-dnssec-key-timing-00.txt
new file mode 100644
index 000000000000..6028ee89d64b
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsop-dnssec-key-timing-00.txt
@@ -0,0 +1,1960 @@
+
+
+
+Internet Engineering Task Force                                S. Morris
+Internet-Draft                                                       ISC
+Intended status: Informational                                  J. Ihren
+Expires: January 2, 2011                                          Netnod
+                                                            J. Dickinson
+                                                                 Sinodun
+                                                            July 1, 2010
+
+
+                    DNSSEC Key Timing Considerations
+               draft-ietf-dnsop-dnssec-key-timing-00.txt
+
+Abstract
+
+   This document describes the issues surrounding the timing of events
+   in the rolling of a key in a DNSSEC-secured zone.  It presents
+   timelines for the key rollover and explicitly identifies the
+   relationships between the various parameters affecting the process.
+
+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 January 2, 2011.
+
+Copyright Notice
+
+   Copyright (c) 2010 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+
+
+
+Morris, et al.           Expires January 2, 2011                [Page 1]
+
+Internet-Draft      DNSSEC Key Timing Considerations           July 2010
+
+
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+     1.1.  Key Rolling Considerations . . . . . . . . . . . . . . . .  3
+     1.2.  Types of Keys  . . . . . . . . . . . . . . . . . . . . . .  4
+     1.3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
+   2.  Rollover Methods . . . . . . . . . . . . . . . . . . . . . . .  4
+     2.1.  ZSK Rollovers  . . . . . . . . . . . . . . . . . . . . . .  4
+     2.2.  KSK Rollovers  . . . . . . . . . . . . . . . . . . . . . .  6
+     2.3.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . .  7
+   3.  Key Rollover Timelines . . . . . . . . . . . . . . . . . . . .  8
+     3.1.  Key States . . . . . . . . . . . . . . . . . . . . . . . .  8
+     3.2.  Zone-Signing Key Timelines . . . . . . . . . . . . . . . .  9
+       3.2.1.  Pre-Publication Method . . . . . . . . . . . . . . . .  9
+       3.2.2.  Double-Signature Method  . . . . . . . . . . . . . . . 13
+       3.2.3.  Double-RRSIG Method  . . . . . . . . . . . . . . . . . 14
+     3.3.  Key-Signing Key Rollover Timelines . . . . . . . . . . . . 17
+       3.3.1.  Double-Signature Method  . . . . . . . . . . . . . . . 17
+       3.3.2.  Double-DS Method . . . . . . . . . . . . . . . . . . . 20
+       3.3.3.  Double-RRset Method  . . . . . . . . . . . . . . . . . 22
+       3.3.4.  Interaction with Configured Trust Anchors  . . . . . . 25
+         3.3.4.1.  Addition of KSK  . . . . . . . . . . . . . . . . . 25
+         3.3.4.2.  Removal of KSK . . . . . . . . . . . . . . . . . . 25
+       3.3.5.  Introduction of First KSK  . . . . . . . . . . . . . . 26
+   4.  Standby Keys . . . . . . . . . . . . . . . . . . . . . . . . . 27
+   5.  Algorithm Considerations . . . . . . . . . . . . . . . . . . . 28
+   6.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
+   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 28
+   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 28
+   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
+   10. Change History . . . . . . . . . . . . . . . . . . . . . . . . 29
+   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
+     11.1. Normative References . . . . . . . . . . . . . . . . . . . 30
+     11.2. Informative References . . . . . . . . . . . . . . . . . . 30
+   Appendix A.  List of Symbols . . . . . . . . . . . . . . . . . . . 30
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
+
+
+
+
+
+
+
+
+
+
+
+Morris, et al.           Expires January 2, 2011                [Page 2]
+
+Internet-Draft      DNSSEC Key Timing Considerations           July 2010
+
+
+1.  Introduction
+
+1.1.  Key Rolling Considerations
+
+   When a zone is secured with DNSSEC, the zone manager must be prepared
+   to replace ("roll") the keys used in the signing process.  The
+   rolling of keys may be caused by compromise of one or more of the
+   existing keys, or it may be due to a management policy that demands
+   periodic key replacement for security or operational reasons.  In
+   order to implement a key rollover, the keys need to be introduced
+   into and removed from the zone at the appropriate times.
+   Considerations that must be taken into account are:
+
+   o  DNSKEY records and associated information (such as RRSIG records
+      created with the key or the associated DS records) are not only
+      held at the authoritative nameserver, they are also cached at
+      client resolvers.  The data on these systems can be interlinked,
+      e.g. a validating resolver may try to validate a signature
+      retrieved from a cache with a key obtained separately.
+
+   o  A query for the key RRset returns all DNSKEY records in the zone.
+      As there is limited space in the UDP packet (even with EDNS0
+      support), dead key records must be periodically removed.  (For the
+      same reason, the number of stand-by keys in the zone should be
+      restricted to the minimum required to support the key management
+      policy.)
+
+   o  Zone "boot-strapping" events, where a zone is signed for the first
+      time, can be common in configurations where a large number of
+      zones are being served.  Procedures should be able to cope with
+      the introduction of keys into the zone for the first time as well
+      as "steady-state", where the records are being replaced as part of
+      normal zone maintenance.
+
+   o  To allow for an emergency re-signing of the zone as soon as
+      possible after a key compromise has been detected, stand-by keys
+      (additional keys over and above those used to sign the zone) need
+      to be present.
+
+   Management policy, e.g. how long a key is used for, also needs to be
+   considered.  However, the point of key management logic is not to
+   ensure that a "rollover" is completed at a certain time but rather to
+   ensure that no changes are made to the state of keys published in the
+   zone until it is "safe" to do so ("safe" in this context meaning that
+   at no time during the rollover process does any part of the zone ever
+   go bogus).  In other words, although key management logic enforces
+   policy, it may not enforce it strictly.
+
+
+
+
+Morris, et al.           Expires January 2, 2011                [Page 3]
+
+Internet-Draft      DNSSEC Key Timing Considerations           July 2010
+
+
+1.2.  Types of Keys
+
+   Although DNSSEC validation treats all keys equally, [RFC4033]
+   recognises the broad classification of zone-signing keys (ZSK) and
+   key-signing keys (KSK).  A ZSK is used to authenticate information
+   within the zone; a KSK is used to authenticate the key set in the
+   zone.  The main implication for this distinction concerns the
+   consistency of information during a rollover.
+
+   During operation, a validating resolver must use separate pieces of
+   information to perform an authentication.  At the time of
+   authentication, each piece of information may be in the validating
+   resolver's cache or may need to be retrieved from the authoritative
+   server.  The rollover process needs to happen in such a way that at
+   all times through the rollover the information is consistent.  With a
+   ZSK, the information is the RRSIG (plus associated RRset) and the
+   DNSKEY.  These are both obtained from the same zone.  In the case of
+   the KSK, the information is the DNSKEY and DS RRset with the latter
+   being obtained from a different zone.
+
+   There are similarities in the rolling of ZSKs and KSKs: replace the
+   RRSIG (plus RR) by the DNSKEY and replace the DNSKEY by the DS, and
+   the ZSK rolling algorithms are virtually the same as the KSK
+   algorithms.  However, there are a number of differences, and for this
+   reason the two types of rollovers are described separately in this
+   document.
+
+1.3.  Terminology
+
+   The terminology used in this document is as defined in [RFC4033] and
+   [RFC5011].
+
+   A large number of symbols are used to identify times, intervals, etc.
+   All are listed in Appendix A.
+
+
+2.  Rollover Methods
+
+2.1.  ZSK Rollovers
+
+   A ZSK can be rolled in one of three ways:
+
+   o  Pre-Publication.  Described in [RFC4641], the new key is
+      introduced into the DNSKEY RRset, leaving the existing keys and
+      signatures in place.  This state of affairs remains in place for
+      long enough to ensure that any DNSKEY RRsets cached in client
+      validating resolvers contain both keys.  At that point signatures
+      created with the old key can be replaced by those created with the
+
+
+
+Morris, et al.           Expires January 2, 2011                [Page 4]
+
+Internet-Draft      DNSSEC Key Timing Considerations           July 2010
+
+
+      new key, and the old signatures removed.  During the re-signing
+      process (which may or may not be atomic depending on how the zone
+      is managed), it doesn't matter which key an RRSIG record retrieved
+      by a client was created with; clients with a cached copy of the
+      DNSKEY RRset will have a copy containing both the old and new
+      keys.
+
+      Once the zone contains only signatures created with the new key,
+      there is an interval during which RRSIG records created with the
+      old key expire from client caches.  After this, there will be no
+      signatures anywhere that were created using the old key, and it
+      can can be removed from the DNSKEY RRset.
+
+   o  Double-Signature.  Also mentioned in [RFC4641], this involves
+      introducing the new key into the zone and using it to create
+      additional RRSIG records; the old key and existing RRSIG records
+      are retained.  During the period in which the zone is being signed
+      (again, the signing process may not be atomic), client resolvers
+      are always able to validate RRSIGs: any combination of old and new
+      DNSKEY RRset and RRSIG allows at least one signature to be
+      validated.
+
+      Once the signing process is complete and enough time has elapsed
+      to allow all old information to expire from caches, the old key
+      and signatures can be removed from the zone.  As before, during
+      this period any combination of DNSKEY RRset and RRSIG will allow
+      validation of at least one signature.
+
+   o  Double-RRSIG.  Strictly speaking, the use of the term "Double-
+      Signature" above is a misnomer as the method is not only double
+      signature, it is also double key as well.  A true Double-Signature
+      method (here called the Double-RRSIG method) involves introducing
+      new signatures in the zone (while still retaining the old ones)
+      but not the new key.
+
+      Once the signing process is complete and enough time has elapsed
+      to ensure that all caches that may contain an RR and associated
+      RRSIG to have a copy of both signatures, the ZSK is changed.
+      After a further interval during which the old DNSKEY RRset expires
+      from caches, the old signatures are removed from the zone.
+
+   Of three methods, Double-Signature is the simplest conceptually -
+   introduce the new key and new signatures, then approximately one TTL
+   later remove the old key and signatures.  The drawback of this method
+   is a noticeable increase in the size of the DNSSEC data, affecting
+   both the overall size of the zone and the size of the responses.
+
+   Pre-Publication is more complex - introduce the new key,
+
+
+
+Morris, et al.           Expires January 2, 2011                [Page 5]
+
+Internet-Draft      DNSSEC Key Timing Considerations           July 2010
+
+
+   approximately one TTL later sign the records, and approximately one
+   TTL after that remove the old key.  However, the amount of DNSSEC
+   data is kept to a minimum which reduces the impact on performance.
+
+   The Double-RRSIG combines the increase in data volume of the Double-
+   Signature method with the complexity of Pre-Publication.  It has few
+   (if any) advantages and a description is only included here for
+   completeness.
+
+2.2.  KSK Rollovers
+
+   In the ZSK case the issue for the validating resolver is to ensure
+   that it has access to the ZSK that corresponds to a particular
+   signature.  In the KSK case this can never be a problem as the KSK is
+   only used for one signature (that over the DNSKEY RRset) and both the
+   key the signature travel together.  Instead, the issue is to ensure
+   that the KSK is trusted.
+
+   Trust in the KSK is either due to the existence of an explicitly
+   configured trust anchor in the validating resolver or DS record in
+   the parent zone (which is itself trusted).  If the former, [RFC5011]
+   timings will be needed to roll the keys.  If the latter, the rollover
+   algorithm will need to involve the parent zone in the addition and
+   removal of DS records, so timings are not wholly under the control of
+   the zone manager.  (The zone manager may elect to include [RFC5011]
+   timings in the key rolling process so as to cope with the possibility
+   that the key has also been explicitly configured as a trust anchor.)
+
+   It is important to note that this does not preclude the development
+   of key rollover logic; in accordance with the goal of the rollover
+   logic being able to determine when a state change is "safe", the only
+   effect of being dependent on the parent is that there may be a period
+   of waiting for the parent to respond in addition to any delay the key
+   rollover logic requires.  Although this introduces additional delays,
+   even with a parent that is less than ideally responsive the only
+   effect will be a slowdown in the rollover state transitions.  This
+   may cause a policy violation, but will not cause any operational
+   problems.
+
+   Like the ZSK case, there are three methods for rolling a KSK:
+
+   o  Double-Signature: Also known as Double-DNSKEY, the new KSK is
+      added to the DNSKEY RRset which is then signed with both the old
+      and new key.  After waiting for the old RRset to expire from
+      caches, the DS record in the parent zone is changed.  After
+      waiting a further interval for this change to be reflected in
+      caches, the old key is removed from the RRset.  (The name "Double-
+      Signature" is used because, like the ZSK method of the same name,
+
+
+
+Morris, et al.           Expires January 2, 2011                [Page 6]
+
+Internet-Draft      DNSSEC Key Timing Considerations           July 2010
+
+
+      the new key is introduced and immediately used for signing.)
+
+   o  Double-DS: the new DS record is published.  After waiting for this
+      change to propagate into the caches of all validating resolvers,
+      the KSK is changed.  After a further interval during which the old
+      DNSKEY RRset expires from caches, the old DS record is removed.
+
+   o  Double-RRset: the new KSK is added to the DNSKEY RRset which is
+      then signed with both the old and new key, and the new DS record
+      added to the parent zone.  After waiting a suitable interval for
+      the old DS and DNSKEY RRsets to expire from validating resolver
+      caches, the old DNSKEY and DS record are removed.
+
+   In essence, "Double-Signature" means that the new KSK is introduced
+   first and used to sign the DNSKEY RRset.  The DS record is changed,
+   and finally the old KSK removed.  With "Double-DS" it is the other
+   way around.  Finally, Double-RRset does both updates more or less in
+   parallel.
+
+   The strategies have different advantages and disadvantages:
+
+   o  Double-Signature minimizes the number of interactions with the
+      parent zone.  However, for the period of the rollover the DNSKEY
+      RRset is signed with two KSKs, so increasing the size of the
+      response to a query for this data.
+
+   o  Double-DS keeps the size of the DNSKEY RRset to a minimum, but
+      does require the additional administrative overhead of two
+      interactions with the parent to roll a KSK.  (Although this can be
+      mitigated if the parent has the ability for a child zone to
+      schedule the withdrawal of the old key at the same time as the
+      introduction of the new one.)
+
+   o  Finally, Double-RRset allows the rollover to be done in roughly
+      half the time of the other two methods; it also supports policies
+      that require a period of running with old and new KSKs
+      simultaneously.  However, it does have the disadvantages of both
+      the other two methods - it requires two signatures during the
+      period of the rollover and two interactions with the parent.
+
+2.3.  Summary
+
+   The methods can be summarised as follows:
+
+
+
+
+
+
+
+
+Morris, et al.           Expires January 2, 2011                [Page 7]
+
+Internet-Draft      DNSSEC Key Timing Considerations           July 2010
+
+
+   +------------------+------------------+-----------------------------+
+   | ZSK Method       | KSK Method       | Description                 |
+   +------------------+------------------+-----------------------------+
+   | Pre-Publication  | (not applicable) | Publish the DNSKEY before   |
+   |                  |                  | the RRSIG.                  |
+   | Double-Signature | Double-Signature | Publish the DNSKEY and      |
+   |                  |                  | RRSIG at same time.  (For a |
+   |                  |                  | KSK, this happens before    |
+   |                  |                  | the DS is published.)       |
+   | Double-RRSIG     | (not applicable) | Publish RRSIG before the    |
+   |                  |                  | DNSKEY.                     |
+   | (not applicable) | Double-DS        | Publish DS before the       |
+   |                  |                  | DNSKEY.                     |
+   | (not applicable) | Double-RRset     | Publish DNSKEY and DS in    |
+   |                  |                  | parallel.                   |
+   +------------------+------------------+-----------------------------+
+
+                                  Table 1
+
+
+3.  Key Rollover Timelines
+
+3.1.  Key States
+
+   During the rolling process, a key moves through different states.
+   These states are:
+
+   Generated   The key has been created, but has not yet been used for
+               anything.
+
+   Published   The DNSKEY record - or information associated with it -
+               is published in the zone, but predecessors of the key (or
+               associated information) may be held in resolver caches.
+
+               The idea of "associated information" is used in rollover
+               methods where RRSIG or DS records are published first and
+               the DNSKEY is changed in an atomic operation.  It allows
+               the rollover still to be thought of as moving through a
+               set of states.  In the rest of this section, the term
+               "key" should be taken to mean "key or associated
+               information".
+
+   Ready       The key has been published for long enough to guarantee
+               that all caches that might contain a copy of the key
+               RRset have a copy that includes this key.
+
+
+
+
+
+
+Morris, et al.           Expires January 2, 2011                [Page 8]
+
+Internet-Draft      DNSSEC Key Timing Considerations           July 2010
+
+
+   Active      The key is in the zone and has started to be used to sign
+               RRsets or authenticate the DNSKEY RRset.  Note that when
+               this state is entered, it might not be possible for every
+               validating resolver to use the key for validation: the
+               zone signing may not have finished, or the data might not
+               have reached the resolver because of propagation delays
+               and/or caching issues.  If this is the case, the resolver
+               will have to rely on the key's predecessor instead.
+
+   Retired     The key is in the zone but a successor key has become
+               active.  As there may still be information in caches that
+               that require use of the key, it is being retained until
+               this information expires.
+
+   Dead        The key is published in the zone but there is no
+               information anywhere that requires its presence.
+
+   Removed     The key has been removed from the zone.
+
+   There is one additional state, used where [RFC5011] considerations
+   are in effect (see Section 3.3.4):
+
+   Revoked     The key is published for a period with the "revoke" bit
+               set as a way of notifying validating resolvers that have
+               configured it as a trust anchor that it is about to be
+               removed from the zone.
+
+3.2.  Zone-Signing Key Timelines
+
+3.2.1.  Pre-Publication Method
+
+   The following diagram shows the time line of a particular ZSK and its
+   replacement by its successor using the Pre-Publication method.  Time
+   increases along the horizontal scale from left to right and the
+   vertical lines indicate events in the life of the key.  The events
+   are numbered; significant times and time intervals are marked.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Morris, et al.           Expires January 2, 2011                [Page 9]
+
+Internet-Draft      DNSSEC Key Timing Considerations           July 2010
+
+
+            |1|  |2|      |3|   |4|   |5|      |6| |7|      |8|   |9|
+             |    |        |     |     |        |   |        |     |
+     Key N   |    |<-Ipub->|<--->|<-------Lzsk----->|<-Iret->|<--->|
+             |    |        |     |     |        |   |        |     |
+     Key N+1 |    |        |     |     |<-Ipub->|<->|<---Lzsk-- - -
+             |    |        |     |     |        |   |        |     |
+            Tgen Tpub     Trdy  Tact  TpubS        Tret     Tdea  Trem
+
+                             ---- Time ---->
+
+
+          Figure 1: Timeline for a Pre-Publication ZSK rollover.
+
+   Event 1: key N is generated at the generate time (Tgen).  Although
+   there is no reason why the key cannot be generated immediately prior
+   to publication in the zone (Event 2), some implementations may find
+   it convenient to create a pool of keys in one operation and draw from
+   that pool as required.  For this reason, it is shown as a separate
+   event.  Keys that are available for use but not published are said to
+   be generated.
+
+   Event 2: key N's DNSKEY record is put into the zone, i.e. it is added
+   to the DNSKEY RRset which is then re-signed with the current key-
+   signing key.  The time at which this occurs is the key's publication
+   time (Tpub), and the key is now said to be published.  Note that the
+   key is not yet used to sign records.
+
+   Event 3: before it can be used, the key must be published for long
+   enough to guarantee that any resolver that has a copy of the DNSKEY
+   RRset from the zone in its cache will have a copy of the RRset that
+   includes this key: in other words, that any prior cached information
+   about the DNSKEY RRset has expired.
+
+   This interval is the publication interval (Ipub) and, for the second
+   or subsequent keys in the zone, is given by:
+
+             Ipub = Dprp + TTLkey
+
+   Here, Dprp is the propagation delay - the time taken for any change
+   introduced at the master to replicate to all slave servers - which
+   depends on the depth of the master-slave hierarchy.  TTLkey is the
+   time-to-live (TTL) for the DNSKEY records in the zone.  The sum is
+   therefore the time taken for existing DNSKEY records to expire from
+   the caches of downstream validating resolvers, regardless of the
+   nameserver from which they were retrieved.
+
+   In the case of the first key in the zone, Ipub is slightly different
+   because it is not information about a DNSKEY RRset that may be
+
+
+
+Morris, et al.           Expires January 2, 2011               [Page 10]
+
+Internet-Draft      DNSSEC Key Timing Considerations           July 2010
+
+
+   cached, it is information about its absence.  In this case:
+
+             Ipub = Dprp + Ingc
+
+   where Ingc is the negative cache interval from the zone's SOA record,
+   calculated according to [RFC2308] as the minimum of the TTL of the
+   SOA record itself (TTLsoa), and the "minimum" field in the record's
+   parameters (SOAmin), i.e.
+
+             Ingc = min(TTLsoa, SOAmin)
+
+   After a delay of Ipub, the key is said to be ready and could be used
+   to sign records.  The time at which this event occurs is the key's
+   ready time (Trdy), which is given by:
+
+             Trdy = Tpub + Ipub
+
+   Event 4: at some later time, the key starts being used to sign
+   RRsets.  This point is the active time (Tact) and after this, the key
+   is said to be active.
+
+   Event 5: while this key is active, thought must be given to its
+   successor (key N+1).  As with the introduction of the currently
+   active key into the zone, the successor key will need to be published
+   at least Ipub before it is used.  Denoting the publication time of
+   the successor key by TpubS, then:
+
+             TpubS <= Tact + Lzsk - Ipub
+
+   Here, Lzsk is the length of time for which a ZSK will be used (the
+   ZSK lifetime).  It should be noted that unlike the publication
+   interval, Lzsk is not determined by timing logic, but by key
+   management policy.  Lzsk will be set by the operator according to
+   their assessment of the risks posed by continuing to use a key and
+   the risks associated with key rollover.  However, operational
+   considerations may mean a key is active for slightly more or less
+   than Lzsk.
+
+   Event 6: while the key N is still active, its successor becomes
+   ready.  From this time onwards, it could be used to sign the zone.
+
+   Event 7: at some point the decision is made to start signing the zone
+   using the successor key.  This will be when the current key has been
+   in use for an interval equal to the ZSK lifetime, hence:
+
+             Tret = Tact + Lzsk
+
+   This point in time is the retire time (Tret) of key N; after this the
+
+
+
+Morris, et al.           Expires January 2, 2011               [Page 11]
+
+Internet-Draft      DNSSEC Key Timing Considerations           July 2010
+
+
+   key is said to be retired.  (This time is also the point at which the
+   successor key becomes active.)
+
+   Event 8: the retired key needs to be retained in the zone whilst any
+   RRSIG records created using this key are still published in the zone
+   or held in resolver caches.  (It is possible that a resolver could
+   have an unexpired RRSIG record and an expired DNSKEY RRset in the
+   cache when it is asked to provide both to a client.  In this case the
+   DNSKEY RRset would need to be looked up again.)  This means that once
+   the key is no longer used to sign records, it should be retained in
+   the zone for at least the retire interval (Iret) given by:
+
+             Iret = Dsgn + Dprp + TTLsig
+
+   Dsgn is the delay needed to ensure that all existing RRsets have been
+   re-signed with the new key.  Dprp is (as described above) the
+   propagation delay, required to guarantee that the updated zone
+   information has reached all slave servers, and TTLsig is the TTL of
+   the RRSIG records.
+
+   (It should be noted that an upper limit on the retire interval is
+   given by:
+
+             Iret = Lsig + Dskw
+
+   where Lsig is the lifetime of a signature (i.e. the interval between
+   the time the signature was created and the signature end time), and
+   Dskw is the clock skew - the maximum difference in time between the
+   server and a validating resolver.  The reasoning here is that
+   whatever happens, a key only has to be available while any signatures
+   created with it are valid.  Wherever a signature record is held -
+   published in the zone and/or held in a resolver cache - it won't be
+   valid for longer than Lsig after it was created.  The Dskw term is
+   present to account for the fact that the signature end time is an
+   absolute time rather than interval, and systems may not agree exactly
+   about the time.)
+
+   The time at which all RRSIG records created with this key have
+   expired from resolver caches is the dead time (Tdea), given by:
+
+             Tdea = Tret + Iret
+
+   ...at which point the key is said to be dead.
+
+   Event 9: at any time after the key becomes dead, it can be removed
+   from the zone and the DNSKEY RRset re-signed with the current key-
+   signing key.  This time is the removal time (Trem), given by:
+
+
+
+
+Morris, et al.           Expires January 2, 2011               [Page 12]
+
+Internet-Draft      DNSSEC Key Timing Considerations           July 2010
+
+
+             Trem >= Tdea
+
+   ...at which time the key is said to be removed.
+
+3.2.2.  Double-Signature Method
+
+   In the Double-Signature method, both the new key and signatures
+   created using it are introduced at the same time.  After a period
+   during which this information propagates to validating resolver
+   caches, the old key and signature are removed.  The time line for the
+   method is shown below:
+
+
+
+               |1|  |2|            |3|  |4|              |5|  |6|
+                |    |              |    |                |    |
+        Key N   |    |<-------Lzsk------>|<-----Iret----->|    |
+                |    |              |    |                |    |
+        Key N+1 |    |              |    |<----------Lzsk------- - -
+                |    |              |    |                |    |
+               Tgen Tact               Tret             Tdea  Trem
+
+                              ---- Time ---->
+
+
+          Figure 2: Timeline for a Double-Signature ZSK rollover.
+
+   Event 1: key N is generated at the generate time (Tgen).  Although
+   there is no reason why the key cannot be generated immediately prior
+   to publication in the zone (Event 2), some implementations may find
+   it convenient to create a pool of keys in one operation and draw from
+   that pool as required.  For this reason, it is shown as a separate
+   event.  Keys that are available for use but not published are said to
+   be generated.
+
+   Event 2: key N is added to the DNSKEY RRset and is immediately used
+   to sign the zone; existing signatures in the zone are not removed.
+   This is the active time (Tact) and the key is said to be active.
+
+   Event 3: at some time later, the predecessor key (key N-1) and its
+   signatures can be withdrawn from the zone.  (The timing of key
+   removal is discussed further in the description of event 5.)
+
+   Event 4: the successor key (key N+1) is introduced into the zone and
+   starts being used to sign RRsets.  The successor is key is now active
+   and the current key (key N) is said to be retired.  This time is the
+   retire time of the key (Tret); it is also the active time of the
+   successor key (TactS).
+
+
+
+Morris, et al.           Expires January 2, 2011               [Page 13]
+
+Internet-Draft      DNSSEC Key Timing Considerations           July 2010
+
+
+             Tret = Tact + Lzsk
+
+   Event 5: before key N can be withdrawn from the zone, all RRsets that
+   need to be signed must have been signed by the successor key (as a
+   result, all these RRsets are now signed twice, once by key N and once
+   by its successor) and the information must have reached all
+   validating resolvers that may have RRsets from this zone cached.
+
+   This takes Iret, the retire interval, given by the expression:
+
+             Iret = Dsgn + Dprp + max(TTLkey, TTLsig)
+
+   As before, Dsgn is the time taken to sign the zone with the new key
+   and Dprp is the propagation delay.  The final term is the period to
+   wait for old key and signature data to expire from caches.  After the
+   end of this interval, key N is said to be dead.  This occurs at the
+   dead time (Tdea) so:
+
+             Tdea = Tret + Iret
+
+   Event 6: at some later time key N and its signatures can be removed
+   from the zone.  This is the removal time Trem, given by:
+
+             Trem >= Tdea
+
+3.2.3.  Double-RRSIG Method
+
+   As noted above, "Double-Signature" is simultaneous rollover of both
+   signature and key.  The time line for a pure Double-Signature ZSK
+   rollover (the Double-RRSIG method) - where new signatures are
+   introduced, the key changed, and finally the old signatures removed -
+   is shown below:
+
+
+
+          |1||2|      |3| |4||5|       |6||7|       |8||9|     |10| |11|
+           |  |        |   |  |         |  |         |  |        |   |
+   Key N   |  |<-Dsgn->|   |  |<-----------Lzsk-------->|<-Iret->|   |
+           |  |<---IpubG-->|  |<-IpubK->|  |         |  |        |   |
+           |  |        |   |  |         |  |         |  |        |   |
+   Key N+1 |  |        |   |  |         |  |<-IpubG->|  |        |   |
+           |  |        |   |  |         |  |         |  |        |   |
+        Tgen Tpub        Trdy Tact        TpubS   TrdyS Tret   Tdea Trem
+
+                                ---- Time ---->
+
+
+          Figure 3: Timeline for a Double-Signature ZSK rollover.
+
+
+
+Morris, et al.           Expires January 2, 2011               [Page 14]
+
+Internet-Draft      DNSSEC Key Timing Considerations           July 2010
+
+
+   Event 1: key N is generated at the generate time (Tgen).  Although
+   there is no reason why the key cannot be generated immediately prior
+   to publication in the zone (Event 2), some implementations may find
+   it convenient to create a pool of keys in one operation and draw from
+   that pool as required.  For this reason, it is shown as a separate
+   event.  Keys that are available for use but not published are said to
+   be generated.
+
+   Event 2: key N is used to sign the zone but existing signatures are
+   retained.  Although the new ZSK is not published in the zone at this
+   point, for analogy with the other ZSK rollover methods and because
+   this is the first time that key information is visible (albeit
+   indirectly through the created signatures) this time is called the
+   publish time (Tpub).
+
+   Event 3: after the signing interval, Dsgn, all RRsets that need to be
+   signed have been signed by the new key.  (As a result, all these
+   RRsets are now signed twice, once by the existing key and once by the
+   (still-absent) key N.
+
+   Event 4: there is now a delay while the this information reaches all
+   validating resolvers that may have RRsets from the zone cached.  This
+   interval is given by the expression:
+
+             Dprp + TTLsig
+
+   ...comprising the delay for the information to propagate through the
+   nameserver infrastructure plus the time taken for signature
+   information to expire from caches.
+
+   Again in analogy with other key rollover methods, this is defined as
+   key N's ready time (Trdy) and the key is said to be in the ready
+   state.  (Although the key is not in the zone, it is ready to be
+   used.)  The interval between the publication and ready times is the
+   publication interval of the signature, IpubG, i.e.
+
+             Trdy = Tpub + IpubG
+
+   where
+
+             IpubG = Dsgn + Dprp + TTLsig
+
+   Event 5: at some later time the predecessor key is removed and the
+   key N added to the DNSKEY RRset.  As all the RRs have signatures
+   created by the old and new keys, the records can still be
+   authenticated.  This time is the active time (Tact) and the key is
+   now said to be active.
+
+
+
+
+Morris, et al.           Expires January 2, 2011               [Page 15]
+
+Internet-Draft      DNSSEC Key Timing Considerations           July 2010
+
+
+   Event 6: After IpubK - the publication interval of the key - the
+   newly added DNSKEY RRset has propagated through to all validating
+   resolvers.  At this point the old signatures can be removed from the
+   zone.  IpubK is given by:
+
+             IpubK = Dprp + TTLkey
+
+   Event 7: as before, at some later time thought must be given to
+   rolling the key.  The first step is to publish signatures created by
+   the successor key (key N+1) early enough so that key N can be
+   replaced after it has been active for its scheduled lifetime.  This
+   occurs at TpubS (the publication time of the successor), given by:
+
+             TpubS <= Tact + Lzsk - IpubG
+
+   Event 8: the signatures have propagated through the zone and the new
+   key could be added to the zone.  This time is the ready time of the
+   successor (TrdyS).
+
+             TrdyS = TpubS + IpubG
+
+   ... where IpubG is as defined above.
+
+   Event 9: at some later time key N is removed from the zone and the
+   successor key added.  This is the retire time of the key (Tret).
+
+   Event 10: The signatures must remain in the zone for long enough that
+   the new DNSKEY RRset has had enough time to propagate to all caches.
+   Once caches contain the new DNSKEY, the old signatures are no longer
+   of use and can be considered to be dead.  The time at which this
+   occurs is the dead time (Tdea), given by:
+
+             Tdea = Tret + Iret
+
+   ... where Iret is the retire interval, given by:
+
+             Iret = IpubK
+
+   Event 11: At some later time the signatures can be removed from the
+   zone.  Although the key has is not longer in the zone, this is
+   information associated with it and so the time can be regarded as the
+   key's remove time (Trem), given by:
+
+             Trem >= Tdea
+
+
+
+
+
+
+
+Morris, et al.           Expires January 2, 2011               [Page 16]
+
+Internet-Draft      DNSSEC Key Timing Considerations           July 2010
+
+
+3.3.  Key-Signing Key Rollover Timelines
+
+3.3.1.  Double-Signature Method
+
+   The Double-Signature method (also knows as the double-DNSKEY method)
+   involves introducing the new KSK to the zone and waiting until its
+   presence has been registered by all validating resolvers.  At this
+   point, the DS record in the parent is changed.  Once that change has
+   propagated to all validating resolvers, the old KSK is removed.
+
+   The timing diagram for such a rollover is:
+
+
+
+               |1|  |2|      |3|   |4|      |5|      |6|
+                |    |        |     |        |        |
+        Key N   |    |<-Ipub->|<--->|<-Dreg->|<---------Lksk--- - -
+                |    |        |     |        |        |
+        Key N+1 |    |        |     |        |        |
+                |    |        |     |        |        |
+               Tgen Tpub     Trdy  Tsub    Tact
+
+                            ---- Time ---->
+
+        (continued...)
+
+                    |7|      |8|   |9|      |10|     |11|    |12|
+                     |        |     |        |        |       |
+        Key N   - - -------------Lksk------->|<-Iret->|       |
+                     |        |     |        |        |       |
+        Key N+1      |<-Ipub->|<--->|<-Dreg->|<--------Lksk----- - -
+                     |        |     |        |        |       |
+                   TpubS    TrdyS  TsubS   Tret      Tdea     Trem
+
+                        ---- Time (cont) ---->
+
+
+          Figure 4: Timeline for a Double-Signature KSK rollover.
+
+   Event 1: key N is generated at time Tgen.  As before, although there
+   is no reason why the key cannot be generated immediately prior to
+   publication, some implementations may find it convenient to create a
+   central pool of keys and draw from it.  For this reason, it is again
+   shown as a separate event.
+
+   Event 2: key N is introduced into the zone; it is added to the DNSKEY
+   RRset, which is then signed by key N and all currently active KSKs.
+   (So at this point, the DNSKEY RRset is signed by both key N and its
+
+
+
+Morris, et al.           Expires January 2, 2011               [Page 17]
+
+Internet-Draft      DNSSEC Key Timing Considerations           July 2010
+
+
+   predecessor KSK.  If other KSKs were active, it is signed by these as
+   well.)  This is the publication time (Tpub); after this the key is
+   said to be published.
+
+   Event 3: before it can be used, the key must be published for long
+   enough to guarantee that any validating resolver that has a copy of
+   the DNSKEY RRset from the zone in its cache will have a copy of the
+   RRset that includes this key: in other words, that any prior cached
+   information about the DNSKEY RRset has expired.
+
+   The interval is the publication interval (Ipub) and, for the second
+   or subsequent KSKs in the zone, is given by:
+
+             Ipub = Dprp + TTLkey
+
+   ... where Dprp is the propagation delay for the zone and TTLkey the
+   TTL for the DNSKEY RRset.  The time at which this occurs is the key's
+   ready time, Trdy, given by:
+
+             Trdy = Tpub + Ipub
+
+   Event 4: at some later time, the DS RR corresponding to the new KSK
+   is submitted to the parent zone for publication.  This time is the
+   submission time, Tsub.
+
+   Event 5: the DS record is published in the parent zone.  As this is
+   the point at which all information for authentication - both DNSKEY
+   and DS record - is available in the two zones, it is the active time
+   of the key:
+
+             Tact = Tsub + Dreg
+
+   ... where Dreg is the registration delay, the time taken after the DS
+   record has been received by the parent zone manager for it to be
+   placed in the zone.  (Parent zones are often managed by different
+   entities, and this term accounts of the organisational overhead of
+   transferring a record.)
+
+   Event 6: at some time later, all validating resolvers that have the
+   DS RRset cached will have a copy that includes the new DS record.
+   For the second or subsequent DS records, this interval is given by
+   the expression:
+
+             DprpP + TTLds
+
+   ... where DprpP is the propagation delay in the parent zone and TTLds
+   the TTL assigned to DS records in that zone.
+
+
+
+
+Morris, et al.           Expires January 2, 2011               [Page 18]
+
+Internet-Draft      DNSSEC Key Timing Considerations           July 2010
+
+
+   In the case of the first DS record for the zone in question, the
+   expression is slightly different because it is not information about
+   a DS RRset that may be cached, it is information about its absence.
+   In this case, the interval is:
+
+             DprpP + IngcP
+
+   where IngcP is the negative cache interval from the zone's SOA
+   record, calculated according to [RFC2308] as the minimum of the TTL
+   of the parent SOA record itself (TTLsoaP), and the "minimum" field in
+   the record's parameters (SOAminP), i.e.
+
+             IngcP = min(TTLsoaP, SOAminP)
+
+   Event 7: while key N is active, thought needs to be given to its
+   successor (key N+1).  At some time before the scheduled end of the
+   KSK lifetime, the successor KSK is introduced into the zone and is
+   used to sign the DNSKEY RRset.  (As before, this means that the
+   DNSKEY RRset is signed by both the current and successor KSK.)  This
+   is the publication time of the successor key, TpubS.
+
+   Event 8: after an interval Ipub, the successor key becomes ready (in
+   that all validating resolvers that have a copy of the DNSKEY RRset
+   have a copy of this key).  This is the successor ready time, TrdyS.
+
+   Event 9: at the successor submission time (TsubS), the DS record
+   corresponding to the successor key is submitted to the parent zone.
+
+   Event 10: the successor DS record is published in the parent zone and
+   the current DS record withdrawn.  The current key is said to be
+   retired and the time at which this occurs is Tret, given by:
+
+   The relationships between these times are:
+
+             TpubS <= Tact + Lksk - Dreg - Ipub
+
+             Tret = Tact + Lksk
+
+   ... where Lksk is the scheduled lifetime of the KSK.
+
+   Event 11: key N must remain in the zone until any validators that
+   have the DS RRset cached have a copy of the DS RRset containing the
+   new DS record.  This interval is the retire interval, given by:
+
+             Iret = DprpP + TTLds
+
+   ... where DprpP is the propagation delay in the parent zone and TTLds
+   the TTL of a DS record.
+
+
+
+Morris, et al.           Expires January 2, 2011               [Page 19]
+
+Internet-Draft      DNSSEC Key Timing Considerations           July 2010
+
+
+   As the key is no longer used for anything, it can also be said to be
+   dead, in which case:
+
+             Tdea = Tret + Iret
+
+   Event 12: at some later time, key N is removed from the zone (at the
+   remove time Trem); the key is now said to be removed.
+
+             Trem >= Tdea
+
+3.3.2.  Double-DS Method
+
+   The Double-DS method is the reverse of the Double-Signature method is
+   that it is the DS record that is pre-published (in the parent), and
+   not the DNSKEY.
+
+   The timeline for the key rollover is shown below:
+
+
+
+             |1|  |2|      |3|       |4|  |5|    |6|
+              |    |        |         |    |      |
+      Key N   |    |<-Dreg->|<-IpubP->|<-->|<---------Lksk------- - -
+              |    |        |         |    |      |
+      Key N+1 |    |        |         |    |<---->|<--Dreg+IpubP- - -
+              |    |        |         |    |      |
+             Tgen Tsub     Tpub      Trdy Tact  TsubS
+
+                              ---- Time ---->
+
+       (continued...)
+
+                               |7|   |8|      |9|    |10|
+                                |     |        |      |
+      Key N   - - -----Lksk---------->|<-Iret->|      |
+                                |     |        |      |
+      Key N+1 - - --Dreg+IpubP->|<--->|<------Lksk------ - -
+                                |     |        |      |
+                              TrdyS  Tret    Tdea    Trem
+
+                              ---- Time ---->
+
+
+             Figure 5: Timeline for a Double-DS KSK rollover.
+
+   Event 1: key N is generated at time Tgen.  As before, although there
+   is no reason why the key cannot be generated immediately prior to
+   publication, some implementations may find it convenient to create a
+
+
+
+Morris, et al.           Expires January 2, 2011               [Page 20]
+
+Internet-Draft      DNSSEC Key Timing Considerations           July 2010
+
+
+   central pool of keys and draw from it.  For this reason, it is again
+   shown as a separate event.
+
+   Event 2: the DS record corresponding to key N is submitted for
+   publication in the parent zone.  This time is the submission time
+   (Tsub).
+
+   Event 3: after the registration delay, Dreg, the DS record is
+   published in the parent zone.  This is the publication time Tpub,
+   given by:
+
+             Tpub = Tsub + Dreg
+
+   Event 4: at some later time, any validating resolver that has copies
+   of the DS RRset in its cache will have a copy of the DS record for
+   key N. At this point, key N, if introduced into the DNSKEY RRset,
+   could be used to validate the zone.  For this reason, this time is
+   known as the key's ready time, Trdy, and is given by:
+
+             Trdy = Tpub + IpubP
+
+   IpubP is the parent publication interval and is given by the
+   expression:
+
+             IpubP = DprpP + TTLds
+
+   ... where DprpP is the propagation delay in the parent zone and TTLds
+   the TTL assigned to DS records in that zone.
+
+   Event 5: at some later time, the key rollover takes place.  The
+   predecessor key is withdrawn from the DNSKEY RRset and the new key
+   (key N) introduced and used to sign the RRset.
+
+   As both DS records have been in the parent zone long enough to ensure
+   that they are in the cache of any validating resolvers that have the
+   DS RRset cached, the zone can be authenticated throughout the
+   rollover - either the resolver has a copy of the DNSKEY RRset (and
+   associated RRSIGs) authenticated by the predecessor key, or it has a
+   copy of the updated RRset authenticated with the new key.
+
+   This time is the key's active time (Tact) and at this point the key
+   is said to be active.
+
+   Event 6: at some point thought must be given to key replacement.  The
+   DS record for the successor key must be submitted to the parent zone
+   at a time such that when the current key is withdrawn, any validating
+   resolver that has DS records in its cache will have data about the DS
+   record of the successor key.  The time at which this occurs is the
+
+
+
+Morris, et al.           Expires January 2, 2011               [Page 21]
+
+Internet-Draft      DNSSEC Key Timing Considerations           July 2010
+
+
+   submission time of the successor, given by:
+
+             TsubS <= Tact + Lksk - IpubP - Dreg
+
+   ... where Lksk is the lifetime of the KSK.
+
+   Event 7: the successor key (key N+1) enters the ready state i.e. its
+   DS record is now in the caches of all validating resolvers that have
+   the parent DS RRset cached.  (This is the ready time of the
+   successor, TrdyS.)
+
+   Event 8: when the current key has been active for its lifetime
+   (Lksk), the current key is removed from the DNSKEY RRset and the
+   successor key added; the RRset is then signed with the successor key.
+   This point is the retire time of the key, Tret, given by:
+
+             Tret = Tact + Lksk
+
+   Event 9: at some later time, all copies of the old DNSKEY RRset have
+   expired from caches and the old DS record is no longer needed.  This
+   is called the dead time, Tdea, and is given by:
+
+             Tdea = Tret + Iret
+
+   ... where Iret is the retire interval, given by:
+
+             Iret = Dprp + TTLkey
+
+   As before, this term includes the time taken to propagate the RRset
+   change through the master-slave hierarchy and the time take for the
+   DNSKEY RRset to expire from caches.
+
+   Event 10: at some later time, the DS record is removed from the
+   parent zone.  This is the removal time (Trem), given by:
+
+             Trem >= Tdea
+
+3.3.3.  Double-RRset Method
+
+   In the Double-RRset method, both the DS and DNSKEY records are
+   changed at the same time, so for a period the zone can be
+   authenticated with either key.  The advantage of this method is its
+   applicability in cases where zone management policy requires overlap
+   of authentication keys during a roll.
+
+   The timeline for this rollover is shown below:
+
+
+
+
+
+Morris, et al.           Expires January 2, 2011               [Page 22]
+
+Internet-Draft      DNSSEC Key Timing Considerations           July 2010
+
+
+                |1|  |2|      |3|     |4|      |5|      |6|   |7|
+                 |    |        |       |        |        |     |
+         Key N   |    |<-Dreg->|<-----Lksk----->|<-Iret->|     |
+                 |    |        |       |        |        |     |
+         Key N+1 |    |        |       |<-Dreg->|<-----Lksk-- - -
+                 |    |        |       |        |        |     |
+               Tgen  Tpub    Tact    TpubS     Tret    Tdea   Trem
+
+                                 ---- Time ---->
+
+
+            Figure 6: Timeline for a Double-RRset KSK rollover.
+
+   Event 1: key N is created at time Tgen and thereby immediately
+   becomes generated.  As before, although there is no reason why the
+   key cannot be generated immediately prior to publication, some
+   implementations may find it convenient to create a central pool of
+   keys and draw from it.  For this reason, it is again shown as a
+   separate event.
+
+   Event 2: the key is added to and used for signing the DNSKEY RRset
+   and is thereby published in the zone.  At the same time the
+   corresponding DS record is submitted to the parent zone for
+   publication.  This time is the publish time (Tpub) and the key is now
+   said to be published.
+
+   Event 3: after Dreg, the registration delay, the DS record is
+   published in the parent zone.  At this point, the zones have all the
+   information needed for a validating resolver to authenticate the
+   zone, although the information may not yet have reached all
+   validating resolver caches.  This time is the active time (Tact) and
+   the key is said to be active.
+
+             Tact = Tpub + Dreg
+
+   Event 4: at some point we need to give thought to key replacement.
+   The successor key must be introduced into the zone (and its DS record
+   submitted to the parent) at a time such that it becomes active when
+   the current key has been active for its lifetime, Lksk.  This time is
+   TpubS, the publication time of the successor key, and is given by:
+
+             TpubS <= Tact + Lksk - Dreg
+
+   ... where Lksk is the lifetime of the KSK.
+
+   Event 5: the successor key's DS record appears in the parent zone and
+   the successor key becomes active.  At this point, the current key
+   becomes retired.  This occurs at Tret, given by:
+
+
+
+Morris, et al.           Expires January 2, 2011               [Page 23]
+
+Internet-Draft      DNSSEC Key Timing Considerations           July 2010
+
+
+             Tret = Tact + Lksk
+
+   Event 6: the current DNSKEY and DS record must be retained in the
+   zones until any any validating resolver that has cached the DNSKEY
+   and/or DS RRsets will have a copy of the data for the successor key.
+   At this point the current key information is dead, as any validating
+   resolver can perform authentication using the successor key.  This is
+   the dead time, Tdea, given by:
+
+             Tdea = Tret + Iret
+
+   ... where Iret is the retire interval.  This depends on how long both
+   the successor DNSKEY and DS records take to propagate through the
+   nameserver infrastructure and thence into validator caches.  These
+   delays are the publication intervals of the child and parent zones
+   respectively, so a suitable expression for Iret is:
+
+             Iret = max(IpubP, IpubC)
+
+   IpubC is the publication interval of the DNSKEY in the child zone,
+   IpubP that of the DS record in the parent.
+
+   The child term comprises two parts - the time taken for the
+   introduction of the DNSKEY record to be propagated to the downstream
+   secondary servers (= DprpC, the child propagation delay) and the time
+   taken for information about the DNSKEY RRset to expire from the
+   validating resolver cache, i.e.
+
+             IpubC = DprpC + TTLkey
+
+   TTLkey is the TTL for a DNSKEY record in the child zone.  The parent
+   term is similar:
+
+             IpubP = DprpP + TTLds
+
+   DprpP the propagation delay in the parent zone and TTLds the TTL for
+   a DS record in the parent zone.
+
+   Event 7: at some later time, the DNSKEY record can be removed from
+   the child zone and a request can be made to remove the DS record from
+   the parent zone.  This is the removal time, Trem and is given by:
+
+             Trem >= Tdea
+
+
+
+
+
+
+
+
+Morris, et al.           Expires January 2, 2011               [Page 24]
+
+Internet-Draft      DNSSEC Key Timing Considerations           July 2010
+
+
+3.3.4.  Interaction with Configured Trust Anchors
+
+   Although the preceding sections have been concerned with rolling KSKs
+   where the trust anchor is a DS record in the parent zone, zone
+   managers may want to take account of the possibility that some
+   validating resolvers may have configured trust anchors directly.
+
+   Rolling a configured trust anchor is dealt with in [RFC5011].  It
+   requires introducing the KSK to be used as the trust anchor into the
+   zone for a period of time before use, and retaining it (with the
+   "revoke" bit set) for some time after use.  The Double-Signature and
+   Double-RRset methods can be adapted to include [RFC5011]
+   recommendations so that the rollover will also be signalled to
+   validating resolvers with configured trust anchors.  (The
+   recommendations are not suitable for the Double-DS method.
+   Introducing the new key early and retaining the old key after use
+   effectively converts it into a form of Double-RRset.)
+
+3.3.4.1.  Addition of KSK
+
+   When the new key is introduced, the publication interval (Ipub) in
+   the Double-Signature method should also be subject to the condition:
+
+             Ipub >= max(30 days, TTLkey)
+
+   ... where the right had side of the expression is the add hold-down
+   time defined in section 2.4.1 of [RFC5011].
+
+   In the Double-RRSIG method, the key should not be regarded as being
+   active until the add hold-down time has passed.  In other words, the
+   following condition should be enforced:
+
+             Tact >= Tpub + max(30 days, TTLkey)
+
+   (Effectively, this means extending the lifetime of the key by an
+   appropriate amount.)
+
+3.3.4.2.  Removal of KSK
+
+   The timeline for the removal of the key in both methods is modified
+   by introducing a new state, "revoked".  When the key reaches the end
+   of the retire period, instead of being declared "dead", it is
+   revoked; the "revoke" bit is set on the DNSKEY RR and is published in
+   (and used to sign) the DNSKEY RRset.  The key is maintained in this
+   state for the "revoke" interval, Irev, given by:
+
+
+
+
+
+
+Morris, et al.           Expires January 2, 2011               [Page 25]
+
+Internet-Draft      DNSSEC Key Timing Considerations           July 2010
+
+
+             Irev >= 30 days
+
+   ... 30 days being the [RFC5011] remove hold-down time.  After this
+   time, the key is dead and can be removed from the zone when
+   convenient.
+
+3.3.5.  Introduction of First KSK
+
+   There is an additional consideration when introducing a KSK into a
+   zone for the first time, and that is that no validating resolver
+   should be in a position where it can access the trust anchor before
+   the KSK appears in the zone.  To do so will cause the validating
+   resolver to declare the zone to be bogus.
+
+   This is important: in the case of a secure parent, it means ensuring
+   that the DS record is not published in the parent zone until there is
+   no possibility that a validating resolver can obtain the record yet
+   not be able to obtain the corresponding DNSKEY.  In the case of an
+   insecure parent, i.e. the initial creation of a new security apex, it
+   is important to not configure trust anchors in validating resolvers
+   until the DNSKEY RRset has had sufficient time to propagate.  In both
+   cases, this time is the trust anchor availability time (Ttaa) given
+   by:
+
+             Ttaa >= Tpub + IpubC
+
+   where
+
+             IpubC = DprpC + TTLkeyC
+
+   or
+
+             IpubC = DprpC + IngcC
+
+   The first expression applies if there was previously a DNSKEY RRset
+   in the child zone, the expression for IpubC including the TTLkeyC
+   term to account for the time taken for that RRset to expire from
+   caches.  (It is possible that the zone was signed but that the trust
+   anchor had not been submitted to the parent.)
+
+   If the introduction of the KSK caused the appearance of the first
+   DNSKEY RRset in the child zone, the second expression applies in
+   which the TTLkeyC term is replaced by Ingc to allow for the effect of
+   negative caching.
+
+   As before, IngcC is the negative cache interval from the child zone's
+   SOA record, calculated according to [RFC2308] as the minimum of the
+   TTL of the SOA record itself (TTLsoaC), and the "minimum" field in
+
+
+
+Morris, et al.           Expires January 2, 2011               [Page 26]
+
+Internet-Draft      DNSSEC Key Timing Considerations           July 2010
+
+
+   the record's parameters (SOAminC), i.e.
+
+             IngcC = min(TTLsoaC, SOAminC)
+
+
+4.  Standby Keys
+
+   Although keys will usually be rolled according to some regular
+   schedule, there may be occasions when an emergency rollover is
+   required, e.g. if the active key is suspected of being compromised.
+   The aim of the emergency rollover is to allow the zone to be re-
+   signed with a new key as soon as possible.  As a key must be in the
+   ready state to sign the zone, having at least one additional key (a
+   standby key) in this state at all times will minimise delay.
+
+   In the case of a ZSK, a standby key only really makes sense with the
+   Pre-Publication method.  A permanent standby DNSKEY RR should be
+   included in zone or successor keys could be introduced as soon as
+   possible after a key becomes active.  Either way results in an
+   additional ZSK in the DNSKEY RRset that can immediately be used to
+   sign the zone if the current key is compromised.
+
+   (Although in theory the mechanism could be used with both the Double-
+   Signature and Double-RRSIG methods, it would require Pre-Publication
+   of the signatures.  Essentially, the standby key would be permanently
+   active, as it would have to be periodically used to renew signatures.
+   Zones would also permanently require two sets of signatures,
+   something that could have a performance impact in large zones.)
+
+   A standby key can also be used with the Double-Signature and
+   Double-DS methods of rolling a KSK.  (The idea of a standby key in
+   the Double-RRset effectively means having two active keys.)  The
+   Double-Signature method requires that the standby KSK be included in
+   the DNSKEY RRset; rolling the key then requires just the introduction
+   of the DS record in the parent.  (Note that the DNSKEY should also be
+   used to sign the DNSKEY RRset.  As the RRset and its signatures
+   travel together, merely adding the DNSKEY does not provide the
+   desired time saving; to be used in a rollover requires that the
+   DNSKEY RRset be signed with the standby key, and this introduces a
+   delay whilst the RRset and its signatures propagate to the caches of
+   validating resolvers.  There is no time advantage over introducing a
+   new DNSKEY and signing the RRset with it at the same time.)
+
+   In the Double-DS method of rolling a KSK, it is not a standby key
+   that is present, it is a standby DS record in the parent zone.
+   Whatever algorithm is used, the standby item of data can be
+   introduced as a permanent standby, or be a successor introduced as
+   early as possible.
+
+
+
+Morris, et al.           Expires January 2, 2011               [Page 27]
+
+Internet-Draft      DNSSEC Key Timing Considerations           July 2010
+
+
+5.  Algorithm Considerations
+
+   The preceding sections have implicitly assumed that all keys and
+   signatures are created using a single algorithm.  However, [RFC4035]
+   (section 2.4) states that "There MUST be an RRSIG for each RRset
+   using at least one DNSKEY of each algorithm in the zone apex DNSKEY
+   RRset".
+
+   Except in the case of an algorithm rollover - where the algorithms
+   used to create the signatures are being changed - there is no
+   relationship between the keys of different algorithms.  This means
+   that they can be rolled independently of one another.  In other
+   words, the key rollover logic described above should be run
+   separately for each algorithm; the union of the results is included
+   in the zone, which is signed using the active key for each algorithm.
+
+
+6.  Summary
+
+   For ZSKs, "Pre-Publication" is generally considered to be the
+   preferred way of rolling keys.  As shown in this document, the time
+   taken to roll is wholly dependent on parameters under the control of
+   the zone manager.
+
+   In contrast, "Double-RRset" is the most efficient method for KSK
+   rollover due to the ability to have new DS records and DNSKEY RRsets
+   propagate in parallel.  The time taken to roll KSKs may depend on
+   factors related to the parent zone if the parent is signed.  For
+   zones that intend to comply with the recommendations of [RFC5011], in
+   virtually all cases the rollover time will be determined by the
+   RFC5011 "add hold-down" and "remove hold-down" times.  It should be
+   emphasized that this delay is a policy choice and not a function of
+   timing values and that it also requires changes to the rollover
+   process due to the need to manage revocation of trust anchors.
+
+   Finally, the treatment of emergency key rollover is significantly
+   simplified by the introduction of stand-by keys as standard practice
+   during all types of rollovers.
+
+
+7.  IANA Considerations
+
+   This memo includes no request to IANA.
+
+
+8.  Security Considerations
+
+   This document does not introduce any new security issues beyond those
+
+
+
+Morris, et al.           Expires January 2, 2011               [Page 28]
+
+Internet-Draft      DNSSEC Key Timing Considerations           July 2010
+
+
+   already discussed in [RFC4033], [RFC4034], [RFC4035] and [RFC5011].
+
+
+9.  Acknowledgements
+
+   The authors gratefully acknowledge help and contributions from Roy
+   Arends and Wouter Wijngaards.
+
+
+10.  Change History
+
+   o  draft-morris-dnsop-dnssec-key-timing-02
+      * General restructuring.
+      * Added descriptions of more rollovers (IETF-76 meeting).
+      * Improved description of key states and removed diagram.
+      * Provided simpler description of standby keys.
+      * Added section concerning first key in a zone.
+      * Moved [RFC5011] to a separate section.
+      * Various nits fixed (Alfred Hones, Jeremy Reed, Scott Rose, Sion
+      Lloyd, Tony FinchX).
+
+   o  draft-morris-dnsop-dnssec-key-timing-01
+      * Use latest boilerplate for IPR text.
+      * List different ways to roll a KSK (acknowledgements to Mark
+      Andrews).
+      * Restructure to concentrate on key timing, not management
+      procedures.
+      * Change symbol notation (Diane Davidowicz and others).
+      * Added key state transition diagram (Diane Davidowicz).
+      * Corrected spelling, formatting, grammatical and style errors
+      (Diane Davidowicz, Alfred Hoenes and Jinmei Tatuya).
+      * Added note that in the case of multiple algorithms, the
+      signatures and rollovers for each algorithm can be considered as
+      more or less independent (Alfred Hoenes).
+      * Take account of the fact that signing a zone is not atomic
+      (Chris Thompson).
+      * Add section contrasting pre-publication rollover with double
+      signature rollover (Matthijs Mekking).
+      * Retained distinction between first and subsequent keys in
+      definition of initial publication interval (Matthijs Mekking).
+
+   o  draft-morris-dnsop-dnssec-key-timing-00
+      Initial draft.
+
+
+11.  References
+
+
+
+
+
+Morris, et al.           Expires January 2, 2011               [Page 29]
+
+Internet-Draft      DNSSEC Key Timing Considerations           July 2010
+
+
+11.1.  Normative References
+
+   [RFC2308]  Andrews, M., "Negative Caching of DNS Queries (DNS
+              NCACHE)", RFC 2308, March 1998.
+
+   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "DNS Security Introduction and Requirements",
+              RFC 4033, March 2005.
+
+   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "Resource Records for the DNS Security Extensions",
+              RFC 4034, March 2005.
+
+   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "Protocol Modifications for the DNS Security
+              Extensions", RFC 4035, March 2005.
+
+   [RFC5011]  StJohns, M., "Automated Updates of DNS Security (DNSSEC)
+              Trust Anchors", RFC 5011, September 2007.
+
+11.2.  Informative References
+
+   [RFC4641]  Kolkman, O. and R. Gieben, "DNSSEC Operational Practices",
+              RFC 4641, September 2006.
+
+
+Appendix A.  List of Symbols
+
+   The document defines a number of symbols, all of which are listed
+   here.  All are of the form:
+
+   All symbols used in the text are of the form:
+
+             <TYPE><id><INST>
+
+   where:
+
+   <TYPE> is an upper-case character indicating what type the symbol is.
+   Defined types are:
+
+   D         delay: interval that is a feature of the process
+
+   I         interval between two events
+
+   L         lifetime: interval set by the zone manager
+
+
+
+
+
+
+Morris, et al.           Expires January 2, 2011               [Page 30]
+
+Internet-Draft      DNSSEC Key Timing Considerations           July 2010
+
+
+   SOA       parameter related to SOA RR
+
+   T         a point in time
+
+   TTL       TTL of a record
+
+   T and I are self-explanatory.  D, and L are also time periods, but
+   whereas I values are intervals between two events (even if the events
+   are defined in terms of the interval, e.g. the dead time occurs
+   "retire interval" after the retire time), D, and L are fixed
+   intervals.  An "L" interval (lifetime) is chosen by the zone manager
+   and is a feature of policy.  A "D" interval (delay) is a feature of
+   the process, probably outside control of the zone manager.  SOA and
+   TTL are used just because they are common terms.
+
+   <id> is lower-case and defines what object or event the variable is
+   related to, e.g.
+
+   act       active
+
+   ngc       negative cache
+
+   pub       publication
+
+   Finally, <INST> is a capital letter that distinguishes between the
+   same variable applying to different instances of an object and is one
+   of:
+
+   C         child
+
+   G         signature
+
+   K         key
+
+   P         parent
+
+   S         successor
+
+   The list of variables used in the text is:
+
+   Dprp      Propagation delay.  The amount of time for a change made at
+             a master nameserver to propagate to all the slave
+             nameservers.
+
+   DprpC     Propagation delay in the child zone.
+
+
+
+
+
+
+Morris, et al.           Expires January 2, 2011               [Page 31]
+
+Internet-Draft      DNSSEC Key Timing Considerations           July 2010
+
+
+   DprpP     Propagation delay in the parent zone.
+
+   Dreg      Registration delay.  As a parent zone is often managed by a
+             different organisation to that managing the child zone, the
+             delays associated with passing data between zones is
+             captured by this term.
+
+   Dskw      Clock skew.  The maximum difference in time between the
+             signing system and the resolver.
+
+   Dsgn      Signing delay.  After the introduction of a new ZSK, the
+             amount of time taken for all the RRs in the zone to be
+             signed with it.
+
+   Ingc      Negative cache interval.
+
+   IngcP     Negative cache interval of the child zone.
+
+   IngcP     Negative cache interval of the parent zone.
+
+   Ipub      Publication interval.  The amount of time that must elapse
+             after the publication of a key before it can be considered
+             to have entered the ready state.
+
+   IpubC     Publication interval in the child zone.
+
+   IpubG     Publication interval for the signature.
+
+   IpubK     Publication interval for the key.
+
+   IpubP     Publication interval in the parent zone.
+
+   Iret      Retire interval.  The amount of time that must elapse after
+             a key enters the retire state for any signatures created
+             with it to be purged from validating resolver caches.
+
+   Irev      Revoke interval.  The amount of time that a KSK must remain
+             published with the revoke bit set to satisfy [RFC5011]
+             considerations.
+
+   Lksk      Lifetime of a key-signing key.  This is the intended amount
+             of time for which this particular KSK is regarded as the
+             active KSK.  Depending on when the key is rolled-over, the
+             actual lifetime may be longer or shorter than this.
+
+
+
+
+
+
+
+Morris, et al.           Expires January 2, 2011               [Page 32]
+
+Internet-Draft      DNSSEC Key Timing Considerations           July 2010
+
+
+   Lzsk      Lifetime of a zone-signing key.  This is the intended
+             amount of time for which the ZSK is used to sign the zone.
+             Depending on when the key is rolled-over, the actual
+             lifetime may be longer or shorter than this.
+
+   Lsig      Lifetime of a signature: the difference in time between the
+             signature's expiration time and the time at which the
+             signature was created.  (Note that this is not the
+             difference between the signature's expiration and inception
+             times: the latter is usually set a small amount of time
+             before the signature is created to allow for clock skew
+             between the signing system and the validating resolver.)
+
+   SOAmin    Value of the "minimum" field from an SOA record.
+
+   SOAminC   Value of the "minimum" field from an SOA record in the
+             child zone.
+
+   SOAminP   Value of the "minimum" field from an SOA record in the
+             parent zone.
+
+   Tact      Active time of the key; the time at which the key is
+             regarded as the principal key for the zone.
+
+   TactS     Active time of the successor key.
+
+   Tdea      Dead time of a key.  Applicable only to ZSKs, this is the
+             time at which any record signatures held in validating
+             resolver caches are guaranteed to be created with the
+             successor key.
+
+   Tgen      Generate time of a key.  The time that a key is created.
+
+   Tpub      Publish time of a key.  The time that a key appears in a
+             zone for the first time.
+
+   TpubS     Publish time of the successor key.
+
+   Trem      Removal time of a key.  The time at which a key is removed
+             from the zone.
+
+   Tret      Retire time of a key.  The time at which a successor key
+             starts being used to sign the zone.
+
+   Trdy      Ready time of a key.  The time at which it can be
+             guaranteed that validating resolvers that have key
+             information from this zone cached have a copy of this key
+             in their cache.  (In the case of KSKs, should the
+
+
+
+Morris, et al.           Expires January 2, 2011               [Page 33]
+
+Internet-Draft      DNSSEC Key Timing Considerations           July 2010
+
+
+             validating resolvers also have DS information from the
+             parent zone cached, the cache must include information
+             about the DS record corresponding to the key.)
+
+   TrdyS     Ready time of a successor key.
+
+   Tsub      Submit time - the time at which the DS record of a KSK is
+             submitted to the parent.
+
+   TsubS     Submit time of the successor key.
+
+   TTLds     Time to live of a DS record (in the parent zone).
+
+   TTLkey    Time to live of a DNSKEY record.
+
+   TTLkeyC   Time to live of a DNSKEY record in the child zone.
+
+   TTLsoa    Time to live of a SOA record.
+
+   TTLsoaC   Time to live of a SOA record in the child zone.
+
+   TTLsoaP   Time to live of a SOA record in the parent zone.
+
+   TTLsig    Time to live of an RRSIG record.
+
+   Ttaa      Trust anchor availability time.  The time at which a trust
+             anchor record can be made available when a KSK is first
+             introduced into a zone.
+
+
+Authors' Addresses
+
+   Stephen Morris
+   Internet Systems Consortium
+   950 Charter Street
+   Redwood City, CA  94063
+   USA
+
+   Phone: +1 650 423 1300
+   Email: stephen@isc.org
+
+
+
+
+
+
+
+
+
+
+
+Morris, et al.           Expires January 2, 2011               [Page 34]
+
+Internet-Draft      DNSSEC Key Timing Considerations           July 2010
+
+
+   Johan Ihren
+   Netnod
+   Franzengatan 5
+   Stockholm,   SE-112 51
+   Sweden
+
+   Phone: +46 8615 8573
+   Email: johani@autonomica.se
+
+
+   John Dickinson
+   Sinodun Internet Technologies Ltd
+   Stables 4 Suite 11, Howbery Park
+   Wallingford, Oxfordshire  OX10 8BA
+   UK
+
+   Phone: +44 1491 818120
+   Email: jad@sinodun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Morris, et al.           Expires January 2, 2011               [Page 35]
+
diff --git a/doc/draft/draft-mekking-dnsop-auto-cpsync-00.txt b/doc/draft/draft-mekking-dnsop-auto-cpsync-00.txt
new file mode 100644
index 000000000000..0a7516bd64a0
--- /dev/null
+++ b/doc/draft/draft-mekking-dnsop-auto-cpsync-00.txt
@@ -0,0 +1,336 @@
+
+
+
+Domain Name System Operations                                 W. Mekking
+Internet-Draft                                                NLnet Labs
+Intended status: Standards Track                           June 29, 2010
+Expires: December 31, 2010
+
+
+    Automated (DNSSEC) Child Parent Synchronization using DNS UPDATE
+                   draft-mekking-dnsop-auto-cpsync-00
+
+Abstract
+
+   This document proposes a way to synchronise existing trust anchors
+   automatically between a child zone and its parent.  The algorithm can
+   be used for other Resource Records that are required to delegate from
+   a parent to a child such as NS and glue records.
+
+Requirements Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+Status of This Memo
+
+   This Internet-Draft is submitted in full conformance with the
+   provisions of BCP 78 and BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF).  Note that other groups may also distribute
+   working documents as Internet-Drafts.  The list of current Internet-
+   Drafts is at http://datatracker.ietf.org/drafts/current/.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   This Internet-Draft will expire on December 31, 2010.
+
+Copyright Notice
+
+   Copyright (c) 2010 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+
+
+
+Mekking                 Expires December 31, 2010               [Page 1]
+
+Internet-Draft        Child Parent Synchronization             June 2010
+
+
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+1.  Introduction
+
+   This memo defines a way to synchronise existing trust anchors
+   automatically between a child zone and its parent.  The algorithm can
+   be used for other Resource Records that are required to delegate from
+   a parent to a child such as NS and glue records.
+
+   To create a DNSSEC RFC 4035 [RFC4035] chain of trust, child zones
+   must submit their DNSKEYs, or hashes of their DNSKEYs, to their
+   parent zone.  The parent zone publishes the hashes of the DNSKEYs in
+   the form of a DS record.  The DNSKEY RRset at the child may change
+   over time.  In order to keep the chain of trust intact, the DS
+   records at the parent zone also needs to be updated.  The rolling of
+   the keys with the SEP bit on is one of the few tasks in DNSSEC that
+   yet has to be fully automated.
+
+   The DNS UPDATE mechanism RFC 2136 [RFC2136] can be used to push zone
+   changes to the parent.
+
+   To bootstrap the direct communication channel, information must be
+   exchanged in order to detect service location and granting update
+   privileges.  A new or existing child zone can request a direct
+   communication channel with the parent.  If the parent allows for
+   direct communication with child zones, the parent can share the
+   required data to set up the channel to the child zone.  Once the
+   child has the required credentials, it can use the direct
+   communication channel with the parent to request zone changes related
+   to its delegation.
+
+   If a third party is involved, the third party can act on behalf of
+   the parent.  In this case, the third party will give out the required
+   credentials to set up the communication channel.
+
+   It is RECOMMENDED that the direct communication channel is secured
+   with TSIG [RFC2845] or SIG0 [RFC2931].
+
+2.  Access and Update Control
+
+   The DNS UPDATE normally is used for granting update permissions to a
+   machine that is within the boundary of the same organization.  This
+   document proposes to grant child zones the same permissions.
+   However, it MUST NOT be possible that a child zone updates
+
+
+
+Mekking                 Expires December 31, 2010               [Page 2]
+
+Internet-Draft        Child Parent Synchronization             June 2010
+
+
+   information in the parent zone that falls outside the administrative
+   domain of the corresponding delegation.  For example, it MUST NOT be
+   possible for a child zone to update the data that the parent is
+   authoritative for, or update a delegation that is pointed to a
+   different child zone.  It MUST only be able to update records that
+   match one of the following:
+
+   Or:   The owner name is equal the child zone name and RRtype is
+      delegation specific.  Currently those are records with RRtype NS
+      or DS.
+
+   Or:   The owner name is a subdomain of the child zone name and RRtype
+      is glue specific.  Currently those are records with RRtype A or
+      AAAA.
+
+   This list may be expanded in the future, if there is need for more
+   delegation related zone content.
+
+   In case of adding or deleting delegation specific records, the DNSSEC
+   related RRs in the parent zone might need to be updated.
+
+   The service location may be handed out by the registrar during
+   bootstrap If this information is missing, the normal guidelines for
+   sending DNS UPDATE messages SHOULD be followed.
+
+3.  Update Mechanism
+
+3.1.  Child Duties
+
+   Updating the NS RRset or corresponding glue at the parent, an update
+   can be sent at any time.  Updating the DS RRset is part of key
+   rollover, as described in RFC 4641 [RFC4641].  When performing a key
+   rollover that involves updating the RRset at the parent, the child
+   introduces a new DNSKEY in its zone that represents the security
+   entry point for determining the chain of trust.  After a while, it
+   will revoke and/or remove the previous security entry point.  The
+   timings when to update the DS RRset at the parent are described in
+   draft-dnsop-morris-dnssec-key-timing [keytiming].  When updating the
+   DS RRset at the parent automatically, these timing specifications
+   SHOULD be followed.  To determine the propagation delays described in
+   this document, the child should poll the parent zone for a short
+   time, until the DS is visible at all parent name servers.
+
+   To discuss: A child zone might be unable to reach all parent name
+   servers.
+
+   The child notifies the parent of the requested changes by sending a
+   DNS UPDATE message.  If it receives a NOERROR reply in return, the
+
+
+
+Mekking                 Expires December 31, 2010               [Page 3]
+
+Internet-Draft        Child Parent Synchronization             June 2010
+
+
+   update is acknowledged by the parent zone.  Otherwise, the child MAY
+   retry transmitting the update.  In order to prevent duplicate
+   updates, it SHOULD follow the guidelines described in RFC 2136
+   [RFC2136].
+
+3.2.  Parent Duties
+
+   When the master DNS server of the parent receives a DNS UPDATE from
+   one of its children the following must be done:
+
+   Step 1:  Check the TSIG/SIG0 credentials.  In case of TSIG, the
+      parent should follow the TSIG processing described in section 3.2
+      of RFC 2845.  In case of SIG0, the parent should follow the SIG0
+      processing described in section 3.2 of RFC 2931.
+
+   Step 2:  Verify that the updates matches the update policy for child
+      zones.
+
+   Step 3:  If verified, send back DNS UPDATE OK.  Otherwise, send back
+      DNS UPDATE REFUSED.
+
+   Step 4:  If verified, apply changes.  How that is done is a matter of
+      policy.
+
+3.3.  Proxy considerations
+
+   Some environments don't allow for direct communication between parent
+   and child zone.  In these case, the parent duties can be performed by
+   a different party (for example, the registar).  The third party will
+   forward the update to the parent zone.  In what format depends on
+   local policy.
+
+4.  Example BIND9 Configuration
+
+   This is how a parent zone can configure a policy to enable a child
+   zone synchronize delegation specific records.  The first rule of the
+   update policy grants children to update their DS and NS records in
+   the parent zone, in this case example.com.  The second rule of the
+   update policy grants children to update the corresponding glue
+   records.
+
+   key cs.example.com. {
+   algorithm HMAC-MD5;
+   secret "secretforcs";
+   }
+
+   key math.example.com. {
+   algorithm HMAC-MD5;
+
+
+
+Mekking                 Expires December 31, 2010               [Page 4]
+
+Internet-Draft        Child Parent Synchronization             June 2010
+
+
+   secret "secretformath";
+   }
+
+   ...
+
+   zone "example.com" {
+   type master;
+   file "example.com";
+   update-policy { grant *.example.com. self *.example.com.  DS NS; };
+   update-policy { grant *.example.com. selfsub *.example.com.  A AAAA;
+   };
+   };
+
+5.  Security Considerations
+
+   Automating the synchronization of (DNSSEC) records between the parent
+   and child created a new channel.  We have recommended that this
+   channel should be secured with TSIG or SIG0.  There is an advantage
+   and a disadvantage of the new security channel.  The disadvantage is
+   that you create a new attack window for your DNSSEC credentials.  If
+   the automated synchronization is used for updating DS records at the
+   parent, you SHOULD pick a cryptographically an equally strong or
+   stronger TSIG/SIG0 key than the strength of your DNSSEC keys.
+
+   The advantage is that if somehow your DNSSEC keys are compromised,
+   you can still use this channel to perform an emergency key rollover.
+
+6.  IANA Considerations
+
+   None.
+
+7.  Acknowledgments
+
+   Rickard Bellgrim, Wolfgang Nagele, Wouter Wijngaards and more.
+
+8.  References
+
+8.1.  Informative References
+
+   [RFC2136]    Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
+                "Dynamic Updates in the Domain Name System (DNS
+                UPDATE)", RFC 2136, April 1997.
+
+   [RFC4641]    Kolkman, O. and R. Gieben, "DNSSEC Operational
+                Practices", RFC 4641, September 2006.
+
+   [keytiming]  Morris, S., Ihren, J., and J. Dickinson, "DNSSEC Key
+                Timing Considerations", March 2010.
+
+
+
+Mekking                 Expires December 31, 2010               [Page 5]
+
+Internet-Draft        Child Parent Synchronization             June 2010
+
+
+8.2.  Normative References
+
+   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
+                Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2845]    Vixie, P., Gudmundsson, O., Eastlake, D., and B.
+                Wellington, "Secret Key Transaction Authentication for
+                DNS (TSIG)", RFC 2845, May 2000.
+
+   [RFC2931]    Eastlake, D., "DNS Request and Transaction Signatures (
+                SIG(0)s)", RFC 2931, September 2000.
+
+   [RFC4035]    Arends, R., Austein, R., Larson, M., Massey, D., and S.
+                Rose, "Protocol Modifications for the DNS Security
+                Extensions", RFC 4035, March 2005.
+
+Author's Address
+
+   Matthijs Mekking
+   NLnet Labs
+   Science Park 140
+   Amsterdam  1098 XG
+   The Netherlands
+
+   EMail: matthijs@nlnetlabs.nl
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mekking                 Expires December 31, 2010               [Page 6]
+
diff --git a/doc/draft/draft-yao-dnsext-bname-04.txt b/doc/draft/draft-yao-dnsext-bname-04.txt
new file mode 100644
index 000000000000..0c52c462c27b
--- /dev/null
+++ b/doc/draft/draft-yao-dnsext-bname-04.txt
@@ -0,0 +1,729 @@
+
+
+Network Working Group                                             J. Yao
+Internet-Draft                                                    X. Lee
+Intended status: Standards Track                                   CNNIC
+Expires: February 12, 2011                                      P. Vixie
+                                            Internet Software Consortium
+                                                         August 11, 2010
+
+
+                      Bundle DNS Name Redirection
+                     draft-yao-dnsext-bname-04.txt
+
+Abstract
+
+   This document defines a new DNS Resource Record called "BNAME", which
+   provides the capability to map itself and its subtree of the DNS name
+   space to another domain.  It differs from the CNAME record which only
+   maps a single node of the DNS name space, from the DNAME which only
+   maps the subtree of the DNS name space to another domain.
+
+Status of this Memo
+
+   This Internet-Draft is submitted in full conformance with the
+   provisions of BCP 78 and BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF).  Note that other groups may also distribute
+   working documents as Internet-Drafts.  The list of current Internet-
+   Drafts is at http://datatracker.ietf.org/drafts/current/.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   This Internet-Draft will expire on February 12, 2011.
+
+Copyright Notice
+
+   Copyright (c) 2010 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+
+
+
+Yao, et al.             Expires February 12, 2011               [Page 1]
+
+Internet-Draft                    bname                      August 2010
+
+
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+   This document may contain material from IETF Documents or IETF
+   Contributions published or made publicly available before November
+   10, 2008.  The person(s) controlling the copyright in some of this
+   material may not have granted the IETF Trust the right to allow
+   modifications of such material outside the IETF Standards Process.
+   Without obtaining an adequate license from the person(s) controlling
+   the copyright in such materials, this document may not be modified
+   outside the IETF Standards Process, and derivative works of it may
+   not be created outside the IETF Standards Process, except to format
+   it for publication as an RFC or to translate it into languages other
+   than English.
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   3.  The BNAME Resource Record  . . . . . . . . . . . . . . . . . .  4
+     3.1.  Format . . . . . . . . . . . . . . . . . . . . . . . . . .  4
+     3.2.  The BNAME Substitution . . . . . . . . . . . . . . . . . .  4
+     3.3.  The BNAME Rules  . . . . . . . . . . . . . . . . . . . . .  4
+   4.  Query Processing . . . . . . . . . . . . . . . . . . . . . . .  4
+     4.1.  Processing by Servers  . . . . . . . . . . . . . . . . . .  5
+     4.2.  Processing by Resolvers  . . . . . . . . . . . . . . . . .  8
+   5.  BNAME in DNSSEC  . . . . . . . . . . . . . . . . . . . . . . .  9
+     5.1.  BNAME validating . . . . . . . . . . . . . . . . . . . . .  9
+     5.2.  BNAME alias algorithm identifiers  . . . . . . . . . . . . 10
+   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
+   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
+   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
+   9.  Change History . . . . . . . . . . . . . . . . . . . . . . . . 11
+     9.1.  draft-yao-dnsext-bname: Version 00 . . . . . . . . . . . . 11
+     9.2.  draft-yao-dnsext-bname: Version 01 . . . . . . . . . . . . 11
+     9.3.  draft-yao-dnsext-bname: Version 02 . . . . . . . . . . . . 11
+     9.4.  draft-yao-dnsext-bname: Version 03 . . . . . . . . . . . . 11
+   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
+     10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
+     10.2. Informative References . . . . . . . . . . . . . . . . . . 13
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
+
+
+
+
+
+
+
+
+Yao, et al.             Expires February 12, 2011               [Page 2]
+
+Internet-Draft                    bname                      August 2010
+
+
+1.  Introduction
+
+   More and more internationalized domain name labels [RFC3490] appear
+   in the DNS trees.  Some labels [RFC3743] are equivalent in some
+   languages.  The internet users want them to be identical in the DNS
+   resolution.  For example, color.exmaple.com==colour.example.com.  The
+   BNAME represents for bundle names.  This document defines a new DNS
+   Resource Record called "BNAME", which provides the capability to map
+   an entire tree of the DNS name space to another domain.  It means
+   that the BNAME redirects both itself and its descendants to its
+   owner.  The DNAME [RFC2672] and [RFC2672bis] do not redirect itself,
+   only the descendants.  The domain name that owns a DNAME record is
+   allowed to have other resource record types at that domain name.  The
+   domain name that owns a BNAME record is not allowed to have other
+   resource record types at that domain name unless they are the DNSSEC
+   related resource record types defined in [RFC4033], [RFC4034],
+   [RFC4035] and [RFC5155].  A server MAY refuse to load a zone that has
+   data at a sub-domain of a domain name owning a BNAME RR or that has
+   other data except the DNSSEC related resource record types and BNAME
+   at that name.  BNAME is a singleton type, meaning only one BNAME is
+   allowed per name except the DNSSEC related resource record types.
+   Resolvers, servers and zone content administrators should be cautious
+   that usage of BNAME or its combination with CNAME or DNAME may lead
+   to form loops.  The loops should be avoided.
+
+1.1.  Terminology
+
+   All the basic terms used in this specification are defined in the
+   documents [RFC1034], [RFC1035] and [RFC2672].
+
+
+2.  Motivation
+
+   In some languages, some characters have the variants, which look
+   differently or very similar but are identical in the meaning.  For
+   example, Chinese character U+56FD and its variant U+570B look
+   differently, but are identical in the meaning.  If Internationalized
+   Domain Label" or "IDL" [RFC3743] are composed of variant characters,
+   we regard this kind of IDL as the IDL variant.  If these IDL variants
+   are put into the DNS for resolution, they are expected to be
+   identical in the DNS resolution.  More comprehensible example is that
+   we expect color.exmaple.com to be equivalent with the
+   colour.exmaple.com in the DNS resolution.  The BNAME Resource Record
+   and its processing rules are conceived as a solution to this
+   equivalence problem.  Without the BNAME mechanism, current mechanisms
+   such as DNAME or CNAME are not enough capable to solve all the
+   problems with the emergence of internationalized domain names.  The
+   internationalized domain names may have alias or equivalence of the
+
+
+
+Yao, et al.             Expires February 12, 2011               [Page 3]
+
+Internet-Draft                    bname                      August 2010
+
+
+   original one.  The BNAME solution provides the solution to both ASCII
+   alias names and internationalized domain alias names.
+
+
+3.  The BNAME Resource Record
+
+3.1.  Format
+
+   The BNAME RR has mnemonic BNAME and type code xx (decimal).  It is
+   not class-sensitive.  Its RDATA is comprised of a single field,
+   <target>, which contains a fully qualified domain name that must be
+   sent in uncompressed form [RFC1035], [RFC3597].  The <target> field
+   MUST be present.  The presentation format of <target> is that of a
+   domain name [RFC1035].  The wildcards in the BNAME RR SHOULD NOT be
+   used.
+
+     <owner> <ttl> <class> BNAME <target>
+
+   The effect of the BNAME RR is the substitution of the record's
+   <target> for its owner name, as a suffix of a domain name.  This
+   substitution has to be applied for every BNAME RR found in the
+   resolution process, which allows fairly lengthy valid chains of BNAME
+   RRs.
+
+3.2.  The BNAME Substitution
+
+   A BNAME substitution is performed by replacing the suffix labels of
+   the name being sought matching the owner name of the BNAME resource
+   record with the string of labels in the RDATA field.  The matching
+   labels end with the root label in all cases.  Only whole labels are
+   replaced.
+
+3.3.  The BNAME Rules
+
+   There are two rules which governs the use of BNAMEs in a zone file.
+   The first one is that there SHOULD be no descendants under the owner
+   of the BNAME.  The second one is that no resource records can co-
+   exist with the BNAME for the same name except the DNSSEC related
+   resource record types.  It means that if a BNAME RR is present at a
+   node N, there MUST be no other data except the DNSSEC related
+   resource record types at N and no data at any descendant of N. This
+   restriction applies only to records of the same class as the BNAME
+   record.
+
+
+4.  Query Processing
+
+   To exploit the BNAME mechanism the name resolution algorithms
+
+
+
+Yao, et al.             Expires February 12, 2011               [Page 4]
+
+Internet-Draft                    bname                      August 2010
+
+
+   [RFC1034] must be modified slightly for both servers and resolvers.
+   Both modified algorithms incorporate the operation of making a
+   substitution on a name (either QNAME or SNAME) under control of a
+   BNAME record.  This operation will be referred to as "the BNAME
+   substitution".
+
+4.1.  Processing by Servers
+
+   For a server performing non-recursive service steps 3.a, 3.c and 4 of
+   section 4.3.2 [RFC1034] are changed to check for a BNAME record, and
+   to return certain BNAME records from zone data and the cache.
+
+   If the owner name of the bname is the suffix of the name queryed but
+   different, when preparing a response, a server performing a BNAME
+   substitution will in all cases include the relevant BNAME RR in the
+   answer section.  A CNAME RR is synthesized and included in the answer
+   section.  This will help the client to reach the correct DNS data.
+
+   If the owner name of the bname is same with the name queryed, when
+   preparing a response, a server performing a BNAME substitution will
+   not include the relevant BNAME RR in the answer section unless the
+   type queryed is BNAME.  A CNAME RR will be synthesized and included
+   in the answer section unless the type queryed is BNAME or the query
+   is the DNSSEC query.
+
+   The provided synthesized CNAME RR if there has one, MUST have
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yao, et al.             Expires February 12, 2011               [Page 5]
+
+Internet-Draft                    bname                      August 2010
+
+
+      The same CLASS as the QCLASS of the query,
+
+      TTL equal to the corresponding BNAME RR,
+
+      An <owner> equal to the QNAME in effect at the moment the BNAME RR
+      was encountered, and
+
+      An RDATA field containing the new QNAME formed by the action of
+      the BNAME substitution.
+
+
+   The revised server algorithm is:
+
+
+   1. Set or clear the value of recursion available in the response
+      depending on whether the name server is willing to provide
+      recursive service.  If recursive service is available and
+      requested via the RD bit in the query, go to step 5, otherwise
+      step 2.
+
+   2. Search the available zones for the zone which is the nearest
+      ancestor to QNAME.  If such a zone is found, go to step 3,
+      otherwise step 4.
+
+   3. Start matching down, label by label, in the zone.  The matching
+      process can terminate several ways:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yao, et al.             Expires February 12, 2011               [Page 6]
+
+Internet-Draft                    bname                      August 2010
+
+
+     a. If the whole of QNAME is matched, we have found the node.
+
+         If the data at the node is a CNAME, and QTYPE doesn't match
+         CNAME, copy the CNAME RR into the answer section of the
+         response, change QNAME to the canonical name in the CNAME RR,
+         and go back to step 1.
+
+         If the data at the node is a BNAME, and QTYPE doesn't
+         match BNAME, copy the BNAME RR and also a corresponding,
+         synthesized CNAME RR into the answer section of the
+         response, change QNAME to the name carried as RDATA in
+         the BNAME RR, and go back to step 1.
+
+         Otherwise, copy all RRs which match QTYPE into the answer
+         section and go to step 6.
+
+      b. If a match would take us out of the authoritative data, we have
+         a referral.  This happens when we encounter a node with NS RRs
+         marking cuts along the bottom of a zone.
+
+         Copy the NS RRs for the subzone into the authority section of
+         the reply.  Put whatever addresses are available into the
+         additional section, using glue RRs if the addresses are not
+         available from authoritative data or the cache.  Go to step 4.
+
+      c. If at some label, a match is impossible (i.e., the
+         corresponding label does not exist), look to see whether the
+         last label matched has a BNAME record.
+
+
+         If a BNAME record exists at that point, copy that record into
+         the answer section.  If substitution of its <target> for its
+         <owner> in QNAME would overflow the legal size for a <domain-
+         name>, set RCODE to YXDOMAIN [RFC2136] and exit; otherwise
+         perform the substitution and continue.  The server SHOULD
+         synthesize a corresponding CNAME record as described above and
+         include it in the answer section.  Go back to step 1.
+
+         If there was no BNAME record, look to see if the "*" label
+         exists.
+
+         If the "*" label does not exist, check whether the name we are
+         looking for is the original QNAME in the query or a name we
+         have followed due to a CNAME.  If the name is original, set an
+         authoritative name error in the response and exit.  Otherwise
+         just exit.
+
+
+
+
+
+Yao, et al.             Expires February 12, 2011               [Page 7]
+
+Internet-Draft                    bname                      August 2010
+
+
+
+         If the "*" label does exist, match RRs at that node against
+         QTYPE.  If any match, copy them into the answer section, but
+         set the owner of the RR to be QNAME, and not the node with the
+         "*" label.  Go to step 6.
+
+
+   4. Start matching down in the cache.  If QNAME is found in the cache,
+      copy all RRs attached to it that match QTYPE into the answer
+      section.  If QNAME is not found in the cache but a BNAME record is
+      present at QNAME, copy that BNAME record into the
+      answer section.  If there was no delegation from authoritative
+      data, look for the best one from the cache, and put it in the
+      authority section.  Go to step 6.
+
+   5. Use the local resolver or a copy of its algorithm (see resolver
+      section of this memo) to answer the query.  Store the results,
+      including any intermediate CNAMEs and BNAMEs, in the answer
+      section of the response.
+
+   6. Using local data only, attempt to add other RRs which may be
+      useful to the additional section of the query.  Exit.
+
+
+
+   Note that there will be at most one ancestor with a BNAME as
+   described in step 4 unless some zone's data is in violation of the
+   no-descendants limitation in section 3.  An implementation might take
+   advantage of this limitation by stopping the search of step 3c or
+   step 4 when a BNAME record is encountered.
+
+
+4.2.  Processing by Resolvers
+
+   A resolver or a server providing recursive service must be modified
+   to treat a BNAME as somewhat analogous to a CNAME.  The resolver
+   algorithm of [RFC1034] section 5.3.3 is modified to renumber step 4.d
+   as 4.e and insert a new 4.d.  The complete algorithm becomes:
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yao, et al.             Expires February 12, 2011               [Page 8]
+
+Internet-Draft                    bname                      August 2010
+
+
+   1. See if the answer is in local information, and if so return it to
+      the client.
+
+   2. Find the best servers to ask.
+
+   3. Send them queries until one returns a response.
+
+   4. Analyze the response, either:
+
+      a. if the response answers the question or contains a name error,
+         cache the data as well as returning it back to the client.
+
+      b. if the response contains a better delegation to other servers,
+         cache the delegation information, and go to step 2.
+
+      c. if the response shows a CNAME and that is not the answer
+         itself, cache the CNAME, change the SNAME to the canonical name
+         in the CNAME RR and go to step 1.
+
+      d. if the response shows a BNAME and that is not the answer
+         itself, cache the BNAME.  If substitution of the BNAME's
+         <target> for its <owner> in the SNAME would overflow the legal
+         size for a <domain-name>, return an implementation-dependent
+         error to the application; otherwise perform the substitution
+         and go to step 1.
+
+      e. if the response shows a server failure or other bizarre
+         contents, delete the server from the SLIST and go back to step
+         3.
+
+
+   A resolver or recursive server which understands BNAME records but
+   sends non-extended queries MUST augment step 4.c by deleting from the
+   reply any CNAME records which have an <owner> which is a subdomain of
+   the <owner> of any BNAME record in the response.
+
+
+5.  BNAME in DNSSEC
+
+5.1.  BNAME validating
+
+   With the deployment of DNSSEC, more and more servers and resolvers
+   will support DNSSEC.  In order to make BNAME valid in DNSSEC
+   verification, the DNSSEC enabled resolvers and servers MUST support
+   BNAME.  The synthesized CNAME in the answer section for the BNAME
+   will never be signed if there has one.
+
+   If the owner name of the bname is the suffix of the name queryed but
+
+
+
+Yao, et al.             Expires February 12, 2011               [Page 9]
+
+Internet-Draft                    bname                      August 2010
+
+
+   different, DNSSEC validators MUST understand BNAME, verify the BNAME
+   and then checking that the CNAME was properly synthesized in order to
+   verify the synthesized CNAME.
+
+   If the owner name of the bname is same with the name queryed, DNSSEC
+   validators MUST understand BNAME and verify the BNAME.  The BNAME
+   enabled resolver (validator) should do somewhat analogous to a CNAME
+   for further query.
+
+   In any negative response, the NSEC or NSEC3 [RFC5155] record type bit
+   map SHOULD be checked to see that there was no BNAME that could have
+   been applied.  If the BNAME bit in the type bit map is set and the
+   query type is not BNAME, then BNAME substitution should have been
+   done.
+
+5.2.  BNAME alias algorithm identifiers
+
+   In order to prevent BNAME-unaware resolvers from attempting to
+   validate responses from BNAME-signed zones, this specification
+   allocates two new DNSKEY algorithm identifiers.  Algorithm Y, DSA-
+   BNAME-SHA1 is an alias for algorithm 3, DSA.  Algorithm Z, RSASHA1-
+   BNAME-SHA1 is an alias for algorithm 5, RSASHA1.  These are not new
+   algorithms, they are additional identifiers for the existing
+   algorithms.  Zones signed according to this specification MUST only
+   use these algorithm identifiers for their DNSKEY RRs.  The BNAME-
+   unaware resolvers will not know these new identifiers and treat
+   responses from the BNAME signed zone as insecure, otherwise the bname
+   RR will be regarded as bogus if there is no such a mechanism.  These
+   algorithm identifiers are used with the BNAME hash algorithm SHA1.
+   Using other BNAME hash algorithms requires allocation of a new alias.
+   Validating resolvers which follow the BNAME specification MUST
+   recognize the new alias algorithm identifier.
+
+
+6.  IANA Considerations
+
+   IANA is requested to assign the number to XX.  This document updates
+   the IANA registry "DNS SECURITY ALGORITHM NUMBERS".  IANA is
+   requested to assign the number to Y and Z.
+
+   [[anchor14: Note in draft: before this document goes to WG Last call,
+   it is better that we list all DNSSEC algorithms that need to be
+   aliased to reflect compatibility with this extension.]]
+
+
+7.  Security Considerations
+
+   Both ASCII domain name labels and non-ASCII ones have some aliases.
+
+
+
+Yao, et al.             Expires February 12, 2011              [Page 10]
+
+Internet-Draft                    bname                      August 2010
+
+
+   We can bundle the domain name labels and their aliases through BNAME
+   in the DNS resolutions.  The name labels and their aliases in the
+   particular languages are only known by those who know these
+   languages.  Those labels may be regarded as different ones by those
+   who don't know those languages.  Those who do not know the aliases
+   should only use the familar ones.  The applications will not know the
+   aliases unless they are properly configured.
+
+
+8.  Acknowledgements
+
+   Because the BNAME is very similar to DNAME, the authors learn a lot
+   from [RFC2672].  Many ideas are from the discussion in the DNSOP and
+   DNSEXT mailling list.  Thanks a lot to all in the list.  Many
+   important comments and suggestions are contributed by many members of
+   the DNSEXT and DNSOP WGs.  The authors especially thanks the
+   following ones:Niall O'Reilly, Glen Zorn, Mark Andrews, George
+   Barwood,Olafur Gudmundsson, Sun Guonian and Hanfeng for improving
+   this document.
+
+
+9.  Change History
+
+   [[anchor17: RFC Editor: Please remove this section.]]
+
+9.1.  draft-yao-dnsext-bname: Version 00
+
+   o  Bundle DNS Name Redirection
+
+9.2.  draft-yao-dnsext-bname: Version 01
+
+   o  Improve the algorithm
+   o  Improve the text
+
+9.3.  draft-yao-dnsext-bname: Version 02
+
+   o  Add the DNSSEC discussion
+   o  Improve the text
+
+9.4.  draft-yao-dnsext-bname: Version 03
+
+   o  Update the DNSSEC discussion
+   o  Update the IANA consideration
+
+
+10.  References
+
+
+
+
+
+Yao, et al.             Expires February 12, 2011              [Page 11]
+
+Internet-Draft                    bname                      August 2010
+
+
+10.1.  Normative References
+
+   [ASCII]    American National Standards Institute (formerly United
+              States of America Standards Institute), "USA Code for
+              Information Interchange", ANSI X3.4-1968, 1968.
+
+   [EDNS0]    Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
+              RFC 2671, August 1999.
+
+   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
+              STD 13, RFC 1034, November 1987.
+
+   [RFC1035]  Mockapetris, P., "Domain names - implementation and
+              specification", STD 13, RFC 1035, November 1987.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2136]  Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
+              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
+              RFC 2136, April 1997.
+
+   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
+              RFC 2671, August 1999.
+
+   [RFC2672]  Crawford, M., "Non-Terminal DNS Name Redirection",
+              RFC 2672, August 1999.
+
+   [RFC3490]  Faltstrom, P., Hoffman, P., and A. Costello,
+              "Internationalizing Domain Names in Applications (IDNA)",
+              RFC 3490, March 2003.
+
+   [RFC3597]  Gustafsson, A., "Handling of Unknown DNS Resource Record
+              (RR) Types", RFC 3597, September 2003.
+
+   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
+              10646", RFC 3629, November 2003.
+
+   [RFC3743]  Konishi, K., Huang, K., Qian, H., and Y. Ko, "Joint
+              Engineering Team (JET) Guidelines for Internationalized
+              Domain Names (IDN) Registration and Administration for
+              Chinese, Japanese, and Korean", RFC 3743, April 2004.
+
+   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "DNS Security Introduction and Requirements",
+              RFC 4033, March 2005.
+
+   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+
+
+
+Yao, et al.             Expires February 12, 2011              [Page 12]
+
+Internet-Draft                    bname                      August 2010
+
+
+              Rose, "Resource Records for the DNS Security Extensions",
+              RFC 4034, March 2005.
+
+   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "Protocol Modifications for the DNS Security
+              Extensions", RFC 4035, March 2005.
+
+   [RFC5155]  Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
+              Security (DNSSEC) Hashed Authenticated Denial of
+              Existence", RFC 5155, March 2008.
+
+10.2.  Informative References
+
+   [RFC2672bis]
+              Rose, S. and W. Wijngaards, "Update to DNAME Redirection
+              in the DNS", Internet-Draft ietf-dnsext-rfc2672bis-dname-
+              17.txt, 6 2009.
+
+
+Authors' Addresses
+
+   Jiankang YAO
+   CNNIC
+   No.4 South 4th Street, Zhongguancun
+   Beijing
+
+   Phone: +86 10 58813007
+   Email: yaojk@cnnic.cn
+
+
+   Xiaodong LEE
+   CNNIC
+   No.4 South 4th Street, Zhongguancun
+   Beijing
+
+   Phone: +86 10 58813020
+   Email: lee@cnnic.cn
+
+
+   Paul Vixie
+   Internet Software Consortium
+   950 Charter Street
+   Redwood City, CA
+
+   Phone: +1 650 779 7001
+   Email: vixie@isc.org
+
+
+
+
+
+Yao, et al.             Expires February 12, 2011              [Page 13]
+
+
+