diff --git a/FAQ.xml b/FAQ.xml
index c8bb64ccc6..d0f903be78 100644
--- a/FAQ.xml
+++ b/FAQ.xml
@@ -1,7 +1,7 @@
 <!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
        "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" []>
 <!--
- - Copyright (C) 2004-2010, 2012-2014  Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010, 2013  Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003  Internet Software Consortium.
  -
  - Permission to use, copy, modify, and/or distribute this software for any
@@ -30,9 +30,7 @@
       <year>2008</year>
       <year>2009</year>
       <year>2010</year>
-      <year>2012</year>
       <year>2013</year>
-      <year>2014</year>
       <holder>Internet Systems Consortium, Inc. ("ISC")</holder>
     </copyright>
     <copyright>
diff --git a/doc/rfc/rfc5936.txt b/doc/rfc/rfc5936.txt
new file mode 100644
index 0000000000..7a58c49c65
--- /dev/null
+++ b/doc/rfc/rfc5936.txt
@@ -0,0 +1,1627 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                          E. Lewis
+Request for Comments: 5936                                 NeuStar, Inc.
+Updates: 1034, 1035                                       A. Hoenes, Ed.
+Category: Standards Track                                         TR-Sys
+ISSN: 2070-1721                                                June 2010
+
+
+                   DNS Zone Transfer Protocol (AXFR)
+
+Abstract
+
+   The standard means within the Domain Name System protocol for
+   maintaining coherence among a zone's authoritative name servers
+   consists of three mechanisms.  Authoritative Transfer (AXFR) is one
+   of the mechanisms and is defined in RFC 1034 and RFC 1035.
+
+   The definition of AXFR has proven insufficient in detail, thereby
+   forcing implementations intended to be compliant to make assumptions,
+   impeding interoperability.  Yet today we have a satisfactory set of
+   implementations that do interoperate.  This document is a new
+   definition of AXFR -- new in the sense that it records an accurate
+   definition of an interoperable AXFR mechanism.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc5936.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lewis & Hoenes               Standards Track                    [Page 1]
+
+RFC 5936            DNS Zone Transfer Protocol (AXFR)          June 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
+   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.
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lewis & Hoenes               Standards Track                    [Page 2]
+
+RFC 5936            DNS Zone Transfer Protocol (AXFR)          June 2010
+
+
+Table of Contents
+
+   1. Introduction ....................................................4
+      1.1. Definition of Terms ........................................4
+      1.2. Scope ......................................................5
+      1.3. Context ....................................................5
+      1.4. Coverage and Relationship to Original AXFR Specification ...5
+   2. AXFR Messages ...................................................6
+      2.1. AXFR Query .................................................8
+           2.1.1. Header Values .......................................8
+           2.1.2. Question Section ...................................10
+           2.1.3. Answer Section .....................................10
+           2.1.4. Authority Section ..................................10
+           2.1.5. Additional Section .................................10
+      2.2. AXFR Response .............................................11
+           2.2.1. Header Values ......................................12
+           2.2.2. Question Section ...................................14
+           2.2.3. Answer Section .....................................14
+           2.2.4. Authority Section ..................................14
+           2.2.5. Additional Section .................................14
+      2.3. TCP Connection Aborts .....................................15
+   3. Zone Contents ..................................................15
+      3.1. Records to Include ........................................15
+      3.2. Delegation Records ........................................16
+      3.3. Glue Records ..............................................18
+      3.4. Name Compression ..........................................19
+      3.5. Occluded Names ............................................19
+   4. Transport ......................................................20
+      4.1. TCP .......................................................20
+           4.1.1. AXFR Client TCP ....................................21
+           4.1.2. AXFR Server TCP ....................................22
+      4.2. UDP .......................................................22
+   5. Authorization ..................................................22
+   6. Zone Integrity .................................................23
+   7. Backwards Compatibility ........................................24
+      7.1. Server ....................................................24
+      7.2. Client ....................................................25
+   8. Security Considerations ........................................25
+   9. IANA Considerations ............................................25
+   10. Internationalization Considerations ...........................25
+   11. Acknowledgments ...............................................25
+   12. References ....................................................26
+      12.1. Normative References .....................................26
+      12.2. Informative References ...................................28
+
+
+
+
+
+
+
+Lewis & Hoenes               Standards Track                    [Page 3]
+
+RFC 5936            DNS Zone Transfer Protocol (AXFR)          June 2010
+
+
+1.  Introduction
+
+   The Domain Name System standard facilities for maintaining coherent
+   servers for a zone consist of three elements.  Authoritative Transfer
+   (AXFR) is defined in "Domain Names - Concepts and Facilities"
+   [RFC1034] (referred to in this document as RFC 1034) and "Domain
+   Names - Implementation and Specification" [RFC1035] (henceforth RFC
+   1035).  Incremental Zone Transfer (IXFR) is defined in "Incremental
+   Zone Transfer in DNS" [RFC1995].  A mechanism for prompt notification
+   of zone changes (NOTIFY) is defined in "A Mechanism for Prompt
+   Notification of Zone Changes (DNS NOTIFY)" [RFC1996].  The goal of
+   these mechanisms is to enable a set of DNS name servers to remain
+   coherently authoritative for a given zone.
+
+   This document re-specifies the AXFR mechanism as it is deployed in
+   the Internet at large, hopefully with the precision expected from
+   modern Internet Standards, and thereby updates RFC 1034 and RFC 1035.
+
+1.1.  Definition of Terms
+
+   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 "Key words for use in
+   RFCs to Indicate Requirement Levels" [BCP14].
+
+   Use of "newer"/"new" and "older"/"old" DNS refers to implementations
+   written after and prior to the publication of this document.
+
+   "General-purpose DNS implementation" refers to DNS software developed
+   for widespread use.  This includes resolvers and servers freely
+   accessible as libraries and standalone processes.  This also includes
+   proprietary implementations used only in support of DNS service
+   offerings.
+
+   "Turnkey DNS implementation" refers to custom-made, single-use
+   implementations of DNS.  Such implementations consist of software
+   that employs the DNS protocol message format yet does not conform to
+   the entire range of DNS functionality.
+
+   The terms "AXFR session", "AXFR server", and "AXFR client" will be
+   introduced in the first paragraph of Section 2, after some more
+   context has been established.
+
+
+
+
+
+
+
+
+
+Lewis & Hoenes               Standards Track                    [Page 4]
+
+RFC 5936            DNS Zone Transfer Protocol (AXFR)          June 2010
+
+
+1.2.  Scope
+
+   In general terms, authoritative name servers for a given zone can use
+   various means to achieve coherency of the zone contents they serve.
+   For example, there are DNS implementations that assemble answers from
+   data stored in relational databases (as opposed to master files),
+   relying on the database's non-DNS means to synchronize the database
+   instances.  Some of these non-DNS solutions interoperate in some
+   fashion.  However, AXFR, IXFR, and NOTIFY are the only protocol-
+   defined in-band mechanisms to provide coherence of a set of name
+   servers, and they are the only mechanisms specified by the IETF.
+
+   This document does not cover incoherent DNS situations.  There are
+   applications of the DNS in which servers for a zone are designed to
+   be incoherent.  For these configurations, a coherency mechanism as
+   described here would be unsuitable.
+
+   A DNS implementation is not required to support AXFR, IXFR, and
+   NOTIFY, but it should have some means for maintaining name server
+   coherency.  A general-purpose DNS implementation will likely support
+   AXFR (and in the same vein IXFR and NOTIFY), but turnkey DNS
+   implementations may exist without AXFR.
+
+1.3.  Context
+
+   Besides describing the mechanisms themselves, there is the context in
+   which they operate to consider.  In the initial specifications of
+   AXFR (and IXFR and NOTIFY), little consideration was given to
+   security and privacy issues.  Since the original definition of AXFR,
+   new opinions have appeared on the access to an entire zone's
+   contents.  In this document, the basic mechanisms will be discussed
+   separately from the permission to use these mechanisms.
+
+1.4.  Coverage and Relationship to Original AXFR Specification
+
+   This document concentrates on just the definition of AXFR.  Any
+   effort to update the specification of the IXFR or NOTIFY mechanisms
+   is left to different documents.
+
+   The original "specification" of the AXFR sub-protocol is scattered
+   through RFC 1034 and RFC 1035.  Section 2.2 of RFC 1035 (on page 5)
+   depicts the scenario for which AXFR has been designed.  Section 4.3.5
+   of RFC 1034 describes the zone synchronization strategies in general
+   and rules for the invocation of a full zone transfer via AXFR; the
+   fifth paragraph of that section contains a very short sketch of the
+   AXFR protocol; Section 5.5 of RFC 2181 has corrected a significant
+   flaw in that specification.  Section 3.2.3 of RFC 1035 has assigned
+   the code point for the AXFR QTYPE (see Section 2.1.2 below for more
+
+
+
+Lewis & Hoenes               Standards Track                    [Page 5]
+
+RFC 5936            DNS Zone Transfer Protocol (AXFR)          June 2010
+
+
+   details).  Section 4.2 of RFC 1035 discusses how the DNS uses the
+   transport layer and briefly explains why UDP transport is deemed
+   inappropriate for AXFR; the last paragraph of Section 4.2.2 gives
+   details regarding TCP connection management for AXFR.  Finally, the
+   second paragraph of Section 6.3 in RFC 1035 mandates server behavior
+   when zone data changes occur during an ongoing zone transfer using
+   AXFR.
+
+   This document will update the specification of AXFR.  To this end, it
+   fully specifies the record formats and processing rules for AXFR,
+   largely expanding on paragraph 5 of Section 4.3.5 of RFC 1034, and it
+   details the transport considerations for AXFR, thus amending Section
+   4.2.2 of RFC 1035.  Furthermore, it discusses backward-compatibility
+   issues and provides policy/management considerations, as well as
+   specific security considerations for AXFR.  The goal of this document
+   is to define AXFR as it is understood by the DNS community to exist
+   today.
+
+2.  AXFR Messages
+
+   An AXFR session consists of an AXFR query message and the sequence of
+   AXFR response messages returned for it.  In this document, the AXFR
+   client is the sender of the AXFR query, and the AXFR server is the
+   responder.  (Use of terms such as master, slave, primary, and
+   secondary are not important for defining AXFR.)  The use of the word
+   "session" without qualification refers to an AXFR session.
+
+   An important aspect to keep in mind is that the definition of AXFR is
+   restricted to TCP [RFC0793] (see Section 4 for details).  The design
+   of the AXFR process has certain inherent features that are not easily
+   ported to UDP [RFC0768].
+
+   The basic format of an AXFR message is the DNS message as defined in
+   Section 4 ("MESSAGES") of RFC 1035 [RFC1035], updated by the
+   following documents.
+
+   o  The "Basic" DNS specification:
+
+      -  "A Mechanism for Prompt Notification of Zone Changes
+          (DNS NOTIFY)" [RFC1996]
+
+      -  "Dynamic Updates in the Domain Name System (DNS UPDATE)"
+          [RFC2136]
+
+      -  "Clarifications to the DNS Specification" [RFC2181]
+
+      -  "Extension Mechanisms for DNS (EDNS0)" [RFC2671]
+
+
+
+
+Lewis & Hoenes               Standards Track                    [Page 6]
+
+RFC 5936            DNS Zone Transfer Protocol (AXFR)          June 2010
+
+
+      -  "Secret Key Transaction Authentication for DNS (TSIG)"
+          [RFC2845]
+
+      -  "Secret Key Establishment for DNS (TKEY RR)" [RFC2930]
+
+      -  "Obsoleting IQUERY" [RFC3425]
+
+      -  "Handling of Unknown DNS Resource Record (RR) Types"
+          [RFC3597]
+
+      -  "HMAC SHA (Hashed Message Authentication Code, Secure Hash
+          Algorithm) TSIG Algorithm Identifiers" [RFC4635]
+
+      -  "Domain Name System (DNS) IANA Considerations" [RFC5395]
+
+   o  Further additions related to the DNS Security Extensions (DNSSEC),
+      defined in these base documents:
+
+      -  "DNS Security Introduction and Requirements" [RFC4033]
+
+      -  "Resource Records for the DNS Security Extensions"
+          [RFC4034]
+
+      -  "Protocol Modifications for the DNS Security Extensions"
+          [RFC4035]
+
+      -  "Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource
+          Records (RRs)" [RFC4509]
+
+      -  "DNS Security (DNSSEC) Hashed Authenticated Denial of
+          Existence" [RFC5155]
+
+      -  "Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG
+          Resource Records for DNSSEC" [RFC5702]
+
+      -  "Clarifications and Implementation Notes for DNSSECbis"
+          [DNSSEC-U]
+
+   These documents contain information about the syntax and semantics of
+   DNS messages.  They do not interfere with AXFR but are also helpful
+   in understanding what will be carried via AXFR.
+
+   For convenience, the synopsis of the DNS message header from
+   [RFC5395] (and the IANA registry for DNS Parameters [DNSVALS]) is
+   reproduced here informally:
+
+
+
+
+
+
+Lewis & Hoenes               Standards Track                    [Page 7]
+
+RFC 5936            DNS Zone Transfer Protocol (AXFR)          June 2010
+
+
+             0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
+           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+           |                      ID                       |
+           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+           |QR|   OpCode  |AA|TC|RD|RA| Z|AD|CD|   RCODE   |
+           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+           |                QDCOUNT/ZOCOUNT                |
+           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+           |                ANCOUNT/PRCOUNT                |
+           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+           |                NSCOUNT/UPCOUNT                |
+           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+           |                    ARCOUNT                    |
+           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+   This document makes use of the field names as they appear in this
+   diagram.  The names of sections in the body of DNS messages are
+   capitalized in this document for clarity, e.g., "Additional section".
+
+   The DNS message size limit from [RFC1035] for DNS over UDP (and its
+   extension via the EDNS0 mechanism specified in [RFC2671]) is not
+   relevant for AXFR, as explained in Section 4.  The upper limit on the
+   permissible size of a DNS message over TCP is only restricted by the
+   TCP framing defined in Section 4.2.2 of RFC 1035, which specifies a
+   two-octet message length field, understood to be unsigned, and thus
+   causing a limit of 65535 octets.  This limit is not changed by EDNS0.
+
+   Note that the TC (truncation) bit is never set by an AXFR server nor
+   considered/read by an AXFR client.
+
+2.1.  AXFR Query
+
+   An AXFR query is sent by a client whenever there is a reason to ask.
+   This might be because of scheduled or triggered zone maintenance
+   activities (see Section 4.3.5 of RFC 1034 and DNS NOTIFY [RFC1996],
+   respectively) or as a result of a command line request, say for
+   debugging.
+
+2.1.1.  Header Values
+
+   These are the DNS message header values for an AXFR query.
+
+      ID          Selected by client; see Note a)
+
+      QR          MUST be 0 (Query)
+
+      OPCODE      MUST be 0 (Standard Query)
+
+
+
+
+Lewis & Hoenes               Standards Track                    [Page 8]
+
+RFC 5936            DNS Zone Transfer Protocol (AXFR)          June 2010
+
+
+      Flags:
+         AA       "n/a" -- see Note b)
+         TC       "n/a" -- see Note b)
+         RD       "n/a" -- see Note b)
+         RA       "n/a" -- see Note b)
+         Z        "mbz" -- see Note c)
+         AD       "n/a" -- see Note b)
+         CD       "n/a" -- see Note b)
+
+      RCODE       MUST be 0 (No error)
+
+      QDCOUNT     Number of entries in Question section;   MUST be 1
+
+      ANCOUNT     Number of entries in Answer section;     MUST be 0
+
+      NSCOUNT     Number of entries in Authority section;  MUST be 0
+
+      ARCOUNT     Number of entries in Additional section -- see Note d)
+
+   Notes:
+
+   a) Set to any value that the client is not already using with the
+      same server.  There is no specific means for selecting the value
+      in this field.  (Recall that AXFR is done only via TCP connections
+      -- see Section 4, "Transport".)
+
+      A server MUST reply using messages that use the same message ID to
+      allow a client to have multiple queries outstanding concurrently
+      over the same TCP connection -- see Note a) in Section 2.2.1 for
+      more details.
+
+   b) "n/a" -- The value in this field has no meaning in the context of
+      AXFR query messages.  For the client, it is RECOMMENDED that the
+      value be zero.  The server MUST ignore this value.
+
+   c) "mbz" -- The client MUST set this bit to 0; the server MUST ignore
+      it.
+
+   d) The client MUST set this field to the number of resource records
+      it places into the Additional section.  In the absence of explicit
+      specification of new RRs to be carried in the Additional section
+      of AXFR queries, the value MAY be 0, 1, or 2.  See Section 2.1.5,
+      "Additional Section", for details on the currently applicable RRs.
+
+
+
+
+
+
+
+
+Lewis & Hoenes               Standards Track                    [Page 9]
+
+RFC 5936            DNS Zone Transfer Protocol (AXFR)          June 2010
+
+
+2.1.2.  Question Section
+
+   The Question section of the AXFR query MUST conform to Section 4.1.2
+   of RFC 1035, and contain a single resource record with the following
+   values:
+
+      QNAME       the name of the zone requested
+
+      QTYPE       AXFR (= 252), the pseudo-RR type for zone transfer
+                  [DNSVALS]
+
+      QCLASS      the class of the zone requested [DNSVALS]
+
+2.1.3.  Answer Section
+
+   The Answer section MUST be empty.
+
+2.1.4.  Authority Section
+
+   The Authority section MUST be empty.
+
+2.1.5.  Additional Section
+
+   Currently, two kinds of resource records are defined that can appear
+   in the Additional section of AXFR queries and responses: EDNS and DNS
+   transaction security.  Future specifications defining RRs that can be
+   carried in the Additional section of normal DNS transactions need to
+   explicitly describe their use with AXFR, should that be desired.
+
+   The client MAY include one OPT resource record [RFC2671].  If the
+   server does not support EDNS0, the client MUST send this section
+   without an OPT resource record if there is a retry.  However, the
+   protocol does not define an explicit indication that the server does
+   not support EDNS0; that needs to be inferred by the client.  Often,
+   the server will return a FormErr(1) that might be related to the OPT
+   resource record.  Note that, at the time of this writing, only the
+   EXTENDED-RCODE field of the OPT RR is meaningful in the context of
+   AXFR; future specifications of EDNS flags and/or EDNS options must
+   describe their usage in the context of AXFR, if applicable.
+
+   The client MAY include one transaction integrity and authentication
+   resource record, currently a choice of TSIG [RFC2845] or SIG(0)
+   [RFC2931].  If the server has indicated that it does not recognize
+   the resource record, and that the error is indeed caused by the
+   resource record, the client probably should not try again.  Removing
+   the security data in the face of an obstacle ought to only be done
+   with full awareness of the implication of doing so.
+
+
+
+
+Lewis & Hoenes               Standards Track                   [Page 10]
+
+RFC 5936            DNS Zone Transfer Protocol (AXFR)          June 2010
+
+
+   In general, if an AXFR client is aware that an AXFR server does not
+   support a particular mechanism, the client SHOULD NOT attempt to
+   engage the server using the mechanism (or engage the server at all).
+   A client could become aware of a server's abilities via a
+   configuration setting or via some other (as yet) undefined means.
+
+   The range of permissible resource records that MAY appear in the
+   Additional section might change over time.  If either a change to an
+   existing resource record (like the OPT RR for EDNS) is made or a new
+   Additional section record is created, the new definitions ought to
+   include a discussion on the applicability and impact upon AXFR.
+   Future resource records residing in the Additional section might have
+   an effect that is orthogonal to AXFR, and so can ride through the
+   session as opaque data.  In this case, a "wise" implementation ought
+   to be able to pass these records through without disruption.
+
+2.2.  AXFR Response
+
+   The AXFR response will consist of one or more messages.  The special
+   case of a server closing the TCP connection without sending an AXFR
+   response is covered in Section 2.3.
+
+   An AXFR response that is transferring the zone's contents will
+   consist of a series (which could be a series of length 1) of DNS
+   messages.  In such a series, the first message MUST begin with the
+   SOA resource record of the zone, and the last message MUST conclude
+   with the same SOA resource record.  Intermediate messages MUST NOT
+   contain the SOA resource record.  The AXFR server MUST copy the
+   Question section from the corresponding AXFR query message into the
+   first response message's Question section.  For subsequent messages,
+   it MAY do the same or leave the Question section empty.
+
+   The AXFR protocol treats the zone contents as an unordered collection
+   (or to use the mathematical term, a "set") of RRs.  Except for the
+   requirement that the transfer must begin and end with the SOA RR,
+   there is no requirement to send the RRs in any particular order or
+   grouped into response messages in any particular way.  Although
+   servers typically do attempt to send related RRs (such as the RRs
+   forming an RRset, and the RRsets of a name) as a contiguous group or,
+   when message space allows, in the same response message, they are not
+   required to do so, and clients MUST accept any ordering and grouping
+   of the non-SOA RRs.  Each RR SHOULD be transmitted only once, and
+   AXFR clients MUST ignore any duplicate RRs received.
+
+   Each AXFR response message SHOULD contain a sufficient number of RRs
+   to reasonably amortize the per-message overhead, up to the largest
+   number that will fit within a DNS message (taking the required
+   content of the other sections into account, as described below).
+
+
+
+Lewis & Hoenes               Standards Track                   [Page 11]
+
+RFC 5936            DNS Zone Transfer Protocol (AXFR)          June 2010
+
+
+   Some old AXFR clients expect each response message to contain only a
+   single RR.  To interoperate with such clients, the server MAY
+   restrict response messages to a single RR.  As there is no standard
+   way to automatically detect such clients, this typically requires
+   manual configuration at the server.
+
+   To indicate an error in an AXFR response, the AXFR server sends a
+   single DNS message when the error condition is detected, with the
+   response code set to the appropriate value for the condition
+   encountered.  Such a message terminates the AXFR session; it MUST
+   contain a copy of the Question section from the AXFR query in its
+   Question section, but the inclusion of the terminating SOA resource
+   record is not necessary.
+
+   An AXFR server may send a number of AXFR response messages free of an
+   error condition before it sends the message indicating an error.
+
+2.2.1.  Header Values
+
+   These are the DNS message header values for AXFR responses.
+
+      ID          MUST be copied from request -- see Note a)
+
+      QR          MUST be 1 (Response)
+
+      OPCODE      MUST be 0 (Standard Query)
+
+      Flags:
+         AA       normally 1 -- see Note b)
+         TC       MUST be 0 (Not truncated)
+         RD       RECOMMENDED: copy request's value; MAY be set to 0
+         RA       SHOULD be 0 -- see Note c)
+         Z        "mbz" -- see Note d)
+         AD       "mbz" -- see Note d)
+         CD       "mbz" -- see Note d)
+
+      RCODE       See Note e)
+
+      QDCOUNT     MUST be 1 in the first message;
+                  MUST be 0 or 1 in all following messages;
+                  MUST be 1 if RCODE indicates an error
+
+      ANCOUNT     See Note f)
+
+      NSCOUNT     MUST be 0
+
+      ARCOUNT     See Note g)
+
+
+
+
+Lewis & Hoenes               Standards Track                   [Page 12]
+
+RFC 5936            DNS Zone Transfer Protocol (AXFR)          June 2010
+
+
+   Notes:
+
+   a) Because some old implementations behave differently than is now
+      desired, the requirement on this field is stated in detail.  New
+      DNS servers MUST set this field to the value of the AXFR query ID
+      in each AXFR response message for the session.  AXFR clients MUST
+      be able to manage sessions resulting from the issuance of multiple
+      outstanding queries, whether AXFR queries or other DNS queries.  A
+      client SHOULD discard responses that do not correspond (via the
+      message ID) to any outstanding queries.
+
+      Unless the client is sure that the server will consistently set
+      the ID field to the query's ID, the client is NOT RECOMMENDED to
+      issue any other queries until the end of the zone transfer.  A
+      client MAY become aware of a server's abilities via a
+      configuration setting.
+
+   b) If the RCODE is 0 (no error), then the AA bit MUST be 1.  For any
+      other value of RCODE, the AA bit MUST be set according to the
+      rules for that error code.  If in doubt, it is RECOMMENDED that it
+      be set to 1.  It is RECOMMENDED that the value be ignored by the
+      AXFR client.
+
+   c) It is RECOMMENDED that the server set the value to 0; the client
+      MUST ignore this value.
+
+      The server MAY set this value according to the local policy
+      regarding recursive service, but doing so might confuse the
+      interpretation of the response, as AXFR cannot be retrieved
+      recursively.  A client MAY note the server's policy regarding
+      recursive service from this value, but SHOULD NOT conclude that
+      the AXFR response was obtained recursively, even if the RD bit was
+      1 in the query.
+
+   d) "mbz" -- The server MUST set this bit to 0; the client MUST ignore
+      it.
+
+   e) In the absence of an error, the server MUST set the value of this
+      field to NoError(0).  If a server is not authoritative for the
+      queried zone, the server SHOULD set the value to NotAuth(9).
+      (Reminder: Consult the appropriate IANA registry [DNSVALS].)  If a
+      client receives any other value in response, it MUST act according
+      to the error.  For example, a malformed AXFR query or the presence
+      of an OPT resource record sent to an old server will result in a
+      FormErr(1) value.  This value is not set as part of the AXFR-
+      specific response processing.  The same is true for other values
+      indicating an error.
+
+
+
+
+Lewis & Hoenes               Standards Track                   [Page 13]
+
+RFC 5936            DNS Zone Transfer Protocol (AXFR)          June 2010
+
+
+   f) The count of answer records MUST equal the number of resource
+      records in the AXFR Answer section.  When a server is aware that a
+      client will only accept response messages with a single resource
+      record, then the value MUST be 1.  A server MAY be made aware of a
+      client's limitations via configuration data.
+
+   g) The server MUST set this field to the number of resource records
+      it places into the Additional section.  In the absence of explicit
+      specification of new RRs to be carried in the Additional section
+      of AXFR response messages, the value MAY be 0, 1, or 2.  See
+      Section 2.1.5 above for details on the currently applicable RRs
+      and Section 2.2.5 for additional considerations specific to AXFR
+      servers.
+
+2.2.2.  Question Section
+
+   In the first response message, this section MUST be copied from the
+   query.  In subsequent messages, this section MAY be copied from the
+   query, or it MAY be empty.  However, in an error response message
+   (see Section 2.2), this section MUST be copied as well.  The content
+   of this section MAY be used to determine the context of the message,
+   that is, the name of the zone being transferred.
+
+2.2.3.  Answer Section
+
+   The Answer section MUST be populated with the zone contents.  See
+   Section 3 below on encoding zone contents.
+
+2.2.4.  Authority Section
+
+   The Authority section MUST be empty.
+
+2.2.5.  Additional Section
+
+   The contents of this section MUST follow the guidelines for the OPT,
+   TSIG, and SIG(0) RRs, or whatever other future record is possible
+   here.  The contents of Section 2.1.5 apply analogously as well.
+
+   The following considerations specifically apply to AXFR responses:
+
+   If the client has supplied an EDNS OPT RR in the AXFR query and if
+   the server supports EDNS as well, it SHOULD include one OPT RR in the
+   first response message and MAY do so in subsequent response messages
+   (see Section 2.2); the specifications of EDNS options to be carried
+   in the OPT RR may impose stronger requirements.
+
+
+
+
+
+
+Lewis & Hoenes               Standards Track                   [Page 14]
+
+RFC 5936            DNS Zone Transfer Protocol (AXFR)          June 2010
+
+
+   If the client has supplied a transaction security resource record
+   (currently a choice of TSIG and SIG(0)) and the server supports the
+   method chosen by the client, it MUST place the corresponding resource
+   record into the AXFR response message(s), according to the rules
+   specified for that method.
+
+2.3.  TCP Connection Aborts
+
+   If an AXFR client sends a query on a TCP connection and the
+   connection is closed at any point, the AXFR client MUST consider the
+   AXFR session terminated.  The message ID MAY be used again on a new
+   connection, even if the question and AXFR server are the same.
+
+   Facing a dropped connection, a client SHOULD try to make some
+   determination as to whether the connection closure was the result of
+   network activity or due to a decision by the AXFR server.  This
+   determination is not an exact science.  It is up to the AXFR client
+   to react, but the implemented reaction SHOULD NOT be either an
+   endless cycle of retries or an increasing (in frequency) retry rate.
+
+   An AXFR server implementer should take into consideration the dilemma
+   described above when a connection is closed with an outstanding query
+   in the pipeline.  For this reason, a server ought to reserve this
+   course of action for situations in which it believes beyond a doubt
+   that the AXFR client is attempting abusive behavior.
+
+3.  Zone Contents
+
+   The objective of the AXFR session is to request and transfer the
+   contents of a zone, in order to permit the AXFR client to faithfully
+   reconstruct the zone as it exists at the primary server for the given
+   zone serial number.  The word "exists" here designates the externally
+   visible behavior, i.e., the zone content that is being served (handed
+   out to clients) -- not its persistent representation in a zone file
+   or database used by the server -- and that for consistency should be
+   served subsequently by the AXFR client in an identical manner.
+
+   Over time the definition of a zone has evolved from denoting a static
+   set of records to also cover a dynamically updated set of records,
+   and then a potentially continually regenerated set of records (e.g.,
+   RRs synthesized "on the fly" from rule sets or database lookup
+   results in other forms than RR format) as well.
+
+3.1.  Records to Include
+
+   In the Answer section of AXFR response messages, the resource records
+   within a zone for the given serial number MUST appear.  The
+   definition of what belongs in a zone is described in RFC 1034,
+
+
+
+Lewis & Hoenes               Standards Track                   [Page 15]
+
+RFC 5936            DNS Zone Transfer Protocol (AXFR)          June 2010
+
+
+   Section 4.2, "How the database is divided into zones" (in particular
+   Section 4.2.1, "Technical considerations"), and it has been clarified
+   in Section 6 of RFC 2181.
+
+   Zones for which it is impractical to list the entire zone for a
+   serial number are not suitable for AXFR retrieval.  A typical (but
+   not limiting) description of such a zone is a zone consisting of
+   responses generated via other database lookups and/or computed based
+   upon ever-changing data.
+
+3.2.  Delegation Records
+
+   In Section 4.2.1 of RFC 1034, this text appears (keep in mind that
+   the "should" in the quotation predates [BCP14], cf. Section 1.1):
+
+      The RRs that describe cuts ... should be exactly the same as the
+      corresponding RRs in the top node of the subzone.
+
+   There has been some controversy over this statement and the impact on
+   which NS resource records are included in a zone transfer.
+
+   The phrase "that describe cuts" is a reference to the NS set and
+   applicable glue records.  It does not mean that the cut point and
+   apex resource records are identical.  For example, the SOA resource
+   record is only found at the apex.  The discussion here is restricted
+   to just the NS resource record set and glue, as these "describe
+   cuts".
+
+   DNSSEC resource records have special specifications regarding their
+   occurrence at a zone cut and the apex of a zone.  This was first
+   described in Sections 5.3 ff. and 6.2 of RFC 2181 (for the initial
+   specification of DNSSEC), which parts of RFC 2181 now in fact are
+   historical.  The current DNSSEC core document set (see second bullet
+   in Section 2 above) gives the full details for DNSSEC(bis) resource
+   record placement, and Section 3.1.5 of RFC 4035 normatively specifies
+   their treatment during AXFR; the alternate NSEC3 resource record
+   defined later in RFC 5155 behaves identically to the NSEC RR, for the
+   purpose of AXFR.
+
+   Informally:
+
+   o  The DS RRSet only occurs at the parental side of a zone cut and is
+      authoritative data in the parent zone, not the secure child zone.
+
+   o  The DNSKEY RRSet only occurs at the apex of a signed zone and is
+      part of the authoritative data of the zone it serves.
+
+
+
+
+
+Lewis & Hoenes               Standards Track                   [Page 16]
+
+RFC 5936            DNS Zone Transfer Protocol (AXFR)          June 2010
+
+
+   o  Independent RRSIG RRSets occur at the signed parent side of a zone
+      cut and at the apex of a signed zone; they are authoritative data
+      in the respective zone; simple queries for RRSIG resource records
+      may return both RRSets at once if the same server is authoritative
+      for the parent zone and the child zone (Section 3.1.5 of RFC 4035
+      describes how to distinguish these RRs); this seeming ambiguity
+      does not occur for AXFR, since each such RRSIG RRset belongs to a
+      single zone.
+
+   o  Different NSEC [RFC4034] (or NSEC3 [RFC5155]) resource records
+      equally may occur at the parental side of a zone cut and at the
+      apex of a zone; each such resource record belongs to exactly one
+      of these zones and is to be included in the AXFR of that zone.
+
+   One issue is that in operations there are times when the NS resource
+   records for a zone might be different at a cut point in the parent
+   and at the apex of a zone.  Sometimes this is the result of an error,
+   and sometimes it is part of an ongoing change in name servers.  The
+   DNS protocol is robust enough to overcome inconsistencies up to (but
+   not including) there being no parent-indicated NS resource record
+   referencing a server that is able to serve the child zone.  This
+   robustness is one quality that has fueled the success of the DNS.
+   Still, the inconsistency is an error state, and steps need to be
+   taken to make it apparent (if it is unplanned).
+
+   Another issue is that the AXFR server could be authoritative for a
+   different set of zones than the AXFR client.  It is possible that the
+   AXFR server be authoritative for both halves of an inconsistent cut
+   point and that the AXFR client is authoritative for just the parent
+   side of the cut point.
+
+   When facing a situation in which a cut point's NS resource records do
+   not match the authoritative set, the question arises whether an AXFR
+   server responds with the NS resource record set that is in the zone
+   being transferred or the one that is at the authoritative location.
+
+   The AXFR response MUST contain the cut point NS resource record set
+   registered with the zone whether it agrees with the authoritative set
+   or not.  "Registered with" can be widely interpreted to include data
+   residing in the zone file of the zone for the particular serial
+   number (in zone file environments) or as any data configured to be in
+   the zone (database), statically or dynamically.
+
+
+
+
+
+
+
+
+
+Lewis & Hoenes               Standards Track                   [Page 17]
+
+RFC 5936            DNS Zone Transfer Protocol (AXFR)          June 2010
+
+
+   The reasons for this requirement are:
+
+   1) The AXFR server might not be able to determine that there is an
+      inconsistency given local data; hence, requiring consistency would
+      mean a lot more needed work and even network retrieval of data.
+      An authoritative server ought not be required to perform any
+      queries.
+
+   2) By transferring the inconsistent NS resource records from a server
+      that is authoritative for both the cut point and the apex to a
+      client that is not authoritative for both, the error is exposed.
+      For example, an authorized administrator can manually request the
+      AXFR and inspect the results to see the inconsistent records.  (A
+      server authoritative for both halves would otherwise always answer
+      from the more authoritative set, concealing the error.)
+
+   3) The inconsistent NS resource record set might indicate a problem
+      in a registration database.
+
+   4) This requirement is necessary to ensure that retrieving a given
+      (zone, serial) pair by AXFR yields the exact same set of resource
+      records, no matter which of the zone's authoritative servers is
+      chosen as the source of the transfer.
+
+   If an AXFR server were allowed to respond with the authoritative NS
+   RRset of a child zone instead of a parent-side NS RRset in the zone
+   being transferred, the set of records returned could vary depending
+   on whether or not the server happened to be authoritative for the
+   child zone as well.
+
+   The property that a given (zone, serial) pair corresponds to a
+   single, well-defined set of records is necessary for the correct
+   operation of incremental transfer protocols such as IXFR [RFC1995].
+   For example, a client may retrieve a zone by AXFR from one server,
+   and then apply an incremental change obtained by IXFR from a
+   different server.  If the two servers have different ideas of the
+   zone contents, the client can end up attempting to incrementally add
+   records that already exist or to delete records that do not exist.
+
+3.3.  Glue Records
+
+   As quoted in the previous section, Section 4.2.1 of RFC 1034 provides
+   guidance and rationale for the inclusion of glue records as part of
+   an AXFR response.  And, as also argued in the previous section of
+   this document, even when there is an inconsistency between the
+   address in a glue record and the authoritative copy of the name
+   server's address, the glue resource record that is registered as part
+   of the zone for that serial number is to be included.
+
+
+
+Lewis & Hoenes               Standards Track                   [Page 18]
+
+RFC 5936            DNS Zone Transfer Protocol (AXFR)          June 2010
+
+
+   This applies to glue records for any address family [IANA-AF].
+
+   The AXFR response MUST contain the appropriate glue records as
+   registered with the zone.  The interpretation of "registered with" in
+   the previous section applies here.  Inconsistent glue records are an
+   operational matter.
+
+3.4.  Name Compression
+
+   Compression of names in DNS messages is described in RFC 1035,
+   Section 4.1.4, "Message compression".  The issue highlighted here
+   relates to a comment made in RFC 1034, Section 3.1, "Name space
+   specifications and terminology", which says:
+
+      When you receive a domain name or label, you should preserve its
+      case.
+
+   ("Should" in the quote predates [BCP14].)
+
+   Since the primary objective of AXFR is to enable the client to serve
+   the same zone content as the server, unlike such normal DNS responses
+   that are expected to preserve the case in the query, the actual zone
+   transfer needs to retain the case of the labels in the zone content.
+   Hence, name compression in an AXFR message SHOULD be performed in a
+   case-preserving manner, unlike how it is done for "normal" DNS
+   responses.  That is, although when comparing a domain name for
+   matching, "a" equals "A", when comparing for the purposes of message
+   compression for AXFR, "a" is not equal to "A".  Note that this is not
+   the usual definition of name comparison in the DNS protocol and
+   represents a new understanding of the requirement on AXFR servers.
+
+   Rules governing name compression of RDATA in an AXFR message MUST
+   abide by the specification in "Handling of Unknown DNS Resource
+   Record (RR) Types" [RFC3597], specifically, Section 4 on "Domain Name
+   Compression".
+
+3.5.  Occluded Names
+
+   Dynamic Update [RFC2136] operations, and in particular their
+   interaction with DNAME [RFC2672], can have a side effect of occluding
+   names in a zone.  The addition of a delegation point via dynamic
+   update will render all subordinate domain names to be in a limbo,
+   still part of the zone but not available to the lookup process.  The
+   addition of a DNAME resource record has the same impact.  The
+   subordinate names are said to be "occluded".
+
+
+
+
+
+
+Lewis & Hoenes               Standards Track                   [Page 19]
+
+RFC 5936            DNS Zone Transfer Protocol (AXFR)          June 2010
+
+
+   Occluded names MUST be included in AXFR responses.  An AXFR client
+   MUST be able to identify and handle occluded names.  The rationale
+   for this action is based on a speedy recovery if the dynamic update
+   operation was in error and is to be undone.
+
+4.  Transport
+
+   AXFR sessions are currently restricted to TCP by Section 4.3.5 of RFC
+   1034, which states:
+
+      Because accuracy is essential, TCP or some other reliable protocol
+      must be used for AXFR requests.
+
+   The restriction to TCP is also mentioned in Section 6.1.3.2 of
+   "Requirements for Internet Hosts - Application and Support"
+   [RFC1123].
+
+   The most common scenario is for an AXFR client to open a TCP
+   connection to the AXFR server, send an AXFR query, receive the AXFR
+   response, and then close the connection.  But variations of that most
+   simple scenario are legitimate and likely: in particular, sending a
+   query for the zone's SOA resource record first over the same TCP
+   connection, and reusing an existing TCP connection for other queries.
+
+   Therefore, the assumption that a TCP connection is dedicated to a
+   single AXFR session is incorrect.  This wrong assumption has led to
+   implementation choices that prevent either multiple concurrent zone
+   transfers or the use of an open connection for other queries.
+
+   Since the early days of the DNS, operators who have sets of name
+   servers that are authoritative for a common set of zones have found
+   it desirable to be able to have multiple concurrent zone transfers in
+   progress; this way, a name server does not have to wait for one zone
+   transfer to complete before the next can begin.  RFC 1035 did not
+   exclude this possibility, but legacy implementations failed to
+   support this functionality efficiently, over a single TCP connection.
+   The remaining presence of such legacy implementations makes it
+   necessary that new general-purpose client implementations still
+   provide options for graceful fallback to the old behavior in their
+   support of concurrent DNS transactions and AXFR sessions on a single
+   TCP connection.
+
+4.1.  TCP
+
+   In the original definition, there arguably is an implicit assumption
+   (probably unintentional) that a TCP connection is used for one and
+   only one AXFR session.  This is evidenced in the lack of an explicit
+   requirement to copy the Question section and/or the message ID into
+
+
+
+Lewis & Hoenes               Standards Track                   [Page 20]
+
+RFC 5936            DNS Zone Transfer Protocol (AXFR)          June 2010
+
+
+   responses, no explicit ordering information within the AXFR response
+   messages, and the lack of an explicit notice indicating that a zone
+   transfer continues in the next message.
+
+   The guidance given below is intended to enable better performance of
+   the AXFR exchange as well as provide guidelines on interactions with
+   older software.  Better performance includes being able to multiplex
+   DNS message exchanges including zone transfer sessions.  Guidelines
+   for interacting with older software are generally applicable to new
+   AXFR clients.  In the reverse situation -- older AXFR client and
+   newer AXFR server -- the server ought to operate within the
+   specification for an older server.
+
+4.1.1.  AXFR Client TCP
+
+   An AXFR client MAY request a connection to an AXFR server for any
+   reason.  An AXFR client SHOULD close the connection when there is no
+   apparent need to use the connection for some time period.  The AXFR
+   server ought not have to maintain idle connections; the burden of
+   connection closure ought to be on the client.  "Apparent need" for
+   the connection is a judgment for the AXFR client and the DNS client.
+   If the connection is used for multiple sessions, or if it is known
+   that sessions will be coming, or if there is other query/response
+   traffic anticipated or currently on the open connection, then there
+   is "apparent need".
+
+   An AXFR client can cancel the delivery of a zone only by closing the
+   connection.  However, this action will also cancel all other
+   outstanding activity using the connection.  There is no other
+   mechanism by which an AXFR response can be cancelled.
+
+   When a TCP connection is closed remotely (relative to the client),
+   whether by the AXFR server or due to a network event, the AXFR client
+   MUST cancel all outstanding sessions and non-AXFR transactions.
+   Recovery from this situation is not straightforward.  If the
+   disruption was a spurious event, attempting to restart the connection
+   would be proper.  If the disruption was caused by a failure that
+   proved to be persistent, the AXFR client would be wise not to spend
+   too many resources trying to rebuild the connection.  Finally, if the
+   connection was dropped because of a policy at the AXFR server (as can
+   be the case with older AXFR servers), the AXFR client would be wise
+   not to retry the connection.  Unfortunately, knowing which of the
+   three cases above (momentary disruption, failure, policy) applies is
+   not possible with certainty, and can only be assessed by heuristics.
+   This exemplifies the general complications for clients in connection-
+   oriented protocols not receiving meaningful error responses.
+
+
+
+
+
+Lewis & Hoenes               Standards Track                   [Page 21]
+
+RFC 5936            DNS Zone Transfer Protocol (AXFR)          June 2010
+
+
+   An AXFR client MAY use an already opened TCP connection to start an
+   AXFR session.  Using an existing open connection is RECOMMENDED over
+   opening a new connection.  (Non-AXFR session traffic can also use an
+   open connection.)  If in doing so the AXFR client realizes that the
+   responses cannot be properly differentiated (lack of matching query
+   IDs, for example) or the connection is terminated for a remote
+   reason, then the AXFR client SHOULD NOT attempt to reuse an open
+   connection with the specific AXFR server until the AXFR server is
+   updated (which is, of course, not an event captured in the DNS
+   protocol).
+
+4.1.2.  AXFR Server TCP
+
+   An AXFR server MUST be able to handle multiple AXFR sessions on a
+   single TCP connection, as well as to handle other query/response
+   transactions over it.
+
+   If a TCP connection is closed remotely, the AXFR server MUST cancel
+   all AXFR sessions in place.  No retry activity is necessary; that is
+   initiated by the AXFR client.
+
+   Local policy MAY dictate that a TCP connection is to be closed.  Such
+   an action SHOULD be in reaction to limits such as those placed on the
+   number of outstanding open connections.  Closing a connection in
+   response to a suspected security event SHOULD be done only in extreme
+   cases, when the server is certain the action is warranted.  An
+   isolated request for a zone not on the AXFR server SHOULD receive a
+   response with the appropriate response code and not see the
+   connection broken.
+
+4.2.  UDP
+
+   With the addition of EDNS0 and applications that require many small
+   zones, such as in web hosting and some ENUM scenarios, AXFR sessions
+   on UDP would now seem desirable.  However, there are still some
+   aspects of AXFR sessions that are not easily translated to UDP.
+
+   Therefore, this document does not update RFC 1035 in this respect:
+   AXFR sessions over UDP transport are not defined.
+
+5.  Authorization
+
+   A zone administrator has the option to restrict AXFR access to a
+   zone.  This was not envisioned in the original design of the DNS but
+   has emerged as a requirement as the DNS has evolved.  Restrictions on
+   AXFR could be for various reasons including a desire (or in some
+   instances, having a legal requirement) to keep the bulk version of
+   the zone concealed or to prevent the servers from handling the load
+
+
+
+Lewis & Hoenes               Standards Track                   [Page 22]
+
+RFC 5936            DNS Zone Transfer Protocol (AXFR)          June 2010
+
+
+   incurred in serving AXFR.  It has been argued that these reasons are
+   questionable, but this document, driven by the desire to leverage the
+   interoperable practice that has evolved since RFC 1035, acknowledges
+   the factual requirement to provide mechanisms to restrict AXFR.
+
+   A DNS implementation SHOULD provide means to restrict AXFR sessions
+   to specific clients.
+
+   An implementation SHOULD allow access to be granted to Internet
+   Protocol addresses and ranges, regardless of whether a source address
+   could be spoofed.  Combining this with techniques such as Virtual
+   Private Networks (VPNs) [RFC2764] or Virtual LANs has proven to be
+   effective.
+
+   A general-purpose implementation is RECOMMENDED to implement access
+   controls based upon "Secret Key Transaction Authentication for DNS
+   (TSIG)" [RFC2845] and/or "DNS Request and Transaction Signatures
+   ( SIG(0)s )" [RFC2931].
+
+   A general-purpose implementation SHOULD allow access to be open to
+   all AXFR requests.  That is, an operator ought to be able to allow
+   any AXFR query to be granted.
+
+   A general-purpose implementation SHOULD NOT have a default policy for
+   AXFR requests to be "open to all".  For example, a default could be
+   to restrict transfers to addresses selected by the DNS
+   administrator(s) for zones on the server.
+
+6.  Zone Integrity
+
+   An AXFR client MUST ensure that only a successfully transferred copy
+   of the zone data can be used to serve this zone.  Previous
+   description and implementation practice has introduced a two-stage
+   model of the whole zone synchronization procedure:  Upon a trigger
+   event (e.g., when polling of a SOA resource record detects a change
+   in the SOA serial number, or when a DNS NOTIFY request [RFC1996] is
+   received), the AXFR session is initiated, whereby the zone data are
+   saved in a zone file or database (this latter step is necessary
+   anyway to ensure proper restart of the server); upon successful
+   completion of the AXFR operation and some sanity checks, this data
+   set is "loaded" and made available for serving the zone in an atomic
+   operation, and flagged "valid" for use during the next restart of the
+   DNS server; if any error is detected, this data set MUST be deleted,
+   and the AXFR client MUST continue to serve the previous version of
+   the zone, if it did before.  The externally visible behavior of an
+   AXFR client implementation MUST be equivalent to that of this two-
+   stage model.
+
+
+
+
+Lewis & Hoenes               Standards Track                   [Page 23]
+
+RFC 5936            DNS Zone Transfer Protocol (AXFR)          June 2010
+
+
+   If an AXFR client rejects data obtained in an AXFR session, it SHOULD
+   remember the serial number and MAY attempt to retrieve the same zone
+   version again.  The reason the same retrieval could make sense is
+   that the reason for the rejection could be rooted in an
+   implementation detail of one AXFR server used for the zone and not
+   present in another AXFR server used for the zone.
+
+   Ensuring that an AXFR client does not accept a forged copy of a zone
+   is important to the security of a zone.  If a zone operator has the
+   opportunity, protection can be afforded via dedicated links, physical
+   or virtual via a VPN among the authoritative servers.  But there are
+   instances in which zone operators have no choice but to run AXFR
+   sessions over the global public Internet.
+
+   Besides best attempts at securing TCP connections, DNS
+   implementations SHOULD provide means to make use of "Secret Key
+   Transaction Authentication for DNS (TSIG)" [RFC2845] and/or "DNS
+   Request and Transaction Signatures ( SIG(0)s )" [RFC2931] to allow
+   AXFR clients to verify the contents.  These techniques MAY also be
+   used for authorization.
+
+7.  Backwards Compatibility
+
+   Describing backwards compatibility is difficult because of the lack
+   of specifics in the original definition.  In this section, some hints
+   at building in backwards compatibility are given, mostly repeated
+   from the relevant earlier sections.
+
+   Backwards compatibility is not necessary, but the greater the extent
+   of an implementation's compatibility, the greater its
+   interoperability.  For turnkey implementations, this is not usually a
+   concern.  For general-purpose implementations, this takes on varying
+   levels of importance, depending on the implementer's desire to
+   maintain interoperability.
+
+   It is unfortunate that a need to fall back to older behavior cannot
+   be discovered, and thus has to be noted in a configuration file.  An
+   implementation SHOULD, in its documentation, encourage operators to
+   periodically review AXFR clients and servers it has made notes about
+   repeatedly, as old software gets updated from time to time.
+
+7.1.  Server
+
+   An AXFR server has the luxury of being able to react to an AXFR
+   client's abilities, with the exception of knowing whether the client
+   can accept multiple resource records per AXFR response message.  The
+   knowledge that a client is so restricted cannot be discovered; hence,
+   it has to be set by configuration.
+
+
+
+Lewis & Hoenes               Standards Track                   [Page 24]
+
+RFC 5936            DNS Zone Transfer Protocol (AXFR)          June 2010
+
+
+   An implementation of an AXFR server MAY permit configuring, on a per
+   AXFR client basis, the necessity to revert to a single resource
+   record per message; in that case, the default SHOULD be to use
+   multiple records per message.
+
+7.2.  Client
+
+   An AXFR client has the opportunity to try other features (i.e., those
+   not defined by this document) when querying an AXFR server.
+
+   Attempting to issue multiple DNS queries over a TCP transport for an
+   AXFR session SHOULD be aborted if it interrupts the original request,
+   and SHOULD take into consideration whether the AXFR server intends to
+   close the connection immediately upon completion of the original
+   (connection-causing) zone transfer.
+
+8.  Security Considerations
+
+   This document is a clarification of a mechanism outlined in RFCs 1034
+   and 1035 and as such does not add any new security considerations.
+   RFC 3833 [RFC3833] is devoted entirely to security considerations for
+   the DNS; its Section 4.3 delineates zone transfer security aspects
+   from the security threats addressed by DNSSEC.
+
+   Concerns regarding authorization, traffic flooding, and message
+   integrity are mentioned in "Authorization" (Section 5), "TCP"
+   (Section 4.1), and "Zone Integrity" (Section 6).
+
+9.  IANA Considerations
+
+   IANA has added a reference to this RFC in the AXFR (252) row of the
+   "Resource Record (RR) TYPEs" subregistry of the "Domain Name System
+   (DNS) Parameters" registry.
+
+10.  Internationalization Considerations
+
+   The AXFR protocol is transparent to the parts of DNS zone content
+   that can possibly be subject to Internationalization considerations.
+   It is assumed that for DNS labels and domain names, the issue has
+   been solved via "Internationalizing Domain Names in Applications
+   (IDNA)" [RFC3490] or its successor(s).
+
+11.  Acknowledgments
+
+   Earlier draft versions of this document have been edited by Andreas
+   Gustafsson.  In his latest draft version, this acknowledgment
+   appeared:
+
+
+
+
+Lewis & Hoenes               Standards Track                   [Page 25]
+
+RFC 5936            DNS Zone Transfer Protocol (AXFR)          June 2010
+
+
+      Many people have contributed input and commentary to earlier
+      versions of this document, including but not limited to Bob
+      Halley, Dan Bernstein, Eric A. Hall, Josh Littlefield, Kevin
+      Darcy, Robert Elz, Levon Esibov, Mark Andrews, Michael Patton,
+      Peter Koch, Sam Trenholme, and Brian Wellington.
+
+   Comments on later draft versions have come from these individuals:
+   Mark Andrews, Paul Vixie, Wouter Wijngaards, Iain Calder, Tony Finch,
+   Ian Jackson, Andreas Gustafsson, Brian Wellington, Niall O'Reilly,
+   Bill Manning, and other participants of the DNSEXT working group.
+   Significant comments from the IETF at large have been received from
+   Subramanian Moonesamy, Chris Lonvick, and Vijay K. Gurbani.
+
+   Edward Lewis served as a patiently listening sole document editor for
+   two years.
+
+12.  References
+
+   All "RFC" references below -- like all RFCs -- and information about
+   the RFC series can be obtained from the RFC Editor web site at
+   http://www.rfc-editor.org.
+
+12.1.  Normative References
+
+   [BCP14]     Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC0793]   Postel, J., "Transmission Control Protocol", STD 7, RFC
+               793, September 1981.
+
+   [RFC0768]   Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+               August 1980.
+
+   [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.
+
+   [RFC1123]   Braden, R., Ed., "Requirements for Internet Hosts -
+               Application and Support", STD 3, RFC 1123, October 1989.
+
+   [RFC1995]   Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
+               August 1996.
+
+   [RFC1996]   Vixie, P., "A Mechanism for Prompt Notification of Zone
+               Changes (DNS NOTIFY)", RFC 1996, August 1996.
+
+
+
+
+Lewis & Hoenes               Standards Track                   [Page 26]
+
+RFC 5936            DNS Zone Transfer Protocol (AXFR)          June 2010
+
+
+   [RFC2136]   Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
+               "Dynamic Updates in the Domain Name System (DNS UPDATE)",
+               RFC 2136, April 1997.
+
+   [RFC2181]   Elz, R. and R. Bush, "Clarifications to the DNS
+               Specification", RFC 2181, July 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.
+
+   [RFC2845]   Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
+               Wellington, "Secret Key Transaction Authentication for
+               DNS (TSIG)", RFC 2845, May 2000.
+
+   [RFC2930]   Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY
+               RR)", RFC 2930, September 2000.
+
+   [RFC2931]   Eastlake 3rd, D., "DNS Request and Transaction Signatures
+               ( SIG(0)s )", RFC 2931, September 2000.
+
+   [RFC3425]   Lawrence, D., "Obsoleting IQUERY", RFC 3425, November
+               2002.
+
+   [RFC3597]   Gustafsson, A., "Handling of Unknown DNS Resource Record
+               (RR) Types", RFC 3597, September 2003.
+
+   [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.
+
+   [RFC4509]   Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
+               (DS) Resource Records (RRs)", RFC 4509, May 2006.
+
+   [RFC4635]   Eastlake 3rd, D., "HMAC SHA (Hashed Message
+               Authentication Code, Secure Hash Algorithm) TSIG
+               Algorithm Identifiers", RFC 4635, August 2006.
+
+
+
+
+Lewis & Hoenes               Standards Track                   [Page 27]
+
+RFC 5936            DNS Zone Transfer Protocol (AXFR)          June 2010
+
+
+   [RFC5155]   Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
+               Security (DNSSEC) Hashed Authenticated Denial of
+               Existence", RFC 5155, March 2008.
+
+   [RFC5395]   Eastlake 3rd, D., "Domain Name System (DNS) IANA
+               Considerations", BCP 42, RFC 5395, November 2008.
+
+   [RFC5702]   Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY
+               and RRSIG Resource Records for DNSSEC", RFC 5702, October
+               2009.
+
+12.2.  Informative References
+
+   [DNSVALS]   IANA Registry "Domain Name System (DNS) Parameters",
+               http://www.iana.org/.
+
+   [IANA-AF]   IANA Registry "Address Family Numbers",
+               http://www.iana.org/.
+
+   [RFC2764]   Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A.
+               Malis, "A Framework for IP Based Virtual Private
+               Networks", RFC 2764, February 2000.
+
+   [RFC3490]   Faltstrom, P., Hoffman, P., and A. Costello,
+               "Internationalizing Domain Names in Applications (IDNA)",
+               RFC 3490, March 2003.
+
+   [RFC3833]   Atkins, D. and R. Austein, "Threat Analysis of the Domain
+               Name System (DNS)", RFC 3833, August 2004.
+
+   [DNSSEC-U]  Weiler, S. and D. Blacka, "Clarifications and
+               Implementation Notes for DNSSECbis", Work in Progress,
+               March 2010.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lewis & Hoenes               Standards Track                   [Page 28]
+
+RFC 5936            DNS Zone Transfer Protocol (AXFR)          June 2010
+
+
+Authors' Addresses
+
+   Edward Lewis
+   46000 Center Oak Plaza
+   Sterling, VA  20166
+   US
+
+   EMail: ed.lewis@neustar.biz
+
+
+   Alfred Hoenes, Editor
+   TR-Sys
+   Gerlinger Str. 12
+   Ditzingen  D-71254
+   Germany
+
+   EMail: ah@TR-Sys.de
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lewis & Hoenes               Standards Track                   [Page 29]
+
diff --git a/doc/rfc/rfc5952.txt b/doc/rfc/rfc5952.txt
new file mode 100644
index 0000000000..56a0e0c355
--- /dev/null
+++ b/doc/rfc/rfc5952.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                       S. Kawamura
+Request for Comments: 5952                             NEC BIGLOBE, Ltd.
+Updates: 4291                                               M. Kawashima
+Category: Standards Track                       NEC AccessTechnica, Ltd.
+ISSN: 2070-1721                                              August 2010
+
+
+         A Recommendation for IPv6 Address Text Representation
+
+Abstract
+
+   As IPv6 deployment increases, there will be a dramatic increase in
+   the need to use IPv6 addresses in text.  While the IPv6 address
+   architecture in Section 2.2 of RFC 4291 describes a flexible model
+   for text representation of an IPv6 address, this flexibility has been
+   causing problems for operators, system engineers, and users.  This
+   document defines a canonical textual representation format.  It does
+   not define a format for internal storage, such as within an
+   application or database.  It is expected that the canonical format
+   will be followed by humans and systems when representing IPv6
+   addresses as text, but all implementations must accept and be able to
+   handle any legitimate RFC 4291 format.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc5952.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kawamura & Kawashima         Standards Track                    [Page 1]
+
+RFC 5952                IPv6 Text Representation             August 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
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kawamura & Kawashima         Standards Track                    [Page 2]
+
+RFC 5952                IPv6 Text Representation             August 2010
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
+     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  4
+   2.  Text Representation Flexibility of RFC 4291  . . . . . . . . .  4
+     2.1.  Leading Zeros in a 16-Bit Field  . . . . . . . . . . . . .  4
+     2.2.  Zero Compression . . . . . . . . . . . . . . . . . . . . .  5
+     2.3.  Uppercase or Lowercase . . . . . . . . . . . . . . . . . .  6
+   3.  Problems Encountered with the Flexible Model . . . . . . . . .  6
+     3.1.  Searching  . . . . . . . . . . . . . . . . . . . . . . . .  6
+       3.1.1.  General Summary  . . . . . . . . . . . . . . . . . . .  6
+       3.1.2.  Searching Spreadsheets and Text Files  . . . . . . . .  6
+       3.1.3.  Searching with Whois . . . . . . . . . . . . . . . . .  6
+       3.1.4.  Searching for an Address in a Network Diagram  . . . .  7
+     3.2.  Parsing and Modifying  . . . . . . . . . . . . . . . . . .  7
+       3.2.1.  General Summary  . . . . . . . . . . . . . . . . . . .  7
+       3.2.2.  Logging  . . . . . . . . . . . . . . . . . . . . . . .  7
+       3.2.3.  Auditing: Case 1 . . . . . . . . . . . . . . . . . . .  8
+       3.2.4.  Auditing: Case 2 . . . . . . . . . . . . . . . . . . .  8
+       3.2.5.  Verification . . . . . . . . . . . . . . . . . . . . .  8
+       3.2.6.  Unexpected Modifying . . . . . . . . . . . . . . . . .  8
+     3.3.  Operating  . . . . . . . . . . . . . . . . . . . . . . . .  8
+       3.3.1.  General Summary  . . . . . . . . . . . . . . . . . . .  8
+       3.3.2.  Customer Calls . . . . . . . . . . . . . . . . . . . .  9
+       3.3.3.  Abuse  . . . . . . . . . . . . . . . . . . . . . . . .  9
+     3.4.  Other Minor Problems . . . . . . . . . . . . . . . . . . .  9
+       3.4.1.  Changing Platforms . . . . . . . . . . . . . . . . . .  9
+       3.4.2.  Preference in Documentation  . . . . . . . . . . . . .  9
+       3.4.3.  Legibility . . . . . . . . . . . . . . . . . . . . . .  9
+   4.  A Recommendation for IPv6 Text Representation  . . . . . . . . 10
+     4.1.  Handling Leading Zeros in a 16-Bit Field . . . . . . . . . 10
+     4.2.  "::" Usage . . . . . . . . . . . . . . . . . . . . . . . . 10
+       4.2.1.  Shorten as Much as Possible  . . . . . . . . . . . . . 10
+       4.2.2.  Handling One 16-Bit 0 Field  . . . . . . . . . . . . . 10
+       4.2.3.  Choice in Placement of "::"  . . . . . . . . . . . . . 10
+     4.3.  Lowercase  . . . . . . . . . . . . . . . . . . . . . . . . 10
+   5.  Text Representation of Special Addresses . . . . . . . . . . . 11
+   6.  Notes on Combining IPv6 Addresses with Port Numbers  . . . . . 11
+   7.  Prefix Representation  . . . . . . . . . . . . . . . . . . . . 12
+   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
+   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
+   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
+     10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
+     10.2. Informative References . . . . . . . . . . . . . . . . . . 13
+   Appendix A.  For Developers  . . . . . . . . . . . . . . . . . . . 14
+
+
+
+
+
+
+Kawamura & Kawashima         Standards Track                    [Page 3]
+
+RFC 5952                IPv6 Text Representation             August 2010
+
+
+1.  Introduction
+
+   A single IPv6 address can be text represented in many ways.  Examples
+   are shown below.
+
+      2001:db8:0:0:1:0:0:1
+
+      2001:0db8:0:0:1:0:0:1
+
+      2001:db8::1:0:0:1
+
+      2001:db8::0:1:0:0:1
+
+      2001:0db8::1:0:0:1
+
+      2001:db8:0:0:1::1
+
+      2001:db8:0000:0:1::1
+
+      2001:DB8:0:0:1::1
+
+   All of the above examples represent the same IPv6 address.  This
+   flexibility has caused many problems for operators, systems
+   engineers, and customers.  The problems are noted in Section 3.  A
+   canonical representation format to avoid problems is introduced in
+   Section 4.
+
+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.  Text Representation Flexibility of RFC 4291
+
+   Examples of flexibility in Section 2.2 of [RFC4291] are described
+   below.
+
+2.1.  Leading Zeros in a 16-Bit Field
+
+      'It is not necessary to write the leading zeros in an individual
+      field.'
+
+   Conversely, it is also not necessary to omit leading zeros.  This
+   means that it is possible to select from representations such as
+   those in the following example.  The final 16-bit field is different,
+   but all of these addresses represent the same address.
+
+
+
+
+Kawamura & Kawashima         Standards Track                    [Page 4]
+
+RFC 5952                IPv6 Text Representation             August 2010
+
+
+      2001:db8:aaaa:bbbb:cccc:dddd:eeee:0001
+
+      2001:db8:aaaa:bbbb:cccc:dddd:eeee:001
+
+      2001:db8:aaaa:bbbb:cccc:dddd:eeee:01
+
+      2001:db8:aaaa:bbbb:cccc:dddd:eeee:1
+
+2.2.  Zero Compression
+
+      'A special syntax is available to compress the zeros.  The use of
+      "::" indicates one or more groups of 16 bits of zeros.'
+
+   It is possible to select whether or not to omit just one 16-bit 0
+   field.
+
+      2001:db8:aaaa:bbbb:cccc:dddd::1
+
+      2001:db8:aaaa:bbbb:cccc:dddd:0:1
+
+   In cases where there is more than one field of only zeros, there is a
+   choice of how many fields can be shortened.
+
+      2001:db8:0:0:0::1
+
+      2001:db8:0:0::1
+
+      2001:db8:0::1
+
+      2001:db8::1
+
+   In addition, Section 2.2 of [RFC4291] notes,
+
+      'The "::" can only appear once in an address.'
+
+   This gives a choice on where in a single address to compress the
+   zero.
+
+      2001:db8::aaaa:0:0:1
+
+      2001:db8:0:0:aaaa::1
+
+
+
+
+
+
+
+
+
+
+Kawamura & Kawashima         Standards Track                    [Page 5]
+
+RFC 5952                IPv6 Text Representation             August 2010
+
+
+2.3.  Uppercase or Lowercase
+
+   [RFC4291] does not mention any preference of uppercase or lowercase.
+
+      2001:db8:aaaa:bbbb:cccc:dddd:eeee:aaaa
+
+      2001:db8:aaaa:bbbb:cccc:dddd:eeee:AAAA
+
+      2001:db8:aaaa:bbbb:cccc:dddd:eeee:AaAa
+
+3.  Problems Encountered with the Flexible Model
+
+3.1.  Searching
+
+3.1.1.  General Summary
+
+   A search of an IPv6 address if conducted through a UNIX system is
+   usually case sensitive and extended options that allow for regular
+   expression use will come in handy.  However, there are many
+   applications in the Internet today that do not provide this
+   capability.  When searching for an IPv6 address in such systems, the
+   system engineer will have to try each and every possibility to search
+   for an address.  This has critical impacts, especially when trying to
+   deploy IPv6 over an enterprise network.
+
+3.1.2.  Searching Spreadsheets and Text Files
+
+   Spreadsheet applications and text editors on GUI systems rarely have
+   the ability to search for text using regular expression.  Moreover,
+   there are many non-engineers (who are not aware of case sensitivity
+   and regular expression use) that use these applications to manage IP
+   addresses.  This has worked quite well with IPv4 since text
+   representation in IPv4 has very little flexibility.  There is no
+   incentive to encourage these non-engineers to change their tool or
+   learn regular expression when they decide to go dual-stack.  If the
+   entry in the spreadsheet reads, 2001:db8::1:0:0:1, but the search was
+   conducted as 2001:db8:0:0:1::1, this will show a result of no match.
+   One example where this will cause a problem is, when the search is
+   being conducted to assign a new address from a pool, and a check is
+   being done to see if it is not in use.  This may cause problems for
+   the end-hosts or end-users.  This type of address management is very
+   often seen in enterprise networks and ISPs.
+
+3.1.3.  Searching with Whois
+
+   The "whois" utility is used by a wide range of people today.  When a
+   record is set to a database, one will likely check the output to see
+   if the entry is correct.  If an entity was recorded as 2001:db8::/48,
+
+
+
+Kawamura & Kawashima         Standards Track                    [Page 6]
+
+RFC 5952                IPv6 Text Representation             August 2010
+
+
+   but the whois output showed 2001:0db8:0000::/48, most non-engineers
+   would think that their input was wrong and will likely retry several
+   times or make a frustrated call to the database hostmaster.  If there
+   was a need to register the same prefix on different systems, and each
+   system showed a different text representation, this would confuse
+   people even more.  Although this document focuses on addresses rather
+   than prefixes, it is worth mentioning the prefix problems because the
+   problems encountered with addresses and prefixes are mostly equal.
+
+3.1.4.  Searching for an Address in a Network Diagram
+
+   Network diagrams and blueprints often show what IP addresses are
+   assigned to a system devices.  In times of trouble shooting there may
+   be a need to search through a diagram to find the point of failure
+   (for example, if a traceroute stopped at 2001:db8::1, one would
+   search the diagram for that address).  This is a technique quite
+   often in use in enterprise networks and managed services.  Again, the
+   different flavors of text representation will result in a time-
+   consuming search leading to longer mean times to restoration (MTTR)
+   in times of trouble.
+
+3.2.  Parsing and Modifying
+
+3.2.1.  General Summary
+
+   With all the possible methods of text representation, each
+   application must include a module, object, link, etc. to a function
+   that will parse IPv6 addresses in a manner such that no matter how it
+   is represented, they will mean the same address.  Many system
+   engineers who integrate complex computer systems for corporate
+   customers will have difficulties finding that their favorite tool
+   will not have this function, or will encounter difficulties such as
+   having to rewrite their macros or scripts for their customers.
+
+3.2.2.  Logging
+
+   If an application were to output a log summary that represented the
+   address in full (such as 2001:0db8:0000:0000:1111:2222:3333:4444),
+   the output would be highly unreadable compared to the IPv4 output.
+   The address would have to be parsed and reformed to make it useful
+   for human reading.  Sometimes logging for critical systems is done by
+   mirroring the same traffic to two different systems.  Care must be
+   taken so that no matter what the log output is, the logs should be
+   parsed so they are equivalent.
+
+
+
+
+
+
+
+Kawamura & Kawashima         Standards Track                    [Page 7]
+
+RFC 5952                IPv6 Text Representation             August 2010
+
+
+3.2.3.  Auditing: Case 1
+
+   When a router or any other network appliance machine configuration is
+   audited, there are many methods to compare the configuration
+   information of a node.  Sometimes auditing will be done by just
+   comparing the changes made each day.  In this case, if configuration
+   was done such that 2001:db8::1 was changed to 2001:0db8:0000:0000:
+   0000:0000:0000:0001 just because the new engineer on the block felt
+   it was better, a simple diff will show that a different address was
+   configured.  If this was done on a wide scale network, people will be
+   focusing on 'why the extra zeros were put in' instead of doing any
+   real auditing.  Lots of tools are just plain diffs that do not take
+   into account address representation rules.
+
+3.2.4.  Auditing: Case 2
+
+   Node configurations will be matched against an information system
+   that manages IP addresses.  If output notation is different, there
+   will need to be a script that is implemented to cover for this.  The
+   result of an SNMP GET operation, converted to text and compared to a
+   textual address written by a human is highly unlikely to match on the
+   first try.
+
+3.2.5.  Verification
+
+   Some protocols require certain data fields to be verified.  One
+   example of this is X.509 certificates.  If an IPv6 address field in a
+   certificate was incorrectly verified by converting it to text and
+   making a simple textual comparison to some other address, the
+   certificate may be mistakenly shown as being invalid due to a
+   difference in text representation methods.
+
+3.2.6.  Unexpected Modifying
+
+   Sometimes, a system will take an address and modify it as a
+   convenience.  For example, a system may take an input of
+   2001:0db8:0::1 and make the output 2001:db8::1.  If the zeros were
+   input for a reason, the outcome may be somewhat unexpected.
+
+3.3.  Operating
+
+3.3.1.  General Summary
+
+   When an operator sets an IPv6 address of a system as 2001:db8:0:0:1:
+   0:0:1, the system may take the address and show the configuration
+   result as 2001:DB8::1:0:0:1.  Someone familiar with IPv6 address
+   representation will know that the right address is set, but not
+   everyone may understand this.
+
+
+
+Kawamura & Kawashima         Standards Track                    [Page 8]
+
+RFC 5952                IPv6 Text Representation             August 2010
+
+
+3.3.2.  Customer Calls
+
+   When a customer calls to inquire about a suspected outage, IPv6
+   address representation should be handled with care.  Not all
+   customers are engineers, nor do they have a similar skill level in
+   IPv6 technology.  The network operations center will have to take
+   extra steps to humanly parse the address to avoid having to explain
+   to the customers that 2001:db8:0:1::1 is the same as
+   2001:db8::1:0:0:0:1.  This is one thing that will never happen in
+   IPv4 because IPv4 addresses cannot be abbreviated.
+
+3.3.3.  Abuse
+
+   Network abuse reports generally include the abusing IP address.  This
+   'reporting' could take any shape or form of the flexible model.  A
+   team that handles network abuse must be able to tell the difference
+   between a 2001:db8::1:0:1 and 2001:db8:1::0:1.  Mistakes in the
+   placement of the "::" will result in a critical situation.  A system
+   that handles these incidents should be able to handle any type of
+   input and parse it in a correct manner.  Also, incidents are reported
+   over the phone.  It is unnecessary to report if the letter is
+   uppercase or lowercase.  However, when a letter is spelled uppercase,
+   people tend to specify that it is uppercase, which is unnecessary
+   information.
+
+3.4.  Other Minor Problems
+
+3.4.1.  Changing Platforms
+
+   When an engineer decides to change the platform of a running service,
+   the same code may not work as expected due to the difference in IPv6
+   address text representation.  Usually, a change in a platform (e.g.,
+   Unix to Windows, Cisco to Juniper) will result in a major change of
+   code anyway, but flexibility in address representation will increase
+   the work load.
+
+3.4.2.  Preference in Documentation
+
+   A document that is edited by more than one author may become harder
+   to read.
+
+3.4.3.  Legibility
+
+   Capital case D and 0 can be quite often misread.  Capital B and 8 can
+   also be misread.
+
+
+
+
+
+
+Kawamura & Kawashima         Standards Track                    [Page 9]
+
+RFC 5952                IPv6 Text Representation             August 2010
+
+
+4.  A Recommendation for IPv6 Text Representation
+
+   A recommendation for a canonical text representation format of IPv6
+   addresses is presented in this section.  The recommendation in this
+   document is one that complies fully with [RFC4291], is implemented by
+   various operating systems, and is human friendly.  The recommendation
+   in this section SHOULD be followed by systems when generating an
+   address to be represented as text, but all implementations MUST
+   accept and be able to handle any legitimate [RFC4291] format.  It is
+   advised that humans also follow these recommendations when spelling
+   an address.
+
+4.1.  Handling Leading Zeros in a 16-Bit Field
+
+   Leading zeros MUST be suppressed.  For example, 2001:0db8::0001 is
+   not acceptable and must be represented as 2001:db8::1.  A single 16-
+   bit 0000 field MUST be represented as 0.
+
+4.2.  "::" Usage
+
+4.2.1.  Shorten as Much as Possible
+
+   The use of the symbol "::" MUST be used to its maximum capability.
+   For example, 2001:db8:0:0:0:0:2:1 must be shortened to 2001:db8::2:1.
+   Likewise, 2001:db8::0:1 is not acceptable, because the symbol "::"
+   could have been used to produce a shorter representation 2001:db8::1.
+
+4.2.2.  Handling One 16-Bit 0 Field
+
+   The symbol "::" MUST NOT be used to shorten just one 16-bit 0 field.
+   For example, the representation 2001:db8:0:1:1:1:1:1 is correct, but
+   2001:db8::1:1:1:1:1 is not correct.
+
+4.2.3.  Choice in Placement of "::"
+
+   When there is an alternative choice in the placement of a "::", the
+   longest run of consecutive 16-bit 0 fields MUST be shortened (i.e.,
+   the sequence with three consecutive zero fields is shortened in 2001:
+   0:0:1:0:0:0:1).  When the length of the consecutive 16-bit 0 fields
+   are equal (i.e., 2001:db8:0:0:1:0:0:1), the first sequence of zero
+   bits MUST be shortened.  For example, 2001:db8::1:0:0:1 is correct
+   representation.
+
+4.3.  Lowercase
+
+   The characters "a", "b", "c", "d", "e", and "f" in an IPv6 address
+   MUST be represented in lowercase.
+
+
+
+
+Kawamura & Kawashima         Standards Track                   [Page 10]
+
+RFC 5952                IPv6 Text Representation             August 2010
+
+
+5.  Text Representation of Special Addresses
+
+   Addresses such as IPv4-Mapped IPv6 addresses, ISATAP [RFC5214], and
+   IPv4-translatable addresses [ADDR-FORMAT] have IPv4 addresses
+   embedded in the low-order 32 bits of the address.  These addresses
+   have a special representation that may mix hexadecimal and dot
+   decimal notations.  The decimal notation may be used only for the
+   last 32 bits of the address.  For these addresses, mixed notation is
+   RECOMMENDED if the following condition is met: the address can be
+   distinguished as having IPv4 addresses embedded in the lower 32 bits
+   solely from the address field through the use of a well-known prefix.
+   Such prefixes are defined in [RFC4291] and [RFC2765] at the time of
+   this writing.  If it is known by some external method that a given
+   prefix is used to embed IPv4, it MAY be represented as mixed
+   notation.  Tools that provide options to specify prefixes that are
+   (or are not) to be represented as mixed notation may be useful.
+
+   There is a trade-off here where a recommendation to achieve an exact
+   match in a search (no dot decimals whatsoever) and a recommendation
+   to help the readability of an address (dot decimal whenever possible)
+   does not result in the same solution.  The above recommendation is
+   aimed at fixing the representation as much as possible while leaving
+   the opportunity for future well-known prefixes to be represented in a
+   human-friendly manner as tools adjust to newly assigned prefixes.
+
+   The text representation method noted in Section 4 should be applied
+   for the leading hexadecimal part (i.e., ::ffff:192.0.2.1 instead of
+   0:0:0:0:0:ffff:192.0.2.1).
+
+6.  Notes on Combining IPv6 Addresses with Port Numbers
+
+   There are many different ways to combine IPv6 addresses and port
+   numbers that are represented in text.  Examples are shown below.
+
+   o  [2001:db8::1]:80
+
+   o  2001:db8::1:80
+
+   o  2001:db8::1.80
+
+   o  2001:db8::1 port 80
+
+   o  2001:db8::1p80
+
+   o  2001:db8::1#80
+
+   The situation is not much different in IPv4, but the most ambiguous
+   case with IPv6 is the second bullet.  This is due to the "::"usage in
+
+
+
+Kawamura & Kawashima         Standards Track                   [Page 11]
+
+RFC 5952                IPv6 Text Representation             August 2010
+
+
+   IPv6 addresses.  This style is NOT RECOMMENDED because of its
+   ambiguity.  The [] style as expressed in [RFC3986] SHOULD be
+   employed, and is the default unless otherwise specified.  Other
+   styles are acceptable when there is exactly one style for the given
+   context and cross-platform portability does not become an issue.  For
+   URIs containing IPv6 address literals, [RFC3986] MUST be followed, as
+   well as the rules defined in this document.
+
+7.  Prefix Representation
+
+   Problems with prefixes are the same as problems encountered with
+   addresses.  The text representation method of IPv6 prefixes should be
+   no different from that of IPv6 addresses.
+
+8.  Security Considerations
+
+   This document notes some examples where IPv6 addresses are compared
+   in text format.  The example on Section 3.2.5 is one that may cause a
+   security risk if used for access control.  The common practice of
+   comparing X.509 data is done in binary format.
+
+9.  Acknowledgements
+
+   The authors would like to thank Jan Zorz, Randy Bush, Yuichi Minami,
+   and Toshimitsu Matsuura for their generous and helpful comments in
+   kick starting this document.  We also would like to thank Brian
+   Carpenter, Akira Kato, Juergen Schoenwaelder, Antonio Querubin, Dave
+   Thaler, Brian Haley, Suresh Krishnan, Jerry Huang, Roman Donchenko,
+   Heikki Vatiainen, Dan Wing, and Doug Barton for their input.  Also, a
+   very special thanks to Ron Bonica, Fred Baker, Brian Haberman, Robert
+   Hinden, Jari Arkko, and Kurt Lindqvist for their support in bringing
+   this document to light in IETF working groups.
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
+                  Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2765]      Nordmark, E., "Stateless IP/ICMP Translation Algorithm
+                  (SIIT)", RFC 2765, February 2000.
+
+   [RFC3986]      Berners-Lee, T., Fielding, R., and L. Masinter,
+                  "Uniform Resource Identifier (URI): Generic Syntax",
+                  STD 66, RFC 3986, January 2005.
+
+
+
+
+
+Kawamura & Kawashima         Standards Track                   [Page 12]
+
+RFC 5952                IPv6 Text Representation             August 2010
+
+
+   [RFC4291]      Hinden, R. and S. Deering, "IP Version 6 Addressing
+                  Architecture", RFC 4291, February 2006.
+
+10.2.  Informative References
+
+   [ADDR-FORMAT]  Bao, C., "IPv6 Addressing of IPv4/IPv6 Translators",
+                  Work in Progress, July 2010.
+
+   [RFC4038]      Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E.
+                  Castro, "Application Aspects of IPv6 Transition",
+                  RFC 4038, March 2005.
+
+   [RFC5214]      Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
+                  Automatic Tunnel Addressing Protocol (ISATAP)",
+                  RFC 5214, March 2008.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kawamura & Kawashima         Standards Track                   [Page 13]
+
+RFC 5952                IPv6 Text Representation             August 2010
+
+
+Appendix A.  For Developers
+
+   We recommend that developers use display routines that conform to
+   these rules.  For example, the usage of getnameinfo() with flags
+   argument NI_NUMERICHOST in FreeBSD 7.0 will give a conforming output,
+   except for the special addresses notes in Section 5.  The function
+   inet_ntop() of FreeBSD7.0 is a good C code reference, but should not
+   be called directly.  See [RFC4038] for details.
+
+Authors' Addresses
+
+   Seiichi Kawamura
+   NEC BIGLOBE, Ltd.
+   14-22, Shibaura 4-chome
+   Minatoku, Tokyo  108-8558
+   JAPAN
+
+   Phone: +81 3 3798 6085
+   EMail: kawamucho@mesh.ad.jp
+
+
+   Masanobu Kawashima
+   NEC AccessTechnica, Ltd.
+   800, Shimomata
+   Kakegawa-shi, Shizuoka  436-8501
+   JAPAN
+
+   Phone: +81 537 23 9655
+   EMail: kawashimam@necat.nec.co.jp
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kawamura & Kawashima         Standards Track                   [Page 14]
+
diff --git a/doc/rfc/rfc5966.txt b/doc/rfc/rfc5966.txt
new file mode 100644
index 0000000000..470796f823
--- /dev/null
+++ b/doc/rfc/rfc5966.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                         R. Bellis
+Request for Comments: 5966                                    Nominet UK
+Updates: 1035, 1123                                          August 2010
+Category: Standards Track
+ISSN: 2070-1721
+
+
+          DNS Transport over TCP - Implementation Requirements
+
+Abstract
+
+   This document updates the requirements for the support of TCP as a
+   transport protocol for DNS implementations.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc5966.
+
+Copyright Notice
+
+   Copyright (c) 2010 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+
+Bellis                       Standards Track                    [Page 1]
+
+RFC 5966                      DNS over TCP                   August 2010
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
+   2.  Terminology Used in This Document . . . . . . . . . . . . . . . 3
+   3.  Discussion  . . . . . . . . . . . . . . . . . . . . . . . . . . 3
+   4.  Transport Protocol Selection  . . . . . . . . . . . . . . . . . 4
+   5.  Connection Handling . . . . . . . . . . . . . . . . . . . . . . 5
+   6.  Response Reordering . . . . . . . . . . . . . . . . . . . . . . 6
+   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
+   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
+   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
+     9.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
+     9.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
+
+1.  Introduction
+
+   Most DNS [RFC1034] transactions take place over UDP [RFC0768].  TCP
+   [RFC0793] is always used for zone transfers and is often used for
+   messages whose sizes exceed the DNS protocol's original 512-byte
+   limit.
+
+   Section 6.1.3.2 of [RFC1123] states:
+
+      DNS resolvers and recursive servers MUST support UDP, and SHOULD
+      support TCP, for sending (non-zone-transfer) queries.
+
+   However, some implementors have taken the text quoted above to mean
+   that TCP support is an optional feature of the DNS protocol.
+
+   The majority of DNS server operators already support TCP and the
+   default configuration for most software implementations is to support
+   TCP.  The primary audience for this document is those implementors
+   whose failure to support TCP restricts interoperability and limits
+   deployment of new DNS features.
+
+   This document therefore updates the core DNS protocol specifications
+   such that support for TCP is henceforth a REQUIRED part of a full DNS
+   protocol implementation.
+
+   Whilst this document makes no specific recommendations to operators
+   of DNS servers, it should be noted that failure to support TCP (or
+   the blocking of DNS over TCP at the network layer) may result in
+   resolution failure and/or application-level timeouts.
+
+
+
+
+
+
+
+
+Bellis                       Standards Track                    [Page 2]
+
+RFC 5966                      DNS over TCP                   August 2010
+
+
+2.  Terminology Used 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].
+
+3.  Discussion
+
+   In the absence of EDNS0 (Extension Mechanisms for DNS 0) (see below),
+   the normal behaviour of any DNS server needing to send a UDP response
+   that would exceed the 512-byte limit is for the server to truncate
+   the response so that it fits within that limit and then set the TC
+   flag in the response header.  When the client receives such a
+   response, it takes the TC flag as an indication that it should retry
+   over TCP instead.
+
+   RFC 1123 also says:
+
+      ... it is also clear that some new DNS record types defined in the
+      future will contain information exceeding the 512 byte limit that
+      applies to UDP, and hence will require TCP.  Thus, resolvers and
+      name servers should implement TCP services as a backup to UDP
+      today, with the knowledge that they will require the TCP service
+      in the future.
+
+   Existing deployments of DNS Security (DNSSEC) [RFC4033] have shown
+   that truncation at the 512-byte boundary is now commonplace.  For
+   example, a Non-Existent Domain (NXDOMAIN) (RCODE == 3) response from
+   a DNSSEC-signed zone using NextSECure 3 (NSEC3) [RFC5155] is almost
+   invariably larger than 512 bytes.
+
+   Since the original core specifications for DNS were written, the
+   Extension Mechanisms for DNS (EDNS0 [RFC2671]) have been introduced.
+   These extensions can be used to indicate that the client is prepared
+   to receive UDP responses larger than 512 bytes.  An EDNS0-compatible
+   server receiving a request from an EDNS0-compatible client may send
+   UDP packets up to that client's announced buffer size without
+   truncation.
+
+   However, transport of UDP packets that exceed the size of the path
+   MTU causes IP packet fragmentation, which has been found to be
+   unreliable in some circumstances.  Many firewalls routinely block
+   fragmented IP packets, and some do not implement the algorithms
+   necessary to reassemble fragmented packets.  Worse still, some
+   network devices deliberately refuse to handle DNS packets containing
+   EDNS0 options.  Other issues relating to UDP transport and packet
+   size are discussed in [RFC5625].
+
+
+
+
+Bellis                       Standards Track                    [Page 3]
+
+RFC 5966                      DNS over TCP                   August 2010
+
+
+   The MTU most commonly found in the core of the Internet is around
+   1500 bytes, and even that limit is routinely exceeded by DNSSEC-
+   signed responses.
+
+   The future that was anticipated in RFC 1123 has arrived, and the only
+   standardised UDP-based mechanism that may have resolved the packet
+   size issue has been found inadequate.
+
+4.  Transport Protocol Selection
+
+   All general-purpose DNS implementations MUST support both UDP and TCP
+   transport.
+
+   o  Authoritative server implementations MUST support TCP so that they
+      do not limit the size of responses to what fits in a single UDP
+      packet.
+
+   o  Recursive server (or forwarder) implementations MUST support TCP
+      so that they do not prevent large responses from a TCP-capable
+      server from reaching its TCP-capable clients.
+
+   o  Stub resolver implementations (e.g., an operating system's DNS
+      resolution library) MUST support TCP since to do otherwise would
+      limit their interoperability with their own clients and with
+      upstream servers.
+
+   Stub resolver implementations MAY omit support for TCP when
+   specifically designed for deployment in restricted environments where
+   truncation can never occur or where truncated DNS responses are
+   acceptable.
+
+   Regarding the choice of when to use UDP or TCP, Section 6.1.3.2 of
+   RFC 1123 also says:
+
+      ... a DNS resolver or server that is sending a non-zone-transfer
+      query MUST send a UDP query first.
+
+   That requirement is hereby relaxed.  A resolver SHOULD send a UDP
+   query first, but MAY elect to send a TCP query instead if it has good
+   reason to expect the response would be truncated if it were sent over
+   UDP (with or without EDNS0) or for other operational reasons, in
+   particular, if it already has an open TCP connection to the server.
+
+
+
+
+
+
+
+
+
+Bellis                       Standards Track                    [Page 4]
+
+RFC 5966                      DNS over TCP                   August 2010
+
+
+5.  Connection Handling
+
+   Section 4.2.2 of [RFC1035] says:
+
+      If the server needs to close a dormant connection to reclaim
+      resources, it should wait until the connection has been idle for a
+      period on the order of two minutes.  In particular, the server
+      should allow the SOA and AXFR request sequence (which begins a
+      refresh operation) to be made on a single connection.  Since the
+      server would be unable to answer queries anyway, a unilateral
+      close or reset may be used instead of a graceful close.
+
+   Other more modern protocols (e.g., HTTP [RFC2616]) have support for
+   persistent TCP connections and operational experience has shown that
+   long timeouts can easily cause resource exhaustion and poor response
+   under heavy load.  Intentionally opening many connections and leaving
+   them dormant can trivially create a "denial-of-service" attack.
+
+   It is therefore RECOMMENDED that the default application-level idle
+   period should be of the order of seconds, but no particular value is
+   specified.  In practise, the idle period may vary dynamically, and
+   servers MAY allow dormant connections to remain open for longer
+   periods as resources permit.
+
+   To mitigate the risk of unintentional server overload, DNS clients
+   MUST take care to minimize the number of concurrent TCP connections
+   made to any individual server.  Similarly, servers MAY impose limits
+   on the number of concurrent TCP connections being handled for any
+   particular client.
+
+   Further recommendations for the tuning of TCP stacks to allow higher
+   throughput or improved resiliency against denial-of-service attacks
+   are outside the scope of this document.
+
+6.  Response Reordering
+
+   RFC 1035 is ambiguous on the question of whether TCP queries may be
+   reordered -- the only relevant text is in Section 4.2.1, which
+   relates to UDP:
+
+      Queries or their responses may be reordered by the network, or by
+      processing in name servers, so resolvers should not depend on them
+      being returned in order.
+
+   For the avoidance of future doubt, this requirement is clarified.
+   Client resolvers MUST be able to process responses that arrive in a
+   different order to that in which the requests were sent, regardless
+   of the transport protocol in use.
+
+
+
+Bellis                       Standards Track                    [Page 5]
+
+RFC 5966                      DNS over TCP                   August 2010
+
+
+7.  Security Considerations
+
+   Some DNS server operators have expressed concern that wider use of
+   DNS over TCP will expose them to a higher risk of denial-of-service
+   (DoS) attacks.
+
+   Although there is a higher risk of such attacks against TCP-enabled
+   servers, techniques for the mitigation of DoS attacks at the network
+   level have improved substantially since DNS was first designed.
+
+   At the time of writing, the vast majority of Top Level Domain (TLD)
+   authority servers and all of the root name servers support TCP and
+   the author knows of no evidence to suggest that TCP-based DoS attacks
+   against existing DNS infrastructure are commonplace.
+
+   That notwithstanding, readers are advised to familiarise themselves
+   with [CPNI-TCP].
+
+   Operators of recursive servers should ensure that they only accept
+   connections from expected clients, and do not accept them from
+   unknown sources.  In the case of UDP traffic, this will help protect
+   against reflector attacks [RFC5358] and in the case of TCP traffic it
+   will prevent an unknown client from exhausting the server's limits on
+   the number of concurrent connections.
+
+8.  Acknowledgements
+
+   The author would like to thank the document reviewers from the DNSEXT
+   Working Group, and in particular, George Barwood, Alex Bligh, Alfred
+   Hoenes, Fernando Gont, Olafur Gudmondsson, Jim Reid, Paul Vixie, and
+   Nicholas Weaver.
+
+9.  References
+
+9.1.  Normative References
+
+   [RFC0768]   Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+               August 1980.
+
+   [RFC0793]   Postel, J., "Transmission Control Protocol", STD 7,
+               RFC 793, September 1981.
+
+   [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.
+
+
+
+
+Bellis                       Standards Track                    [Page 6]
+
+RFC 5966                      DNS over TCP                   August 2010
+
+
+   [RFC1123]   Braden, R., "Requirements for Internet Hosts -
+               Application and Support", STD 3, RFC 1123, October 1989.
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2671]   Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
+               RFC 2671, August 1999.
+
+9.2.  Informative References
+
+   [CPNI-TCP]  CPNI, "Security Assessment of the Transmission Control
+               Protocol (TCP)", 2009, <http://www.cpni.gov.uk/Docs/
+               tn-03-09-security-assessment-TCP.pdf>.
+
+   [RFC2616]   Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
+               Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
+               Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
+
+   [RFC4033]   Arends, R., Austein, R., Larson, M., Massey, D., and S.
+               Rose, "DNS Security Introduction and Requirements",
+               RFC 4033, March 2005.
+
+   [RFC5155]   Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
+               Security (DNSSEC) Hashed Authenticated Denial of
+               Existence", RFC 5155, March 2008.
+
+   [RFC5358]   Damas, J. and F. Neves, "Preventing Use of Recursive
+               Nameservers in Reflector Attacks", BCP 140, RFC 5358,
+               October 2008.
+
+   [RFC5625]   Bellis, R., "DNS Proxy Implementation Guidelines",
+               BCP 152, RFC 5625, August 2009.
+
+Author's Address
+
+   Ray Bellis
+   Nominet UK
+   Edmund Halley Road
+   Oxford  OX4 4DQ
+   United Kingdom
+
+   Phone: +44 1865 332211
+   EMail: ray.bellis@nominet.org.uk
+   URI:   http://www.nominet.org.uk/
+
+
+
+
+
+
+Bellis                       Standards Track                    [Page 7]
+
diff --git a/doc/rfc/rfc6052.txt b/doc/rfc/rfc6052.txt
new file mode 100644
index 0000000000..5b4389858e
--- /dev/null
+++ b/doc/rfc/rfc6052.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                            C. Bao
+Request for Comments: 6052             CERNET Center/Tsinghua University
+Updates: 4291                                                 C. Huitema
+Category: Standards Track                          Microsoft Corporation
+ISSN: 2070-1721                                               M. Bagnulo
+                                                                    UC3M
+                                                            M. Boucadair
+                                                          France Telecom
+                                                                   X. Li
+                                       CERNET Center/Tsinghua University
+                                                            October 2010
+
+
+                IPv6 Addressing of IPv4/IPv6 Translators
+
+Abstract
+
+   This document discusses the algorithmic translation of an IPv6
+   address to a corresponding IPv4 address, and vice versa, using only
+   statically configured information.  It defines a well-known prefix
+   for use in algorithmic translations, while allowing organizations to
+   also use network-specific prefixes when appropriate.  Algorithmic
+   translation is used in IPv4/IPv6 translators, as well as other types
+   of proxies and gateways (e.g., for DNS) used in IPv4/IPv6 scenarios.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6052.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bao, et al.                  Standards Track                    [Page 1]
+
+RFC 6052        IPv6 Addressing of IPv4/IPv6 Translators    October 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
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+     1.1.  Applicability Scope  . . . . . . . . . . . . . . . . . . .  3
+     1.2.  Conventions  . . . . . . . . . . . . . . . . . . . . . . .  4
+     1.3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
+   2.  IPv4-Embedded IPv6 Address Prefix and Format . . . . . . . . .  5
+     2.1.  Well-Known Prefix  . . . . . . . . . . . . . . . . . . . .  5
+     2.2.  IPv4-Embedded IPv6 Address Format  . . . . . . . . . . . .  5
+     2.3.  Address Translation Algorithms . . . . . . . . . . . . . .  7
+     2.4.  Text Representation  . . . . . . . . . . . . . . . . . . .  7
+   3.  Deployment Guidelines  . . . . . . . . . . . . . . . . . . . .  8
+     3.1.  Restrictions on the Use of the Well-Known Prefix . . . . .  8
+     3.2.  Impact on Inter-Domain Routing . . . . . . . . . . . . . .  8
+     3.3.  Choice of Prefix for Stateless Translation Deployments . .  9
+     3.4.  Choice of Prefix for Stateful Translation Deployments  . . 11
+   4.  Design Choices . . . . . . . . . . . . . . . . . . . . . . . . 12
+     4.1.  Choice of Suffix . . . . . . . . . . . . . . . . . . . . . 12
+     4.2.  Choice of the Well-Known Prefix  . . . . . . . . . . . . . 13
+   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
+     5.1.  Protection against Spoofing  . . . . . . . . . . . . . . . 14
+     5.2.  Secure Configuration . . . . . . . . . . . . . . . . . . . 15
+     5.3.  Firewall Configuration . . . . . . . . . . . . . . . . . . 15
+   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
+   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
+   8.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16
+   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
+     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 17
+     9.2.  Informative References . . . . . . . . . . . . . . . . . . 17
+
+
+
+
+
+
+
+Bao, et al.                  Standards Track                    [Page 2]
+
+RFC 6052        IPv6 Addressing of IPv4/IPv6 Translators    October 2010
+
+
+1.  Introduction
+
+   This document is part of a series of IPv4/IPv6 translation documents.
+   A framework for IPv4/IPv6 translation is discussed in
+   [v4v6-FRAMEWORK], including a taxonomy of scenarios that will be used
+   in this document.  Other documents specify the behavior of various
+   types of translators and gateways, including mechanisms for
+   translating between IP headers and other types of messages that
+   include IP addresses.  This document specifies how an individual IPv6
+   address is translated to a corresponding IPv4 address, and vice
+   versa, in cases where an algorithmic mapping is used.  While specific
+   types of devices are used herein as examples, it is the
+   responsibility of the specification of such devices to reference this
+   document for algorithmic mapping of the addresses themselves.
+
+   Section 2 describes the prefixes and the format of "IPv4-embedded
+   IPv6 addresses", i.e., IPv6 addresses in which 32 bits contain an
+   IPv4 address.  This format is common to both "IPv4-converted" and
+   "IPv4-translatable" IPv6 addresses.  This section also defines the
+   algorithms for translating addresses, and the text representation of
+   IPv4-embedded IPv6 addresses.
+
+   Section 3 discusses the choice of prefixes, the conditions in which
+   they can be used, and the use of IPv4-embedded IPv6 addresses with
+   stateless and stateful translation.
+
+   Section 4 provides a summary of the discussions behind two specific
+   design decisions, the choice of a null suffix and the specific value
+   of the selected prefix.
+
+   Section 5 discusses security concerns.
+
+   In some scenarios, a dual-stack host will unnecessarily send its
+   traffic through an IPv6/IPv4 translator.  This can be caused by the
+   host's default address selection algorithm [RFC3484], referrals, or
+   other reasons.  Optimizing these scenarios for dual-stack hosts is
+   for future study.
+
+1.1.  Applicability Scope
+
+   This document is part of a series defining address translation
+   services.  We understand that the address format could also be used
+   by other interconnection methods between IPv6 and IPv4, e.g., methods
+   based on encapsulation.  If encapsulation methods are developed by
+   the IETF, we expect that their descriptions will document their
+   specific use of IPv4-embedded IPv6 addresses.
+
+
+
+
+
+Bao, et al.                  Standards Track                    [Page 3]
+
+RFC 6052        IPv6 Addressing of IPv4/IPv6 Translators    October 2010
+
+
+1.2.  Conventions
+
+   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].
+
+1.3.  Terminology
+
+   This document makes use of the following terms:
+
+   Address translator:  any entity that has to derive an IPv4 address
+      from an IPv6 address or vice versa.  This applies not only to
+      devices that do IPv4/IPv6 packet translation, but also to other
+      entities that manipulate addresses, such as name resolution
+      proxies (e.g., DNS64 [DNS64]) and possibly other types of
+      Application Layer Gateways (ALGs).
+
+   IPv4-converted IPv6 addresses:  IPv6 addresses used to represent IPv4
+      nodes in an IPv6 network.  They are a variant of IPv4-embedded
+      IPv6 addresses and follow the format described in Section 2.2.
+
+   IPv4-embedded IPv6 addresses:  IPv6 addresses in which 32 bits
+      contain an IPv4 address.  Their format is described in
+      Section 2.2.
+
+   IPv4/IPv6 translator:  an entity that translates IPv4 packets to IPv6
+      packets, and vice versa.  It may do "stateless" translation,
+      meaning that there is no per-flow state required, or "stateful"
+      translation, meaning that per-flow state is created when the first
+      packet in a flow is received.
+
+   IPv4-translatable IPv6 addresses:  IPv6 addresses assigned to IPv6
+      nodes for use with stateless translation.  They are a variant of
+      IPv4-embedded IPv6 addresses and follow the format described in
+      Section 2.2.
+
+   Network-Specific Prefix:  an IPv6 prefix assigned by an organization
+      for use in algorithmic mapping.  Options for the Network-Specific
+      Prefix are discussed in Sections 3.3 and 3.4.
+
+   Well-Known Prefix:  the IPv6 prefix defined in this document for use
+      in an algorithmic mapping.
+
+
+
+
+
+
+
+
+
+Bao, et al.                  Standards Track                    [Page 4]
+
+RFC 6052        IPv6 Addressing of IPv4/IPv6 Translators    October 2010
+
+
+2.  IPv4-Embedded IPv6 Address Prefix and Format
+
+2.1.  Well-Known Prefix
+
+   This document reserves a "Well-Known Prefix" for use in an
+   algorithmic mapping.  The value of this IPv6 prefix is:
+
+      64:ff9b::/96
+
+2.2.  IPv4-Embedded IPv6 Address Format
+
+   IPv4-converted IPv6 addresses and IPv4-translatable IPv6 addresses
+   follow the same format, described here as the IPv4-embedded IPv6
+   address Format.  IPv4-embedded IPv6 addresses are composed of a
+   variable-length prefix, the embedded IPv4 address, and a variable-
+   length suffix, as presented in the following diagram, in which PL
+   designates the prefix length:
+
+    +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+    |PL| 0-------------32--40--48--56--64--72--80--88--96--104---------|
+    +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+    |32|     prefix    |v4(32)         | u | suffix                    |
+    +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+    |40|     prefix        |v4(24)     | u |(8)| suffix                |
+    +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+    |48|     prefix            |v4(16) | u | (16)  | suffix            |
+    +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+    |56|     prefix                |(8)| u |  v4(24)   | suffix        |
+    +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+    |64|     prefix                    | u |   v4(32)      | suffix    |
+    +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+    |96|     prefix                                    |    v4(32)     |
+    +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+
+                                 Figure 1
+
+   In these addresses, the prefix shall be either the "Well-Known
+   Prefix" or a "Network-Specific Prefix" unique to the organization
+   deploying the address translators.  The prefixes can only have one of
+   the following lengths: 32, 40, 48, 56, 64, or 96.  (The Well-Known
+   Prefix is 96 bits long, and can only be used in the last form of the
+   table.)
+
+   Various deployments justify different prefix lengths with Network-
+   Specific Prefixes.  The trade-off between different prefix lengths
+   are discussed in Sections 3.3 and 3.4.
+
+
+
+
+
+Bao, et al.                  Standards Track                    [Page 5]
+
+RFC 6052        IPv6 Addressing of IPv4/IPv6 Translators    October 2010
+
+
+   Bits 64 to 71 of the address are reserved for compatibility with the
+   host identifier format defined in the IPv6 addressing architecture
+   [RFC4291].  These bits MUST be set to zero.  When using a /96
+   Network-Specific Prefix, the administrators MUST ensure that the bits
+   64 to 71 are set to zero.  A simple way to achieve that is to
+   construct the /96 Network-Specific Prefix by picking a /64 prefix,
+   and then adding 4 octets set to zero.
+
+   The IPv4 address is encoded following the prefix, most significant
+   bits first.  Depending of the prefix length, the 4 octets of the
+   address may be separated by the reserved octet "u", whose 8 bits MUST
+   be set to zero.  In particular:
+
+   o  When the prefix is 32 bits long, the IPv4 address is encoded in
+      positions 32 to 63.
+
+   o  When the prefix is 40 bits long, 24 bits of the IPv4 address are
+      encoded in positions 40 to 63, with the remaining 8 bits in
+      position 72 to 79.
+
+   o  When the prefix is 48 bits long, 16 bits of the IPv4 address are
+      encoded in positions 48 to 63, with the remaining 16 bits in
+      position 72 to 87.
+
+   o  When the prefix is 56 bits long, 8 bits of the IPv4 address are
+      encoded in positions 56 to 63, with the remaining 24 bits in
+      position 72 to 95.
+
+   o  When the prefix is 64 bits long, the IPv4 address is encoded in
+      positions 72 to 103.
+
+   o  When the prefix is 96 bits long, the IPv4 address is encoded in
+      positions 96 to 127.
+
+   There are no remaining bits, and thus no suffix, if the prefix is 96
+   bits long.  In the other cases, the remaining bits of the address
+   constitute the suffix.  These bits are reserved for future extensions
+   and SHOULD be set to zero.  Address translators who receive IPv4-
+   embedded IPv6 addresses where these bits are not zero SHOULD ignore
+   the bits' value and proceed as if the bits' value were zero.  (Future
+   extensions may specify a different behavior.)
+
+
+
+
+
+
+
+
+
+
+Bao, et al.                  Standards Track                    [Page 6]
+
+RFC 6052        IPv6 Addressing of IPv4/IPv6 Translators    October 2010
+
+
+2.3.  Address Translation Algorithms
+
+   IPv4-embedded IPv6 addresses are composed according to the following
+   algorithm:
+
+   o  Concatenate the prefix, the 32 bits of the IPv4 address, and the
+      suffix (if needed) to obtain a 128-bit address.
+
+   o  If the prefix length is less than 96 bits, insert the null octet
+      "u" at the appropriate position (bits 64 to 71), thus causing the
+      least significant octet to be excluded, as documented in Figure 1.
+
+   The IPv4 addresses are extracted from the IPv4-embedded IPv6
+   addresses according to the following algorithm:
+
+   o  If the prefix is 96 bits long, extract the last 32 bits of the
+      IPv6 address;
+
+   o  For the other prefix lengths, remove the "u" octet to obtain a
+      120-bit sequence (effectively shifting bits 72-127 to positions
+      64-119), then extract the 32 bits following the prefix.
+
+2.4.  Text Representation
+
+   IPv4-embedded IPv6 addresses will be represented in text in
+   conformity with Section 2.2 of [RFC4291].  IPv4-embedded IPv6
+   addresses constructed using the Well-Known Prefix or a /96 Network-
+   Specific Prefix may be represented using the alternative form
+   presented in Section 2.2 of [RFC4291], with the embedded IPv4 address
+   represented in dotted decimal notation.  Examples of such
+   representations are presented in Tables 1 and 2.
+
+   +-----------------------+------------+------------------------------+
+   | Network-Specific      |    IPv4    | IPv4-embedded IPv6 address   |
+   | Prefix                |   address  |                              |
+   +-----------------------+------------+------------------------------+
+   | 2001:db8::/32         | 192.0.2.33 | 2001:db8:c000:221::          |
+   | 2001:db8:100::/40     | 192.0.2.33 | 2001:db8:1c0:2:21::          |
+   | 2001:db8:122::/48     | 192.0.2.33 | 2001:db8:122:c000:2:2100::   |
+   | 2001:db8:122:300::/56 | 192.0.2.33 | 2001:db8:122:3c0:0:221::     |
+   | 2001:db8:122:344::/64 | 192.0.2.33 | 2001:db8:122:344:c0:2:2100:: |
+   | 2001:db8:122:344::/96 | 192.0.2.33 | 2001:db8:122:344::192.0.2.33 |
+   +-----------------------+------------+------------------------------+
+
+    Table 1: Text Representation of IPv4-Embedded IPv6 Addresses Using
+                         Network-Specific Prefixes
+
+
+
+
+
+Bao, et al.                  Standards Track                    [Page 7]
+
+RFC 6052        IPv6 Addressing of IPv4/IPv6 Translators    October 2010
+
+
+     +-------------------+--------------+----------------------------+
+     | Well-Known Prefix | IPv4 address | IPv4-Embedded IPv6 address |
+     +-------------------+--------------+----------------------------+
+     | 64:ff9b::/96      |  192.0.2.33  | 64:ff9b::192.0.2.33        |
+     +-------------------+--------------+----------------------------+
+
+    Table 2: Text Representation of IPv4-Embedded IPv6 Addresses Using
+                           the Well-Known Prefix
+
+   The Network-Specific Prefix examples in Table 1 are derived from the
+   IPv6 prefix reserved for documentation in [RFC3849].  The IPv4
+   address 192.0.2.33 is part of the subnet 192.0.2.0/24 reserved for
+   documentation in [RFC5735].  The representation of IPv6 addresses is
+   compatible with [RFC5952].
+
+3.  Deployment Guidelines
+
+3.1.  Restrictions on the Use of the Well-Known Prefix
+
+   The Well-Known Prefix MUST NOT be used to represent non-global IPv4
+   addresses, such as those defined in [RFC1918] or listed in Section 3
+   of [RFC5735].  Address translators MUST NOT translate packets in
+   which an address is composed of the Well-Known Prefix and a non-
+   global IPv4 address; they MUST drop these packets.
+
+   The Well-Known Prefix SHOULD NOT be used to construct IPv4-
+   translatable IPv6 addresses.  The nodes served by IPv4-translatable
+   IPv6 addresses should be able to receive global IPv6 traffic bound to
+   their IPv4-translatable IPv6 address without incurring intermediate
+   protocol translation.  This is only possible if the specific prefix
+   used to build the IPv4-translatable IPv6 addresses is advertised in
+   inter-domain routing, but the advertisement of more specific prefixes
+   derived from the Well-Known Prefix is not supported, as explained in
+   Section 3.2.  Network-Specific Prefixes SHOULD be used in these
+   scenarios, as explained in Section 3.3.
+
+   The Well-Known Prefix MAY be used by organizations deploying
+   translation services, as explained in Section 3.4.
+
+3.2.  Impact on Inter-Domain Routing
+
+   The Well-Known Prefix MAY appear in inter-domain routing tables, if
+   service providers decide to provide IPv6-IPv4 interconnection
+   services to peers.  Advertisement of the Well-Known Prefix SHOULD be
+   controlled either by upstream and/or downstream service providers
+   according to inter-domain routing policies, e.g., through
+
+
+
+
+
+Bao, et al.                  Standards Track                    [Page 8]
+
+RFC 6052        IPv6 Addressing of IPv4/IPv6 Translators    October 2010
+
+
+   configuration of BGP [RFC4271].  Organizations that advertise the
+   Well-Known Prefix in inter-domain routing MUST be able to provide
+   IPv4/IPv6 translation service.
+
+   When the IPv4/IPv6 translation relies on the Well-Known Prefix, IPv4-
+   embedded IPv6 prefixes longer than the Well-Known Prefix MUST NOT be
+   advertised in BGP (especially External BGP) [RFC4271] because this
+   leads to importing the IPv4 routing table into the IPv6 one and
+   therefore introduces scalability issues to the global IPv6 routing
+   table.  Administrators of BGP nodes SHOULD configure filters that
+   discard advertisements of embedded IPv6 prefixes longer than the
+   Well-Known Prefix.
+
+   When the IPv4/IPv6 translation service relies on Network-Specific
+   Prefixes, the IPv4-translatable IPv6 prefixes used in stateless
+   translation MUST be advertised with proper aggregation to the IPv6
+   Internet.  Similarly, if translators are configured with multiple
+   Network-Specific Prefixes, these prefixes MUST be advertised to the
+   IPv6 Internet with proper aggregation.
+
+3.3.  Choice of Prefix for Stateless Translation Deployments
+
+   Organizations may deploy translation services using stateless
+   translation.  In these deployments, internal IPv6 nodes are addressed
+   using IPv4-translatable IPv6 addresses, which enable them to be
+   accessed by IPv4 nodes.  The addresses of these external IPv4 nodes
+   are then represented in IPv4-converted IPv6 addresses.
+
+   Organizations deploying stateless IPv4/IPv6 translation SHOULD assign
+   a Network-Specific Prefix to their IPv4/IPv6 translation service.
+   IPv4-translatable and IPv4-converted IPv6 addresses MUST be
+   constructed as specified in Section 2.2.  IPv4-translatable IPv6
+   addresses MUST use the selected Network-Specific Prefix.  Both IPv4-
+   translatable IPv6 addresses and IPv4-converted IPv6 addresses SHOULD
+   use the same prefix.
+
+   Using the same prefix ensures that IPv6 nodes internal to the
+   organization will use the most efficient paths to reach the nodes
+   served by IPv4-translatable IPv6 addresses.  Specifically, if a node
+   learns the IPv4 address of a target internal node without knowing
+   that this target is in fact located behind the same translator that
+   the node also uses, translation rules will ensure that the IPv6
+   address constructed with the Network-Specific Prefix is the same as
+   the IPv4-translatable IPv6 address assigned to the target.  Standard
+   routing preference (i.e., "most specific match wins") will then
+   ensure that the IPv6 packets are delivered directly, without
+   requiring that translators receive the packets and then return them
+   in the direction from which they came.
+
+
+
+Bao, et al.                  Standards Track                    [Page 9]
+
+RFC 6052        IPv6 Addressing of IPv4/IPv6 Translators    October 2010
+
+
+   The intra-domain routing protocol must be able to deliver packets to
+   the nodes served by IPv4-translatable IPv6 addresses.  This may
+   require routing on some or all of the embedded IPv4 address bits.
+   Security considerations detailed in Section 5 require that routers
+   check the validity of the IPv4-translatable IPv6 source addresses,
+   using some form of reverse path check.
+
+   The management of stateless address translation can be illustrated
+   with a small example:
+
+      We will consider an IPv6 network with the prefix 2001:db8:
+      122::/48.  The network administrator has selected the Network-
+      Specific Prefix 2001:db8:122:344::/64 for managing stateless IPv4/
+      IPv6 translation.  The IPv4-translatable address block for IPv4
+      subnet 192.0.2.0/24 is 2001:db8:122:344:c0:2::/96.  In this
+      network, the host A is assigned the IPv4-translatable IPv6 address
+      2001:db8:122:344:c0:2:2100::, which corresponds to the IPv4
+      address 192.0.2.33.  Host A's address is configured either
+      manually or through DHCPv6.
+
+      In this example, host A is not directly connected to the
+      translator, but instead to a link managed by a router R.  The
+      router R is configured to forward to A the packets bound to 2001:
+      db8:122:344:c0:2:2100::.  To receive these packets, R will
+      advertise reachability of the prefix 2001:db8:122:344:c0:2:2100::/
+      104 in the intra-domain routing protocol -- or perhaps a shorter
+      prefix if many hosts on link have IPv4-translatable IPv6 addresses
+      derived from the same IPv4 subnet.  If a packet bound to
+      192.0.2.33 reaches the translator, the destination address will be
+      translated to 2001:db8:122:344:c0:2:2100::, and the packet will be
+      routed towards R and then to A.
+
+      Let's suppose now that a host B of the same domain learns the IPv4
+      address of A, maybe through an application-specific referral.  If
+      B has translation-aware software, B can compose a destination
+      address by combining the Network-Specific Prefix 2001:db8:122:
+      344::/64 and the IPv4 address 192.0.2.33, resulting in the address
+      2001:db8:122:344:c0:2:2100::.  The packet sent by B will be
+      forwarded towards R, and then to A, avoiding protocol translation.
+
+   Forwarding, and reverse path checks, are more efficient when
+   performed on the combination of the prefix and the IPv4 address.  In
+   theory, routers are able to route on prefixes of any length, but in
+   practice there may be routers for which routing on prefixes larger
+   than 64 bits is slower.  However, routing efficiency is not the only
+   consideration in the choice of a prefix length.  Organizations also
+   need to consider the availability of prefixes, and the potential
+   impact of all-zero identifiers.
+
+
+
+Bao, et al.                  Standards Track                   [Page 10]
+
+RFC 6052        IPv6 Addressing of IPv4/IPv6 Translators    October 2010
+
+
+   If a /32 prefix is used, all the routing bits are contained in the
+   top 64 bits of the IPv6 address, leading to excellent routing
+   properties.  These prefixes may however be hard to obtain, and
+   allocation of a /32 to a small set of IPv4-translatable IPv6
+   addresses may be seen as wasteful.  In addition, the /32 prefix and a
+   zero suffix lead to an all-zero interface identifier, which is an
+   issue that we discuss in Section 4.1.
+
+   Intermediate prefix lengths such as /40, /48, or /56 appear as
+   compromises.  Only some of the IPv4 bits are part of the /64
+   prefixes.  Reverse path checks, in particular, may have a limited
+   efficiency.  Reverse path checks limited to the most significant bits
+   of the IPv4 address will reduce the possibility of spoofing external
+   IPv4 addresses, but would allow IPv6 nodes to spoof internal IPv4-
+   translatable IPv6 addresses.
+
+   We propose a compromise, based on using no more than 1/256th of an
+   organization's allocation of IPv6 addresses for the IPv4/IPv6
+   translation service.  For example, if the organization is an Internet
+   Service Provider with an allocated IPv6 prefix /32 or shorter, the
+   ISP could dedicate a /40 prefix to the translation service.  An end
+   site with a /48 allocation could dedicate a /56 prefix to the
+   translation service, or possibly a /96 prefix if all IPv4-
+   translatable IPv6 addresses are located on the same link.
+
+   The recommended prefix length is also a function of the deployment
+   scenario.  The stateless translation can be used for Scenario 1,
+   Scenario 2, Scenario 5, and Scenario 6 defined in [v4v6-FRAMEWORK].
+   For different scenarios, the prefix length recommendations are:
+
+   o  For Scenario 1 (an IPv6 network to the IPv4 Internet) and Scenario
+      2 (the IPv4 Internet to an IPv6 network), an ISP holding a /32
+      allocation SHOULD use a /40 prefix, and a site holding a /48
+      allocation SHOULD use a /56 prefix.
+
+   o  For Scenario 5 (an IPv6 network to an IPv4 network) and Scenario 6
+      (an IPv4 network to an IPv6 network), the deployment SHOULD use a
+      /64 or a /96 prefix.
+
+3.4.  Choice of Prefix for Stateful Translation Deployments
+
+   Organizations may deploy translation services based on stateful
+   translation technology.  An organization may decide to use either a
+   Network-Specific Prefix or the Well-Known Prefix for its stateful
+   IPv4/IPv6 translation service.
+
+
+
+
+
+
+Bao, et al.                  Standards Track                   [Page 11]
+
+RFC 6052        IPv6 Addressing of IPv4/IPv6 Translators    October 2010
+
+
+   When these services are used, IPv6 nodes are addressed through
+   standard IPv6 addresses, while IPv4 nodes are represented by IPv4-
+   converted IPv6 addresses, as specified in Section 2.2.
+
+   The stateful nature of the translation creates a potential stability
+   issue when the organization deploys multiple translators.  If several
+   translators use the same prefix, there is a risk that packets
+   belonging to the same connection may be routed to different
+   translators as the internal routing state changes.  This issue can be
+   avoided either by assigning different prefixes to different
+   translators or by ensuring that all translators using the same prefix
+   coordinate their state.
+
+   Stateful translation can be used in scenarios defined in
+   [v4v6-FRAMEWORK].  The Well-Known Prefix SHOULD be used in these
+   scenarios, with two exceptions:
+
+   o  In all scenarios, the translation MAY use a Network-Specific
+      Prefix, if deemed appropriate for management reasons.
+
+   o  The Well-Known Prefix MUST NOT be used for Scenario 3 (the IPv6
+      Internet to an IPv4 network), as this would lead to using the
+      Well-Known Prefix with non-global IPv4 addresses.  That means a
+      Network-Specific Prefix (for example, a /96 prefix) MUST be used
+      in that scenario.
+
+4.  Design Choices
+
+   The prefix that we have chosen reflects two design choices, the null
+   suffix and the specific value of the Well-Known Prefix.  We provide
+   here a summary of the discussions leading to those two choices.
+
+4.1.  Choice of Suffix
+
+   The address format described in Section 2.2 recommends a zero suffix.
+   Before making this recommendation, we considered different options:
+   checksum neutrality, the encoding of a port range, and a value
+   different than 0.
+
+   In the case of stateless translation, there would be no need for the
+   translator to recompute a one's complement checksum if both the IPv4-
+   translatable and the IPv4-converted IPv6 addresses were constructed
+   in a "checksum-neutral" manner, that is, if the IPv6 addresses would
+   have the same one's complement checksum as the embedded IPv4 address.
+   In the case of stateful translation, checksum neutrality does not
+   eliminate checksum computation during translation, as only one of the
+   two addresses would be checksum neutral.  We considered reserving 16
+   bits in the suffix to guarantee checksum neutrality, but declined
+
+
+
+Bao, et al.                  Standards Track                   [Page 12]
+
+RFC 6052        IPv6 Addressing of IPv4/IPv6 Translators    October 2010
+
+
+   because it would not help with stateful translation and because
+   checksum neutrality can also be achieved by an appropriate choice of
+   the Network-Specific Prefix, i.e., selecting a prefix whose one's
+   complement checksum equals either 0 or 0xffff.
+
+   There have been proposals to complement stateless translation with a
+   port-range feature.  Instead of mapping an IPv4 address to exactly
+   one IPv6 prefix, the options would allow several IPv6 nodes to share
+   an IPv4 address, with each node managing a different range of ports.
+   If a port range extension is needed, it could be defined later, using
+   bits currently reserved as null in the suffix.
+
+   When a /32 prefix is used, an all-zero suffix results in an all-zero
+   interface identifier.  We understand the conflict with Section 2.6.1
+   of RFC4291, which specifies that all zeroes are used for the subnet-
+   router anycast address.  However, in our specification, there is only
+   one node with an IPv4-translatable IPv6 address in the /64 subnet, so
+   the anycast semantic does not create confusion.  We thus decided to
+   keep the null suffix for now.  This issue does not exist for prefixes
+   larger than 32 bits, such as the /40, /56, /64, and /96 prefixes that
+   we recommend in Section 3.3.
+
+4.2.  Choice of the Well-Known Prefix
+
+   Before making our recommendation of the Well-Known Prefix, we were
+   faced with three choices:
+
+   o  reuse the IPv4-mapped prefix, ::ffff:0:0/96, as specified in RFC
+      2765, Section 2.1;
+
+   o  request IANA to allocate a /32 prefix, or
+
+   o  request allocation of a new /96 prefix.
+
+   We weighted the pros and cons of these choices before settling on the
+   recommended /96 Well-Known Prefix.
+
+   The main advantage of the existing IPv4-mapped prefix is that it is
+   already defined.  Reusing that prefix would require minimal
+   standardization efforts.  However, being already defined is not just
+   an advantage, as there may be side effects of current
+   implementations.  When presented with the IPv4-mapped prefix, current
+   versions of Windows and Mac OS generate IPv4 packets, but will not
+   send IPv6 packets.  If we used the IPv4-mapped prefix, these nodes
+   would not be able to support translation without modification.  This
+   will defeat the main purpose of the translation techniques.  We thus
+   eliminated the first choice, i.e., decided to not reuse the IPv4-
+   mapped prefix, ::ffff:0:0/96.
+
+
+
+Bao, et al.                  Standards Track                   [Page 13]
+
+RFC 6052        IPv6 Addressing of IPv4/IPv6 Translators    October 2010
+
+
+   A /32 prefix would have allowed the embedded IPv4 address to fit
+   within the top 64 bits of the IPv6 address.  This would have
+   facilitated routing and load balancing when an organization deploys
+   several translators.  However, such destination-address-based load
+   balancing may not be desirable.  It is not compatible with Session
+   Traversal Utilities for NAT (STUN) [RFC5389] in the deployments
+   involving multiple stateful translators, each one having a different
+   pool of IPv4 addresses.  STUN compatibility would only be achieved if
+   the translators managed the same pool of IPv4 addresses and were able
+   to coordinate their translation state, in which case there is no big
+   advantage to using a /32 prefix rather than a /96 prefix.
+
+   According to Section 2.2 of [RFC4291], in the legal textual
+   representations of IPv6 addresses, dotted decimal can only appear at
+   the end.  The /96 prefix is compatible with that requirement.  It
+   enables the dotted decimal notation without requiring an update to
+   [RFC4291].  This representation makes the address format easier to
+   use and the log files easier to read.
+
+   The prefix that we recommend has the particularity of being "checksum
+   neutral".  The sum of the hexadecimal numbers "0064" and "ff9b" is
+   "ffff", i.e., a value equal to zero in one's complement arithmetic.
+   An IPv4-embedded IPv6 address constructed with this prefix will have
+   the same one's complement checksum as the embedded IPv4 address.
+
+5.  Security Considerations
+
+5.1.  Protection against Spoofing
+
+   IPv4/IPv6 translators can be modeled as special routers, are subject
+   to the same risks, and can implement the same mitigations.  (The
+   discussion of generic threats to routers and their mitigations is
+   beyond the scope of this document.)  There is, however, a particular
+   risk that directly derives from the practice of embedding IPv4
+   addresses in IPv6: address spoofing.
+
+   An attacker could use an IPv4-embedded IPv6 address as the source
+   address of malicious packets.  After translation, the packets will
+   appear as IPv4 packets from the specified source, and the attacker
+   may be hard to track.  If left without mitigation, the attack would
+   allow malicious IPv6 nodes to spoof arbitrary IPv4 addresses.
+
+   The mitigation is to implement reverse path checks and to verify
+   throughout the network that packets are coming from an authorized
+   location.
+
+
+
+
+
+
+Bao, et al.                  Standards Track                   [Page 14]
+
+RFC 6052        IPv6 Addressing of IPv4/IPv6 Translators    October 2010
+
+
+5.2.  Secure Configuration
+
+   The prefixes used for address translation are used by IPv6 nodes to
+   send packets to IPv6/IPv4 translators.  Attackers could attempt to
+   fool nodes, DNS gateways, and IPv4/IPv6 translators into using wrong
+   values for these parameters, resulting in network disruption, denial
+   of service, and possible information disclosure.  To mitigate such
+   attacks, network administrators need to ensure that prefixes are
+   configured in a secure way.
+
+   The mechanisms for achieving secure configuration of prefixes are
+   beyond the scope of this document.
+
+5.3.  Firewall Configuration
+
+   Many firewalls and other security devices filter traffic based on
+   IPv4 addresses.  Attackers could attempt to fool these firewalls by
+   sending IPv6 packets to or from IPv6 addresses that translate to the
+   filtered IPv4 addresses.  If the attack is successful, traffic that
+   was previously blocked might be able to pass through the firewalls
+   disguised as IPv6 packets.  In all such scenarios, administrators
+   should assure that packets that send to or from IPv4-embedded IPv6
+   addresses are subject to the same filtering as those directly sent to
+   or from the embedded IPv4 addresses.
+
+   The mechanisms for configuring firewalls and security devices to
+   achieve this filtering are beyond the scope of this document.
+
+6.  IANA Considerations
+
+   IANA has made the following changes in the "Internet Protocol Version
+   6 Address Space" registry located at http://www.iana.org.
+
+   OLD:
+
+      IPv6 Prefix Allocation       Reference    Note
+      ----------- ---------------- ------------ ----------------
+      0000::/8    Reserved by IETF [RFC4291]    [1][5]
+
+   NEW:
+
+      IPv6 Prefix Allocation       Reference    Note
+      ----------- ---------------- ------------ ----------------
+      0000::/8    Reserved by IETF [RFC4291]    [1][5][6]
+
+      [6] The "Well-Known Prefix" 64:ff9b::/96 used in an algorithmic
+          mapping between IPv4 to IPv6 addresses is defined out of the
+          0000::/8 address block, per RFC 6052.
+
+
+
+Bao, et al.                  Standards Track                   [Page 15]
+
+RFC 6052        IPv6 Addressing of IPv4/IPv6 Translators    October 2010
+
+
+7.  Acknowledgements
+
+   Many people in the BEHAVE WG have contributed to the discussion that
+   led to this document, including Andrew Sullivan, Andrew Yourtchenko,
+   Ari Keranen, Brian Carpenter, Charlie Kaufman, Dan Wing, Dave Thaler,
+   David Harrington, Ed Jankiewicz, Fred Baker, Hiroshi Miyata, Iljitsch
+   van Beijnum, John Schnizlein, Keith Moore, Kevin Yin, Magnus
+   Westerlund, Margaret Wasserman, Masahito Endo, Phil Roberts, Philip
+   Matthews, Remi Denis-Courmont, Remi Despres, and William Waites.
+
+   Marcelo Bagnulo is partly funded by Trilogy, a research project
+   supported by the European Commission under its Seventh Framework
+   Program.
+
+8.  Contributors
+
+   The following individuals co-authored documents from which text has
+   been incorporated, and are listed in alphabetical order.
+
+       Dave Thaler
+       Microsoft Corporation
+       One Microsoft Way
+       Redmond, WA  98052
+       USA
+       Phone: +1 425 703 8835
+       EMail: dthaler@microsoft.com
+
+       Fred Baker
+       Cisco Systems
+       Santa Barbara, California  93117
+       USA
+       Phone: +1-408-526-4257
+       Fax:   +1-413-473-2403
+       EMail: fred@cisco.com
+
+       Hiroshi Miyata
+       Yokogawa Electric Corporation
+       2-9-32 Nakacho
+       Musashino-shi, Tokyo  180-8750
+       JAPAN
+       EMail: h.miyata@jp.yokogawa.com
+
+
+
+
+
+
+
+
+
+
+Bao, et al.                  Standards Track                   [Page 16]
+
+RFC 6052        IPv6 Addressing of IPv4/IPv6 Translators    October 2010
+
+
+9.  References
+
+9.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
+              Architecture", RFC 4291, February 2006.
+
+9.2.  Informative References
+
+   [DNS64]    Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum,
+              "DNS64: DNS extensions for Network Address Translation
+              from IPv6 Clients to IPv4 Servers", Work in Progress,
+              October 2010.
+
+   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
+              E. Lear, "Address Allocation for Private Internets",
+              BCP 5, RFC 1918, February 1996.
+
+   [RFC3484]  Draves, R., "Default Address Selection for Internet
+              Protocol version 6 (IPv6)", RFC 3484, February 2003.
+
+   [RFC3849]  Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix
+              Reserved for Documentation", RFC 3849, July 2004.
+
+   [RFC4271]  Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
+              Protocol 4 (BGP-4)", RFC 4271, January 2006.
+
+   [RFC5389]  Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
+              "Session Traversal Utilities for NAT (STUN)", RFC 5389,
+              October 2008.
+
+   [RFC5735]  Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses",
+              BCP 153, RFC 5735, January 2010.
+
+   [RFC5952]  Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
+              Address Text Representation", RFC 5952, August 2010.
+
+   [v4v6-FRAMEWORK]
+              Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
+              IPv4/IPv6 Translation", Work in Progress, August 2010.
+
+
+
+
+
+
+
+
+Bao, et al.                  Standards Track                   [Page 17]
+
+RFC 6052        IPv6 Addressing of IPv4/IPv6 Translators    October 2010
+
+
+Authors' Addresses
+
+   Congxiao Bao
+   CERNET Center/Tsinghua University
+   Room 225, Main Building, Tsinghua University
+   Beijing,   100084
+   China
+   Phone: +86 10-62785983
+   EMail: congxiao@cernet.edu.cn
+
+
+   Christian Huitema
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052-6399
+   U.S.A.
+   EMail: huitema@microsoft.com
+
+
+   Marcelo Bagnulo
+   UC3M
+   Av. Universidad 30
+   Leganes, Madrid  28911
+   Spain
+   Phone: +34-91-6249500
+   EMail: marcelo@it.uc3m.es
+   URI:   http://www.it.uc3m.es/marcelo
+
+
+   Mohamed Boucadair
+   France Telecom
+   3, Av Francois Chateaux
+   Rennes  350000
+   France
+   EMail: mohamed.boucadair@orange-ftgroup.com
+
+
+   Xing Li
+   CERNET Center/Tsinghua University
+   Room 225, Main Building, Tsinghua University
+   Beijing,   100084
+   China
+   Phone: +86 10-62785983
+   EMail: xing@cernet.edu.cn
+
+
+
+
+
+
+
+Bao, et al.                  Standards Track                   [Page 18]
+
diff --git a/doc/rfc/rfc6147.txt b/doc/rfc/rfc6147.txt
new file mode 100644
index 0000000000..0ccd933530
--- /dev/null
+++ b/doc/rfc/rfc6147.txt
@@ -0,0 +1,1795 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                        M. Bagnulo
+Request for Comments: 6147                                          UC3M
+Category: Standards Track                                    A. Sullivan
+ISSN: 2070-1721                                                 Shinkuro
+                                                             P. Matthews
+                                                          Alcatel-Lucent
+                                                          I. van Beijnum
+                                                          IMDEA Networks
+                                                              April 2011
+
+
+         DNS64: DNS Extensions for Network Address Translation
+                   from IPv6 Clients to IPv4 Servers
+
+Abstract
+
+   DNS64 is a mechanism for synthesizing AAAA records from A records.
+   DNS64 is used with an IPv6/IPv4 translator to enable client-server
+   communication between an IPv6-only client and an IPv4-only server,
+   without requiring any changes to either the IPv6 or the IPv4 node,
+   for the class of applications that work through NATs.  This document
+   specifies DNS64, and provides suggestions on how it should be
+   deployed in conjunction with IPv6/IPv4 translators.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6147.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bagnulo, et al.              Standards Track                    [Page 1]
+
+RFC 6147                          DNS64                       April 2011
+
+
+Copyright Notice
+
+   Copyright (c) 2011 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bagnulo, et al.              Standards Track                    [Page 2]
+
+RFC 6147                          DNS64                       April 2011
+
+
+Table of Contents
+
+   1. Introduction ....................................................4
+   2. Overview ........................................................5
+   3. Background to DNS64-DNSSEC Interaction ..........................7
+   4. Terminology .....................................................9
+   5. DNS64 Normative Specification ..................................10
+      5.1. Resolving AAAA Queries and the Answer Section .............11
+           5.1.1. The Answer when There is AAAA Data Available .......11
+           5.1.2. The Answer when There is an Error ..................11
+           5.1.3. Dealing with Timeouts ..............................12
+           5.1.4. Special Exclusion Set for AAAA Records .............12
+           5.1.5. Dealing with CNAME and DNAME .......................12
+           5.1.6. Data for the Answer when Performing Synthesis ......13
+           5.1.7. Performing the Synthesis ...........................13
+           5.1.8. Querying in Parallel ...............................14
+      5.2. Generation of the IPv6 Representations of IPv4 Addresses ..14
+      5.3. Handling Other Resource Records and the Additional
+           Section ...................................................15
+           5.3.1. PTR Resource Record ................................15
+           5.3.2. Handling the Additional Section ....................16
+           5.3.3. Other Resource Records .............................17
+      5.4. Assembling a Synthesized Response to a AAAA Query .........17
+      5.5. DNSSEC Processing: DNS64 in Validating Resolver Mode ......17
+   6. Deployment Notes ...............................................19
+      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
+           6.3.2. Accidental Dual-Stack DNS64 Use ....................20
+           6.3.3. Intentional Dual-Stack DNS64 Use ...................21
+   7. Deployment Scenarios and Examples ..............................21
+      7.1. Example of "an IPv6 Network to the IPv4 Internet"
+           Setup with DNS64 in DNS Server Mode .......................22
+      7.2. Example of "an IPv6 Network to the IPv4 Internet"
+           Setup with DNS64 in Stub-Resolver Mode ....................23
+      7.3. Example of "the IPv6 Internet to an IPv4 Network"
+           Setup with DNS64 in DNS Server Mode .......................24
+   8. Security Considerations ........................................27
+   9. Contributors ...................................................27
+   10. Acknowledgements ..............................................27
+   11. References ....................................................28
+      11.1. Normative References .....................................28
+      11.2. Informative References ...................................28
+   Appendix A.  Motivations and Implications of Synthesizing AAAA
+                Resource Records when Real AAAA Resource Records
+                Exist ................................................30
+
+
+
+
+Bagnulo, et al.              Standards Track                    [Page 3]
+
+RFC 6147                          DNS64                       April 2011
+
+
+1.  Introduction
+
+   This document specifies DNS64, a mechanism that is part of the
+   toolbox for IPv4-IPv6 transition and coexistence.  DNS64, used
+   together with an IPv6/IPv4 translator such as stateful NAT64
+   [RFC6146], allows an IPv6-only client to initiate communications by
+   name to an IPv4-only server.
+
+   DNS64 is a mechanism for synthesizing AAAA resource records (RRs)
+   from A RRs.  A synthetic AAAA RR created by the DNS64 from an
+   original A RR contains the same owner name of the original A RR, but
+   it contains an IPv6 address instead of an IPv4 address.  The IPv6
+   address is an IPv6 representation of the IPv4 address contained in
+   the original A RR.  The IPv6 representation of the IPv4 address is
+   algorithmically generated from the IPv4 address returned in the A RR
+   and a set of parameters configured in the DNS64 (typically, an IPv6
+   prefix used by IPv6 representations of IPv4 addresses and,
+   optionally, other parameters).
+
+   Together with an IPv6/IPv4 translator, these two mechanisms allow an
+   IPv6-only client to initiate communications to an IPv4-only server
+   using the Fully Qualified Domain Name (FQDN) of the server.
+
+   These mechanisms are expected to play a critical role in the IPv4-
+   IPv6 transition and coexistence.  Due to IPv4 address depletion, it
+   is likely that in the future, many IPv6-only clients will want to
+   connect to IPv4-only servers.  In the typical case, the approach only
+   requires the deployment of IPv6/IPv4 translators that connect an
+   IPv6-only network to an IPv4-only network, along with the deployment
+   of one or more DNS64-enabled name servers.  However, some features
+   require performing the DNS64 function directly in the end hosts
+   themselves.
+
+   This document is structured as follows: Section 2 provides a
+   non-normative overview of the behavior of DNS64.  Section 3 provides
+   a non-normative background required to understand the interaction
+   between DNS64 and DNS Security Extensions (DNSSEC).  The normative
+   specification of DNS64 is provided in Sections 4, 5, and 6.
+   Section 4 defines the terminology, Section 5 is the actual DNS64
+   specification, and Section 6 covers deployment issues.  Section 7 is
+   non-normative and provides a set of examples and typical deployment
+   scenarios.
+
+
+
+
+
+
+
+
+
+Bagnulo, et al.              Standards Track                    [Page 4]
+
+RFC 6147                          DNS64                       April 2011
+
+
+2.  Overview
+
+   This section provides an introduction to the DNS64 mechanism.
+
+   We assume that we have one or more IPv6/IPv4 translator boxes
+   connecting an IPv4 network and an IPv6 network.  The IPv6/IPv4
+   translator device provides translation services between the two
+   networks, enabling communication between IPv4-only hosts and
+   IPv6-only hosts.  (NOTE: By "IPv6-only hosts", we mean hosts running
+   IPv6-only applications and hosts that can only use IPv6, as well as
+   cases where only IPv6 connectivity is available to the client.  By
+   "IPv4-only servers", we mean servers running IPv4-only applications
+   and servers that can only use IPv4, as well as cases where only IPv4
+   connectivity is available to the server).  Each IPv6/IPv4 translator
+   used in conjunction with DNS64 must allow communications initiated
+   from the IPv6-only host to the IPv4-only host.
+
+   To allow an IPv6 initiator to do a standard AAAA RR DNS lookup to
+   learn the address of the responder, DNS64 is used to synthesize a
+   AAAA record from an A record containing a real IPv4 address of the
+   responder, whenever the DNS64 cannot retrieve a AAAA record for the
+   queried name.  The DNS64 service appears as a regular DNS server or
+   resolver to the IPv6 initiator.  The DNS64 receives a AAAA DNS query
+   generated by the IPv6 initiator.  It first attempts a resolution for
+   the requested AAAA records.  If there are no AAAA records available
+   for the target node (which is the normal case when the target node is
+   an IPv4-only node), DNS64 performs a query for A records.  For each A
+   record discovered, DNS64 creates a synthetic AAAA RR from the
+   information retrieved in the A RR.
+
+   The owner name of a synthetic AAAA RR is the same as that of the
+   original A RR, but an IPv6 representation of the IPv4 address
+   contained in the original A RR is included in the AAAA RR.  The IPv6
+   representation of the IPv4 address is algorithmically generated from
+   the IPv4 address and additional parameters configured in the DNS64.
+   Among those parameters configured in the DNS64, there is at least one
+   IPv6 prefix.  If not explicitly mentioned, all prefixes are treated
+   equally, and the operations described in this document are performed
+   using the prefixes available.  So as to be general, we will call any
+   of these prefixes Pref64::/n, and describe the operations made with
+   the generic prefix Pref64::/n.  The IPv6 addresses representing IPv4
+   addresses included in the AAAA RR synthesized by the DNS64 contain
+   Pref64::/n, and they also embed the original IPv4 address.
+
+   The same algorithm and the same Pref64::/n prefix(es) must be
+   configured both in the DNS64 device and the IPv6/IPv4 translator(s),
+   so that both can algorithmically generate the same IPv6
+   representation for a given IPv4 address.  In addition, it is required
+
+
+
+Bagnulo, et al.              Standards Track                    [Page 5]
+
+RFC 6147                          DNS64                       April 2011
+
+
+   that IPv6 packets addressed to an IPv6 destination address that
+   contains the Pref64::/n be delivered to an IPv6/IPv4 translator that
+   has that particular Pref64::/n configured, so they can be translated
+   into IPv4 packets.
+
+   Once the DNS64 has synthesized the AAAA RRs, the synthetic AAAA RRs
+   are passed back to the IPv6 initiator, which will initiate an IPv6
+   communication with the IPv6 address associated with the IPv4
+   receiver.  The packet will be routed to an IPv6/IPv4 translator,
+   which will forward it to the IPv4 network.
+
+   In general, the only shared state between the DNS64 and the IPv6/IPv4
+   translator is the Pref64::/n and an optional set of static
+   parameters.  The Pref64::/n and the set of static parameters must be
+   configured to be the same on both; there is no communication between
+   the DNS64 device and IPv6/IPv4 translator functions.  The mechanism
+   to be used for configuring the parameters of the DNS64 is beyond the
+   scope of this memo.
+
+   The prefixes to be used as Pref64::/n and their applicability are
+   discussed in [RFC6052].  There are two types of prefixes that can be
+   used as Pref64::/n.
+
+   o  The Pref64::/n can be the Well-Known Prefix 64:ff9b::/96 reserved
+      by [RFC6052] for the purpose of representing IPv4 addresses in
+      IPv6 address space.
+
+   o  The Pref64::/n can be a Network-Specific Prefix (NSP).  An NSP is
+      an IPv6 prefix assigned by an organization to create IPv6
+      representations of IPv4 addresses.
+
+   The main difference in the nature of the two types of prefixes is
+   that the NSP is a locally assigned prefix that is under control of
+   the organization that is providing the translation services, while
+   the Well-Known Prefix is a prefix that has a global meaning since it
+   has been assigned for the specific purpose of representing IPv4
+   addresses in IPv6 address space.
+
+   The DNS64 function can be performed in any of three places.  The
+   terms below are more formally defined in Section 4.
+
+   The first option is to locate the DNS64 function in authoritative
+   servers for a zone.  In this case, the authoritative server provides
+   synthetic AAAA RRs for an IPv4-only host in its zone.  This is one
+   type of DNS64 server.
+
+
+
+
+
+
+Bagnulo, et al.              Standards Track                    [Page 6]
+
+RFC 6147                          DNS64                       April 2011
+
+
+   Another option is to locate the DNS64 function in recursive name
+   servers serving end hosts.  In this case, when an IPv6-only host
+   queries the name server for AAAA RRs for an IPv4-only host, the name
+   server can perform the synthesis of AAAA RRs and pass them back to
+   the IPv6-only initiator.  The main advantage of this mode is that
+   current IPv6 nodes can use this mechanism without requiring any
+   modification.  This mode is called "DNS64 in DNS recursive-resolver
+   mode".  This is a second type of DNS64 server, and it is also one
+   type of DNS64 resolver.
+
+   The last option is to place the DNS64 function in the end hosts,
+   coupled to the local (stub) resolver.  In this case, the stub
+   resolver will try to obtain (real) AAAA RRs, and in case they are not
+   available, the DNS64 function will synthesize AAAA RRs for internal
+   usage.  This mode is compatible with some functions like DNSSEC
+   validation in the end host.  The main drawback of this mode is its
+   deployability, since it requires changes in the end hosts.  This mode
+   is called "DNS64 in stub-resolver mode".  This is the second type of
+   DNS64 resolver.
+
+3.  Background to DNS64-DNSSEC Interaction
+
+   DNSSEC ([RFC4033], [RFC4034], [RFC4035]) presents a special challenge
+   for DNS64, because DNSSEC is designed to detect changes to DNS
+   answers, and DNS64 may alter answers coming from an authoritative
+   server.
+
+   A recursive resolver can be security-aware or security-oblivious.
+   Moreover, a security-aware recursive resolver can be validating or
+   non-validating, according to operator policy.  In the cases below,
+   the recursive resolver is also performing DNS64, and has a local
+   policy to validate.  We call this general case vDNS64, but in all the
+   cases below, the DNS64 functionality should be assumed to be needed.
+
+   DNSSEC includes some signaling bits that offer some indicators of
+   what the query originator understands.
+
+   If a query arrives at a vDNS64 device with the "DNSSEC OK" (DO) bit
+   set, the query originator is signaling that it understands DNSSEC.
+   The DO bit does not indicate that the query originator will validate
+   the response.  It only means that the query originator can understand
+   responses containing DNSSEC data.  Conversely, if the DO bit is
+   clear, that is evidence that the querying agent is not aware of
+   DNSSEC.
+
+
+
+
+
+
+
+Bagnulo, et al.              Standards Track                    [Page 7]
+
+RFC 6147                          DNS64                       April 2011
+
+
+   If a query arrives at a vDNS64 device with the "Checking Disabled"
+   (CD) bit set, it is an indication that the querying agent wants all
+   the validation data so it can do checking itself.  By local policy,
+   vDNS64 could still validate, but it must return all data to the
+   querying agent anyway.
+
+   Here are the possible cases:
+
+   1.  A DNS64 (DNSSEC-aware or DNSSEC-oblivious) receives a query with
+       the DO bit clear.  In this case, DNSSEC is not a concern, because
+       the querying agent does not understand DNSSEC responses.  The
+       DNS64 can do validation of the response, if dictated by its local
+       policy.
+
+   2.  A security-oblivious DNS64 receives a query with the DO bit set,
+       and the CD bit clear or set.  This is just like the case of a
+       non-DNS64 case: the server doesn't support it, so the querying
+       agent is out of luck.
+
+   3.  A security-aware and non-validating DNS64 receives a query with
+       the DO bit set and the CD bit clear.  Such a resolver is not
+       validating responses, likely due to local policy (see [RFC4035],
+       Section 4.2).  For that reason, this case amounts to the same as
+       the previous case, and no validation happens.
+
+   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 DNS64 is
+       supposed to pass on all the data it gets to the query initiator
+       (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 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 resolver receives a query
+       with the DO bit clear and the CD bit clear.  In this case, the
+       resolver validates the data.  If it fails, it returns RCODE 2
+       (Server failure); otherwise, it returns the answer.  This is the
+       ideal case for vDNS64.  The resolver validates the data, and then
+       synthesizes the new record and passes that to the client.  The
+       client, which is presumably not validating (else it should have
+       set DO and CD), cannot tell that DNS64 is involved.
+
+   6.  A security-aware and validating DNS64 resolver receives a query
+       with the DO bit set and the CD bit clear.  This works like the
+       previous case, except that the resolver should also set the
+       "Authentic Data" (AD) bit on the response.
+
+
+
+
+Bagnulo, et al.              Standards Track                    [Page 8]
+
+RFC 6147                          DNS64                       April 2011
+
+
+   7.  A security-aware and validating DNS64 resolver receives a query
+       with the DO bit set and the CD bit 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.  The node needs to do
+       DNS64 itself, or else communication will fail.
+
+4.  Terminology
+
+   This section provides definitions for the special terms used in the
+   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 RFC 2119 [RFC2119].
+
+   Authoritative server:  A DNS server that can answer authoritatively a
+      given DNS request.
+
+   DNS64:  A logical function that synthesizes DNS resource records
+      (e.g., AAAA records containing IPv6 addresses) from DNS resource
+      records actually contained in the DNS (e.g., A records containing
+      IPv4 addresses).
+
+   DNS64 recursive resolver:  A recursive resolver that provides the
+      DNS64 functionality as part of its operation.  This is the same
+      thing as "DNS64 in recursive-resolver mode".
+
+   DNS64 resolver:  Any resolver (stub resolver or recursive resolver)
+      that provides the DNS64 function.
+
+   DNS64 server:  Any server providing the DNS64 function.  This
+      includes the server portion of a recursive resolver when it is
+      providing the DNS64 function.
+
+   IPv4-only server:  Servers running IPv4-only applications and servers
+      that can only use IPv4, as well as cases where only IPv4
+      connectivity is available to the server.
+
+   IPv6-only hosts:  Hosts running IPv6-only applications and hosts that
+      can only use IPv6, as well as cases where only IPv6 connectivity
+      is available to the client.
+
+
+
+
+
+
+
+
+Bagnulo, et al.              Standards Track                    [Page 9]
+
+RFC 6147                          DNS64                       April 2011
+
+
+   Recursive resolver:  A DNS server that accepts requests from one
+      resolver, and asks another server (of some description) for the
+      answer on behalf of the first resolver.  Full discussion of DNS
+      recursion is beyond the scope of this document; see [RFC1034] and
+      [RFC1035] for full details.
+
+   Synthetic RR:  A DNS resource record (RR) that is not contained in
+      the authoritative servers' zone data, but which is instead
+      synthesized from other RRs in the same zone.  An example is a
+      synthetic AAAA record created from an A record.
+
+   IPv6/IPv4 translator:  A device that translates IPv6 packets to IPv4
+      packets and vice versa.  It is only required that the
+      communication initiated from the IPv6 side be supported.
+
+   For a detailed understanding of this document, the reader should also
+   be familiar with DNS terminology from [RFC1034] and [RFC1035] and
+   with current NAT terminology from [RFC4787].  Some parts of this
+   document assume familiarity with the terminology of the DNS security
+   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.  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].
+
+   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].
+
+   DNS messages contain several sections.  The portion of a DNS message
+   that is altered by DNS64 is the answer section, which is discussed
+   below in Section 5.1.  The resulting synthetic answer is put together
+   with other sections, and that creates the message that is actually
+   returned as the response to the DNS query.  Assembling that response
+   is covered below in Section 5.4.
+
+   DNS64 also responds to PTR queries involving addresses containing any
+   of the IPv6 prefixes it uses for synthesis of AAAA RRs.
+
+
+
+
+Bagnulo, et al.              Standards Track                   [Page 10]
+
+RFC 6147                          DNS64                       April 2011
+
+
+5.1.  Resolving AAAA Queries and the Answer Section
+
+   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.  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.
+
+5.1.1.  The Answer when There is AAAA Data Available
+
+   If the query results in one or more AAAA records in the answer
+   section, the result is returned to the requesting client as per
+   normal DNS semantics, except in the case where any of the AAAA
+   records match a special exclusion set of prefixes, as considered in
+   Section 5.1.4.  If there is (non-excluded) AAAA data available, DNS64
+   SHOULD NOT include synthetic AAAA RRs in the response (see Appendix A
+   for an analysis of the motivations for and the implications of not
+   complying with this recommendation).  By default, DNS64
+   implementations MUST NOT synthesize AAAA RRs when real AAAA RRs
+   exist.
+
+5.1.2.  The Answer when There is an Error
+
+   If the query results in a response with an RCODE other than 0 (No
+   error condition), then there are two possibilities.  A result with
+   RCODE=3 (Name Error) is handled according to normal DNS operation
+   (which is normally to return the error to the client).  This stage is
+   still prior to any synthesis having happened, so a response to be
+   returned to the client does not need any special assembly other than
+   what would usually happen in DNS operation.
+
+   Any other RCODE is treated as though the RCODE were 0 (see
+   Sections 5.1.6 and 5.1.7) 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 (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.
+
+   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.
+
+
+
+
+
+Bagnulo, et al.              Standards Track                   [Page 11]
+
+RFC 6147                          DNS64                       April 2011
+
+
+5.1.3.  Dealing with Timeouts
+
+   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
+
+   Some IPv6 addresses are not actually usable by IPv6-only hosts.  If
+   they are returned to IPv6-only querying agents as AAAA records,
+   therefore, the goal of decreasing the number of failure modes will
+   not be attained.  Examples include AAAA records with addresses in the
+   ::ffff:0:0/96 network, and possibly (depending on the context) AAAA
+   records with the site's Pref64::/n or the Well-Known Prefix (see
+   below for more about the Well-Known Prefix).  A DNS64 implementation
+   SHOULD provide a mechanism to specify IPv6 prefix ranges to be
+   treated as though the AAAA containing them were an empty answer.  An
+   implementation SHOULD include the ::ffff/96 network in that range by
+   default.  Failure to provide this facility will mean that clients
+   querying the DNS64 function may not be able to communicate with hosts
+   that would be reachable from a dual-stack host.
+
+   When the DNS64 performs its initial AAAA query, if it receives an
+   answer with only AAAA records containing addresses in the excluded
+   range(s), then it MUST treat the answer as though it were an empty
+   answer, and proceed accordingly.  If it receives an answer with at
+   least one AAAA record containing an address outside any of the
+   excluded range(s), then it by default SHOULD build an answer section
+   for a response including only the AAAA record(s) that do not contain
+   any of the addresses inside the excluded ranges.  That answer section
+   is used in the assembly of a response as detailed in Section 5.4.
+   Alternatively, it MAY treat the answer as though it were an empty
+   answer, and proceed accordingly.  It MUST NOT return the offending
+   AAAA records as part of a response.
+
+5.1.5.  Dealing with CNAME and DNAME
+
+   If the response contains a CNAME or a DNAME, then the CNAME or DNAME
+   chain is followed until the first terminating A or AAAA record is
+   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.              Standards Track                   [Page 12]
+
+RFC 6147                          DNS64                       April 2011
+
+
+5.1.6.  Data for the Answer when Performing Synthesis
+
+   If the query results in no error but an empty answer section in the
+   response, the DNS64 attempts to retrieve A records for the name in
+   question, either by performing another query or, in the case of an
+   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.  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
+
+   A synthetic AAAA record is created from an A record as follows:
+
+   o  The NAME field is set to the NAME field from the A record.
+
+   o  The TYPE field is set to 28 (AAAA).
+
+   o  The CLASS field is set to the original CLASS field, 1.  Under this
+      specification, DNS64 for any CLASS other than 1 is undefined.
+
+   o  The Time to Live (TTL) field is set to the minimum of the TTL of
+      the original A RR and the SOA RR for the queried domain.  (Note
+      that in order to obtain the TTL of the SOA RR, the DNS64 does not
+      need to perform a new query, but it can remember the TTL from the
+      SOA RR in the negative response to the AAAA query.  If the SOA RR
+      was not delivered with the negative response to the AAAA query,
+      then the DNS64 SHOULD use the TTL of the original A RR or
+      600 seconds, whichever is shorter.  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.)  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 MUST
+      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.              Standards Track                   [Page 13]
+
+RFC 6147                          DNS64                       April 2011
+
+
+5.1.8.  Querying in Parallel
+
+   The DNS64 MAY perform the query for the AAAA RR and for the A RR in
+   parallel, in order to minimize the delay.
+
+      NOTE: Querying in parallel will result in performing unnecessary A
+      RR queries in the case where no AAAA RR synthesis is required.  A
+      possible trade-off would be to perform them sequentially but with
+      a very short interval between them, so if we obtain a fast reply,
+      we avoid doing the additional query.  (Note that this discussion
+      is relevant only if the DNS64 function needs to perform external
+      queries to fetch the RR.  If the needed RR information is
+      available locally, as in the case of an authoritative server, the
+      issue is no longer relevant.)
+
+5.2.  Generation of the IPv6 Representations of IPv4 Addresses
+
+   DNS64 supports multiple algorithms for the generation of the IPv6
+   representation of an IPv4 address.  The constraints imposed on the
+   generation algorithms are the following:
+
+   o  The same algorithm to create an IPv6 address from an IPv4 address
+      MUST be used by both a DNS64 to create the IPv6 address to be
+      returned in the synthetic AAAA RR from the IPv4 address contained
+      in an original A RR, and by an IPv6/IPv4 translator to create the
+      IPv6 address to be included in the source address field of the
+      outgoing IPv6 packets from the IPv4 address included in the source
+      address field of the incoming IPv4 packet.
+
+   o  The algorithm MUST be reversible; i.e., it MUST be possible to
+      derive the original IPv4 address from the IPv6 representation.
+
+   o  The input for the algorithm MUST be limited to the IPv4 address;
+      the IPv6 prefix (denoted Pref64::/n) used in the IPv6
+      representations; and, optionally, a set of stable parameters that
+      are configured in the DNS64 and in the NAT64 (such as a fixed
+      string to be used as a suffix).
+
+      *  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 manual configuration, 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 [RFC6052] to
+         represent the IPv4 unicast address range.
+
+
+
+
+
+Bagnulo, et al.              Standards Track                   [Page 14]
+
+RFC 6147                          DNS64                       April 2011
+
+
+   A DNS64 MUST support the algorithm for generating IPv6
+   representations of IPv4 addresses defined in Section 2 of [RFC6052].
+   Moreover, the aforementioned algorithm MUST be the default algorithm
+   used by the DNS64.  While the normative description of the algorithm
+   is provided in [RFC6052], a sample description of the algorithm and
+   its application to different scenarios are provided in Section 7 for
+   illustration purposes.
+
+5.3.  Handling Other Resource Records and the Additional Section
+
+5.3.1.  PTR Resource Record
+
+   If a DNS64 server receives a PTR query for a record in the IP6.ARPA
+   domain, it MUST strip the IP6.ARPA labels from the QNAME, reverse the
+   address portion of the QNAME according to the encoding scheme
+   outlined in Section 2.5 of [RFC3596], and examine the resulting
+   address to see whether its prefix matches any of the locally
+   configured Pref64::/n or the default Well-Known Prefix.  There are
+   two alternatives for a DNS64 server to respond to such PTR queries.
+   A DNS64 server MUST provide one of these, and SHOULD NOT provide both
+   at the same time unless different IP6.ARPA zones require answers of
+   different sorts:
+
+   1.  The first option is for the DNS64 server to respond
+       authoritatively for its prefixes.  If the address prefix matches
+       any Pref64::/n used in the site, either a NSP or the Well-Known
+       Prefix (i.e., 64:ff9b::/96), then the DNS64 server MAY answer the
+       query using locally appropriate RDATA.  The DNS64 server MAY use
+       the same RDATA for all answers.  Note that the requirement is to
+       match any Pref64::/n used at the site, and not merely the locally
+       configured Pref64::/n.  This is because end clients could ask for
+       a PTR record matching an address received through a different
+       (site-provided) DNS64, and if this strategy is in effect, those
+       queries should never be sent to the global DNS.  The advantage of
+       this strategy is that it makes plain to the querying client that
+       the prefix is one operated by the (DNS64) site, and that the
+       answers the client is getting are generated by DNS64.  The
+       disadvantage is that any useful reverse-tree information that
+       might be in the global DNS is unavailable to the clients querying
+       the DNS64.
+
+   2.  The second option is for the DNS64 name server to synthesize a
+       CNAME mapping the IP6.ARPA namespace to the corresponding
+       IN-ADDR.ARPA name.  In this case, the DNS64 name server SHOULD
+       ensure that there is RDATA at the PTR of the corresponding
+       IN-ADDR.ARPA name, and that there is not an existing CNAME at
+       that name.  This is in order to avoid synthesizing a CNAME that
+       makes a CNAME chain longer or that does not actually point to
+
+
+
+Bagnulo, et al.              Standards Track                   [Page 15]
+
+RFC 6147                          DNS64                       April 2011
+
+
+       anything.  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
+       disadvantages are that it adds additional load to the DNS64
+       (because CNAMEs have to be synthesized for each PTR query that
+       matches the Pref64::/n), and that it may require signing on
+       the fly.
+
+   If the address prefix does not match any Pref64::/n, then the DNS64
+   server MUST process the query as though it were any other query;
+   i.e., a recursive name server MUST attempt to resolve the query as
+   though it were any other (non-A/AAAA) query, and an authoritative
+   server MUST respond authoritatively or with a referral, as
+   appropriate.
+
+5.3.2.  Handling the Additional Section
+
+   DNS64 synthesis MUST NOT be performed on any records in the
+   additional section of synthesized answers.  The DNS64 MUST pass the
+   additional section unchanged.
+
+      NOTE: It may appear that adding synthetic records to the
+      additional section is desirable, because clients sometimes use the
+      data in the additional section to proceed without having to
+      re-query.  There is in general no promise, however, that the
+      additional section will contain all the relevant records, so any
+      client that depends on the additional section being able to
+      satisfy its needs (i.e., without additional queries) is
+      necessarily broken.  An IPv6-only client that needs a AAAA record,
+      therefore, will send a query for the necessary AAAA record if it
+      is unable to find such a record in the additional section of an
+      answer it is consuming.  For a correctly functioning client, the
+      effect would be no different if the additional section were empty.
+      The alternative of removing the A records in the additional
+      section and replacing them with synthetic AAAA records may cause a
+      host behind a NAT64 to query directly a name server that is
+      unaware of the NAT64 in question.  The result in this case will be
+      resolution failure anyway, but later in the resolution operation.
+      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.
+
+
+
+
+
+
+
+
+Bagnulo, et al.              Standards Track                   [Page 16]
+
+RFC 6147                          DNS64                       April 2011
+
+
+5.3.3.  Other Resource Records
+
+   If the DNS64 is in recursive-resolver mode, then considerations
+   outlined in [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
+
+   A DNS64 uses different pieces of data to build the response returned
+   to the querying client.
+
+   The query that is used as the basis for synthesis results either in
+   an error, an answer that can be used as a basis for synthesis, or an
+   empty (authoritative) answer.  If there is an empty answer, then the
+   DNS64 responds to the original querying client with the answer the
+   DNS64 received to the original (initiator's) query.  Otherwise, the
+   response is assembled as follows.
+
+   The header fields are set according to the usual rules for recursive
+   or authoritative servers, depending on the role that the DNS64 is
+   serving.  The question section is copied from the original
+   (initiator's) query.  The answer section is populated according to
+   the rules in Section 5.1.7.  The authority and additional sections
+   are copied from the response to the final query that the DNS64
+   performed, and used as the basis for synthesis.
+
+   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 Validating Resolver Mode
+
+   We consider the case where a recursive resolver that is performing
+   DNS64 also has a local policy to validate the answers according to
+   the procedures outlined in [RFC4035], Section 5.  We call this
+   general case vDNS64.
+
+   The vDNS64 uses the presence of the DO and CD bits to make some
+   decisions about what the query originator needs, and can react
+   accordingly:
+
+   1.  If CD is not set and DO is not set, vDNS64 SHOULD perform
+       validation and do synthesis as needed.  See the next item for
+       rules about how to do validation and synthesis.  In this case,
+       however, vDNS64 MUST NOT set the AD bit in any response.
+
+
+
+
+
+Bagnulo, et al.              Standards Track                   [Page 17]
+
+RFC 6147                          DNS64                       April 2011
+
+
+   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
+       to query for A records for the same name, in order to be sure
+       that there is not a legitimate AAAA record on the Internet.
+       Failing to observe this step would allow an attacker to use DNS64
+       as a mechanism to circumvent DNSSEC.  If the negative response
+       validates, and the response to the A query validates, then the
+       vDNS64 MAY perform synthesis and SHOULD set the AD bit in the
+       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
+       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
+       bit.  If the data does not validate, the vDNS64 MUST respond with
+       RCODE=2 (Server failure).
+
+       A security-aware end point might take the presence of the AD bit
+       as an indication that the data is valid, and may pass the DNS
+       (and DNSSEC) data to an application.  If the application attempts
+       to validate the synthesized data, of course, the validation will
+       fail.  One could argue therefore that this approach is not
+       desirable, but security-aware stub resolvers must not place any
+       reliance on data received from resolvers and validated on their
+       behalf without certain criteria established by [RFC4035],
+       Section 4.9.3.  An application that wants to perform validation
+       on its own should use the CD bit.
+
+   3.  If the CD bit is set and DO is set, then vDNS64 MAY perform
+       validation, but MUST NOT perform synthesis.  It MUST return the
+       data to the query initiator, just like a regular recursive
+       resolver, and depend on the client to do the validation and the
+       synthesis itself.
+
+       The disadvantage to this approach is that an end point that is
+       translation-oblivious but security-aware and validating will not
+       be able to use the DNS64 functionality.  In this case, the end
+       point will not have the desired benefit of NAT64.  In effect,
+       this strategy means that any end point that wishes to do
+       validation in a NAT64 context must be upgraded to be
+       translation-aware as well.
+
+
+
+
+
+
+
+
+
+Bagnulo, et al.              Standards Track                   [Page 18]
+
+RFC 6147                          DNS64                       April 2011
+
+
+6.  Deployment Notes
+
+   While DNS64 is intended to be part of a strategy for aiding IPv6
+   deployment in an internetworking environment with some IPv4-only and
+   IPv6-only networks, it is important to realize that it is
+   incompatible with some things that may be deployed in an IPv4-only or
+   dual-stack context.
+
+6.1.  DNS Resolvers and DNS64
+
+   Full-service resolvers that are unaware of the DNS64 function can be
+   (mis)configured to act as mixed-mode iterative and forwarding
+   resolvers.  In a native IPv4 context, this sort of configuration may
+   appear to work.  It is impossible to make it work properly without it
+   being aware of the DNS64 function, because it will likely at some
+   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
+   will be unable to answer the necessary AAAA queries.
+
+6.2.  DNSSEC Validators and DNS64
+
+   An existing DNSSEC validator (i.e., one 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 to perform the DNS64 function itself.  Alternatively,
+   the validating host may establish a trusted connection with a DNS64,
+   and allow the DNS64 recursive resolver to do all validation on its
+   behalf.
+
+6.3.  DNS64 and Multihomed and Dual-Stack Hosts
+
+6.3.1.  IPv6 Multihomed Hosts
+
+   Synthetic AAAA records may be constructed on the basis of the network
+   context in which they were constructed.  If a host sends DNS queries
+   to resolvers in multiple networks, it is possible that some of them
+   will receive answers from a DNS64 without all of them being connected
+   via a NAT64.  For instance, suppose a system has two interfaces, i1
+   and i2.  Whereas i1 is connected to the IPv4 Internet via NAT64, i2
+   has native IPv6 connectivity only.  I1 might receive a AAAA answer
+   from a DNS64 that is configured for a particular NAT64; the IPv6
+   address contained in that AAAA answer will not connect with anything
+   via i2.
+
+
+
+
+
+
+Bagnulo, et al.              Standards Track                   [Page 19]
+
+RFC 6147                          DNS64                       April 2011
+
+
+             +---------------+                 +-------------+
+             |      i1 (IPv6)+----NAT64--------+IPv4 Internet|
+             |               |                 +-------------+
+             | host          |
+             |               |                 +-------------+
+             |      i2 (IPv6)+-----------------+IPv6 Internet|
+             +---------------+                 +-------------+
+
+                     Figure 1:  IPv6 Multihomed Hosts
+
+   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.
+
+   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.
+
+6.3.2.  Accidental Dual-Stack DNS64 Use
+
+   Similarly, suppose that i1 has IPv6 connectivity and can connect to
+   the IPv4 Internet through NAT64, but i2 has native IPv4 connectivity.
+   In this case, i1 could receive an IPv6 address from a synthetic AAAA
+   that would better be reached via native IPv4.  Again, it is worth
+   emphasizing that this arises because there are two networks involved.
+
+             +---------------+                 +-------------+
+             |      i1 (IPv6)+----NAT64--------+IPv4 Internet|
+             |               |                 +-------------+
+             | host          |
+             |               |                 +-------------+
+             |      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
+   this reason, hosts with IPv4 connectivity to the Internet should
+   avoid using DNS64.  This can be partly resolved by ISPs when
+   providing DNS resolvers to clients, but that is not a guarantee that
+
+
+
+
+
+
+
+Bagnulo, et al.              Standards Track                   [Page 20]
+
+RFC 6147                          DNS64                       April 2011
+
+
+   the NAT64 will never be used when a native IPv4 connection should be
+   used.  There is no general-purpose mechanism to ensure that native
+   IPv4 transit will always be preferred, because to a DNS64-oblivious
+   host, the DNS64 looks just like an ordinary DNS server.  Operators of
+   a NAT64 should expect traffic to pass through the NAT64 even when it
+   is not necessary.
+
+6.3.3.  Intentional Dual-Stack DNS64 Use
+
+   Finally, consider the case where the IPv4 connectivity on i2 is only
+   with a LAN, and not with the IPv4 Internet.  The IPv4 Internet is
+   only accessible using the NAT64.  In this case, it is critical that
+   the DNS64 not synthesize AAAA responses for hosts in the LAN, or else
+   that the DNS64 be aware of hosts in the LAN and provide context-
+   sensitive answers ("split view" DNS answers) for hosts inside the
+   LAN.  As with any split view DNS arrangement, operators must be
+   prepared for data to leak from one context to another, and for
+   failures to occur because nodes accessible from one context are not
+   accessible from the other.
+
+             +---------------+                 +-------------+
+             |      i1 (IPv6)+----NAT64--------+IPv4 Internet|
+             |               |                 +-------------+
+             | host          |
+             |               |
+             |      i2 (IPv4)+---(local LAN only)
+             +---------------+
+
+                Figure 3:  Intentional Dual-Stack DNS64 Use
+
+   It is important for deployers of DNS64 to realize 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
+   native IPv4, with the associated loss of performance or functionality
+   (or both) entailed by the NAT.  At the same time, some hosts are not
+   able to learn about DNS servers provisioned on IPv6 addresses, or
+   simply cannot send DNS packets over IPv6.
+
+7.  Deployment Scenarios and Examples
+
+   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 [RFC6144]: the "an IPv6
+   network to the 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).
+
+
+
+
+
+Bagnulo, et al.              Standards Track                   [Page 21]
+
+RFC 6147                          DNS64                       April 2011
+
+
+   In all the examples below, there is an 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.
+
+7.1.  Example of "an IPv6 Network to the IPv4 Internet" Setup with DNS64
+      in DNS Server Mode
+
+   In this example, we consider an IPv6 node located in an IPv6-only
+   site that initiates a communication to an IPv4 node located in the
+   IPv4 Internet.
+
+   The scenario for this case is depicted in the following figure:
+
+             +---------------------+         +---------------+
+             |IPv6 network         |         |    IPv4       |
+             |           |  +-------------+  |  Internet     |
+             |           |--| Name server |--|               |
+             |           |  | with DNS64  |  |  +----+       |
+             |  +----+   |  +-------------+  |  | H2 |       |
+             |  | H1 |---|         |         |  +----+       |
+             |  +----+   |   +------------+  |  192.0.2.1    |
+             |           |---| IPv6/IPv4  |--|               |
+             |           |   | Translator |  |               |
+             |           |   +------------+  |               |
+             |           |         |         |               |
+             +---------------------+         +---------------+
+
+          Figure 4:  "An IPv6 Network to the IPv4 Internet" Setup
+                       with DNS64 in DNS Server Mode
+
+   The figure shows an IPv6 node H1 and an IPv4 node H2 with the IPv4
+   address 192.0.2.1 and FQDN h2.example.com.
+
+   The IPv6/IPv4 translator has an IPv4 address 203.0.113.1 assigned
+   to its IPv4 interface, and it is using the Well-Known Prefix
+   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
+   of a name server that they always have to query and that performs
+   recursive lookups (henceforth called "the recursive name server").
+
+
+
+
+Bagnulo, et al.              Standards Track                   [Page 22]
+
+RFC 6147                          DNS64                       April 2011
+
+
+   The steps by which H1 establishes communication with H2 are:
+
+   1.  H1 does a DNS lookup for h2.example.com.  H1 does this by sending
+       a DNS query for a AAAA record for H2 to the recursive name
+       server.  The recursive name server implements DNS64
+       functionality.
+
+   2.  The recursive name server resolves the query, and discovers that
+       there are no AAAA records for H2.
+
+   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::
+       192.0.2.1.
+
+   5.  The packet is routed to the IPv6 interface of the IPv6/IPv4
+       translator, and the subsequent communication flows by means of
+       the IPv6/IPv4 translator mechanisms.
+
+7.2.  Example of "an IPv6 Network to the IPv4 Internet" Setup with DNS64
+      in Stub-Resolver Mode
+
+   This case is depicted in the following figure:
+
+             +---------------------+         +---------------+
+             |IPv6 network         |         |    IPv4       |
+             |           |     +--------+    |  Internet     |
+             |           |-----| Name   |----|               |
+             | +-----+   |     | server |    |  +----+       |
+             | | H1  |   |     +--------+    |  | H2 |       |
+             | |with |---|         |         |  +----+       |
+             | |DNS64|   |   +------------+  |  192.0.2.1    |
+             | +----+    |---| IPv6/IPv4  |--|               |
+             |           |   | Translator |  |               |
+             |           |   +------------+  |               |
+             |           |         |         |               |
+             +---------------------+         +---------------+
+
+          Figure 5:  "An IPv6 Network to the IPv4 Internet" Setup
+                       with DNS64 in Stub-Resolver Mode
+
+
+
+
+Bagnulo, et al.              Standards Track                   [Page 23]
+
+RFC 6147                          DNS64                       April 2011
+
+
+   The figure shows an IPv6 node H1 implementing the DNS64 function and
+   an IPv4 node H2 with the IPv4 address 192.0.2.1 and FQDN
+   h2.example.com.
+
+   The IPv6/IPv4 translator has an IPv4 address 203.0.113.1 assigned
+   to its IPv4 interface, and it is using the Well-Known Prefix
+   64:ff9b::/96 to create IPv6 representations of IPv4 addresses.  The
+   same prefix is configured in the DNS64 function in H1.
+
+   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 name server").
+   The recursive name server does not perform the DNS64 function.
+
+   The steps by which H1 establishes communication with H2 are:
+
+   1.  H1 does a DNS lookup for h2.example.com.  H1 does this by sending
+       a DNS query for a AAAA record for H2 to the recursive name
+       server.
+
+   2.  The recursive DNS server resolves the query, and returns the
+       answer to H1.  Because there are no AAAA records in the global
+       DNS for H2, the answer is empty.
+
+   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
+       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 in the lower 32 bits; the resulting IPv6 address is
+       64:ff9b::192.0.2.1.
+
+   4.  H1 sends a packet towards H2.  The packet is sent to the
+       destination address 64:ff9b::192.0.2.1.
+
+   5.  The packet is routed to the IPv6 interface of the IPv6/IPv4
+       translator and the subsequent communication flows using the IPv6/
+       IPv4 translator mechanisms.
+
+7.3.  Example of "the IPv6 Internet to an IPv4 Network" Setup with DNS64
+      in DNS Server Mode
+
+   In this example, we consider an IPv6 node located in the IPv6
+   Internet that initiates a communication to an IPv4 node located in
+   the IPv4 site.
+
+
+
+
+
+Bagnulo, et al.              Standards Track                   [Page 24]
+
+RFC 6147                          DNS64                       April 2011
+
+
+   In some cases, this scenario can be addressed without using any form
+   of DNS64 function.  This is 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
+   [RFC6052] 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 [RFC6052]).  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
+   [RFC2136] is used in the IPv4 site to update the A RRs for the IPv4
+   nodes, there are two options.  One option is to modify the DNS server
+   that receives the dynamic DNS updates.  That would normally be the
+   authoritative server for the zone.  So the authoritative zone would
+   have normal AAAA RRs that are synthesized as dynamic updates occur.
+   The other option is to modify all of the authoritative servers to
+   generate synthetic AAAA records for a zone, possibly based on
+   additional 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 a 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.
+
+
+
+
+
+
+
+
+
+
+
+
+Bagnulo, et al.              Standards Track                   [Page 25]
+
+RFC 6147                          DNS64                       April 2011
+
+
+   The scenario for this case is depicted in the following figure:
+
+              +-----------+          +----------------------+
+              |           |          |   IPv4 site          |
+              |   IPv6    |    +------------+  |   +----+   |
+              | Internet  |----| IPv6/IPv4  |--|---| H2 |   |
+              |           |    | Translator |  |   +----+   |
+              |           |    +------------+  |            |
+              |           |          |         | 192.0.2.1  |
+              |           |    +------------+  |            |
+              |           |----| Name server|--|            |
+              |           |    | with DNS64 |  |            |
+              +-----------+    +------------+  |            |
+                |                    |         |            |
+              +----+                 |                      |
+              | H1 |                 +----------------------+
+              +----+
+
+          Figure 6:  "The IPv6 Internet to an IPv4 Network" Setup
+                       with DNS64 in DNS Server Mode
+
+   The figure shows an IPv6 node H1 and an IPv4 node H2 with the IPv4
+   address 192.0.2.1 and FQDN h2.example.com.
+
+   The IPv6/IPv4 translator is using an 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:
+
+   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.
+
+   2.  The local DNS server resolves the query (locally), and discovers
+       that there are no AAAA records for H2.
+
+   3.  The name server verifies that h2.example.com and its A RR are
+       among those that the local policy defines as allowed to generate
+       a AAAA RR.  If that is the case, the name server synthesizes a
+       AAAA record from the A RR and the prefix 2001:db8::/96.  The IPv6
+       address in the AAAA record is 2001:db8::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 2001:db8::
+       192.0.2.1.
+
+
+
+Bagnulo, et al.              Standards Track                   [Page 26]
+
+RFC 6147                          DNS64                       April 2011
+
+
+   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.
+
+8.  Security Considerations
+
+   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 modifies DNS answers, and DNSSEC is designed to detect
+   such modifications and to treat modified answers as bogus.  See the
+   discussion above in Sections 3, 5.5, and 6.2.
+
+   Additionally, for the correct functioning of the translation
+   services, the DNS64 and the NAT64 need to use the same Pref64.  If an
+   attacker manages to change the Pref64 used by the DNS64, the traffic
+   generated by the host that receives the synthetic reply will be
+   delivered to the altered Pref64.  This can result in either a denial-
+   of-service (DoS) attack (if the resulting IPv6 addresses are not
+   assigned to any device), a flooding attack (if the resulting IPv6
+   addresses are assigned to devices that do not wish to receive the
+   traffic), or an eavesdropping attack (in case the Pref64 is routed
+   through the attacker).
+
+9.  Contributors
+
+   Dave Thaler
+   Microsoft
+   dthaler@windows.microsoft.com
+
+10.  Acknowledgements
+
+   This document contains the result of discussions involving many
+   people, including the participants of the IETF BEHAVE Working Group.
+   The following IETF participants made specific contributions to parts
+   of the text, and their help is gratefully acknowledged: Jaap
+   Akkerhuis, Mark Andrews, Jari Arkko, Rob Austein, Timothy Baldwin,
+   Fred Baker, Doug Barton, Marc Blanchet, Cameron Byrne, Brian
+   Carpenter, Zhen Cao, Hui Deng, Francis Dupont, Patrik Faltstrom,
+   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, and Xiangsong Cui.
+
+
+
+
+Bagnulo, et al.              Standards Track                   [Page 27]
+
+RFC 6147                          DNS64                       April 2011
+
+
+   Marcelo Bagnulo and Iljitsch van Beijnum are partly funded by
+   Trilogy, a research project supported by the European Commission
+   under its Seventh Framework Program.
+
+11.  References
+
+11.1.  Normative References
+
+   [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.
+
+   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
+              RFC 2671, August 1999.
+
+   [RFC4787]  Audet, F. and C. Jennings, "Network Address Translation
+              (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
+              RFC 4787, January 2007.
+
+   [RFC6052]  Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
+              Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
+              October 2010.
+
+11.2.  Informative References
+
+   [DEFAULT-LOCAL-ZONES]
+              Andrews, M., "Locally-served DNS Zones", Work in Progress,
+              March 2011.
+
+   [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.
+
+   [RFC3596]  Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
+              "DNS Extensions to Support IP Version 6", RFC 3596,
+              October 2003.
+
+
+
+
+Bagnulo, et al.              Standards Track                   [Page 28]
+
+RFC 6147                          DNS64                       April 2011
+
+
+   [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.
+
+   [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.
+
+   [RFC6144]  Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
+              IPv4/IPv6 Translation", RFC 6144, April 2011.
+
+   [RFC6146]  Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
+              NAT64: Network Address and Protocol Translation from IPv6
+              Clients to IPv4 Servers", RFC 6146, April 2011.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bagnulo, et al.              Standards Track                   [Page 29]
+
+RFC 6147                          DNS64                       April 2011
+
+
+Appendix A.  Motivations and Implications of Synthesizing AAAA Resource
+             Records when Real AAAA Resource Records Exist
+
+   The motivation for synthesizing AAAA RRs when real AAAA RRs exist is
+   to support the following scenario:
+
+   o  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 running on the same host.  That host has fully
+      routable IPv4 and IPv6 addresses, and hence the authoritative DNS
+      server has an A record and a AAAA record.
+
+   o  An IPv6-only client (regardless of whether the client application
+      is IPv6-only, the client stack is IPv6-only, or it only has an
+      IPv6 address) wants to access the above server.
+
+   o  The client issues a DNS query to a DNS64 resolver.
+
+   If the DNS64 only generates a synthetic AAAA if there's no real AAAA,
+   then the communication will fail.  Even though there's a real AAAA,
+   the only way for communication to succeed is with the translated
+   address.  So, in order to support this scenario, the administrator of
+   a DNS64 service may want to enable the synthesis of AAAA RRs even
+   when real AAAA RRs exist.
+
+   The implication of including synthetic AAAA RRs when real AAAA RRs
+   exist is that translated connectivity may be preferred over native
+   connectivity in some cases where the DNS64 is operated in DNS server
+   mode.
+
+   RFC 3484 [RFC3484] rules use "longest matching prefix" to select the
+   preferred destination address to use.  So, if the DNS64 resolver
+   returns both the synthetic AAAA RRs and the real AAAA RRs, then if
+   the DNS64 is operated by the same domain as the initiating host, and
+   a global unicast prefix (referred to as a Network-Specific Prefix
+   (NSP) in [RFC6052]) is used, then a synthetic AAAA RR is likely to be
+   preferred.
+
+   This means that without further configuration:
+
+   o  In the "an IPv6 network to the IPv4 Internet" scenario, the host
+      will prefer translated connectivity if an NSP is used.  If the
+      Well-Known Prefix defined in [RFC6052] is used, it will probably
+      prefer native connectivity.
+
+
+
+
+
+
+
+Bagnulo, et al.              Standards Track                   [Page 30]
+
+RFC 6147                          DNS64                       April 2011
+
+
+   o  In the "IPv6 Internet to an IPv4 network" scenario, it is possible
+      to bias the selection towards the real AAAA RR if the DNS64
+      resolver returns the real AAAA first in the DNS reply, when an NSP
+      is used (the Well-Known Prefix usage is not supported in this
+      case).
+
+   o  In the "an IPv6 network to an IPv4 network" scenario, for local
+      destinations (i.e., target hosts inside the local site), it is
+      likely that the NSP and the destination prefix are the same, so we
+      can use the order of RR in the DNS reply to bias the selection
+      through native connectivity.  If the Well-Known Prefix is used,
+      the "longest matching prefix" rule will select native
+      connectivity.
+
+   The problem can be solved by properly configuring the RFC 3484
+   [RFC3484] policy table.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bagnulo, et al.              Standards Track                   [Page 31]
+
+RFC 6147                          DNS64                       April 2011
+
+
+Authors' Addresses
+
+   Marcelo Bagnulo
+   UC3M
+   Av. Universidad 30
+   Leganes, Madrid  28911
+   Spain
+
+   Phone: +34-91-6249500
+   EMail: marcelo@it.uc3m.es
+   URI:   http://www.it.uc3m.es/marcelo
+
+
+   Andrew Sullivan
+   Shinkuro
+   4922 Fairmont Avenue, Suite 250
+   Bethesda, MD  20814
+   USA
+
+   Phone: +1 301 961 3131
+   EMail: ajs@shinkuro.com
+
+
+   Philip Matthews
+   Unaffiliated
+   600 March Road
+   Ottawa, Ontario
+   Canada
+
+   Phone: +1 613-592-4343 x224
+   EMail: philip_matthews@magma.ca
+
+
+   Iljitsch van Beijnum
+   IMDEA Networks
+   Avda. del Mar Mediterraneo, 22
+   Leganes, Madrid  28918
+   Spain
+
+   Phone: +34-91-6246245
+   EMail: iljitsch@muada.com
+
+
+
+
+
+
+
+
+
+
+Bagnulo, et al.              Standards Track                   [Page 32]
+
diff --git a/doc/rfc/rfc6168.txt b/doc/rfc/rfc6168.txt
new file mode 100644
index 0000000000..eb6a25c9a2
--- /dev/null
+++ b/doc/rfc/rfc6168.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                       W. Hardaker
+Request for Comments: 6168                                  Sparta, Inc.
+Category: Informational                                         May 2011
+ISSN: 2070-1721
+
+
+        Requirements for Management of Name Servers for the DNS
+
+Abstract
+
+   Management of name servers for the Domain Name System (DNS) has
+   traditionally been done using vendor-specific monitoring,
+   configuration, and control methods.  Although some service monitoring
+   platforms can test the functionality of the DNS itself, there is not
+   an interoperable way to manage (monitor, control, and configure) the
+   internal aspects of a name server itself.
+
+   This document discusses the requirements of a management system for
+   name servers and can be used as a shopping list of needed features
+   for such a system.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6168.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hardaker                      Informational                     [Page 1]
+
+RFC 6168           Name Server Management Requirements          May 2011
+
+
+Copyright Notice
+
+   Copyright (c) 2011 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.
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hardaker                      Informational                     [Page 2]
+
+RFC 6168           Name Server Management Requirements          May 2011
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
+     1.1.  Requirements Notation  . . . . . . . . . . . . . . . . . .  4
+     1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5
+     1.3.  Document Layout and Requirements . . . . . . . . . . . . .  5
+   2.  Management Architecture Requirements . . . . . . . . . . . . .  5
+     2.1.  Expected Deployment Scenarios  . . . . . . . . . . . . . .  5
+       2.1.1.  Zone Size Constraints  . . . . . . . . . . . . . . . .  6
+       2.1.2.  Name Server Discovery  . . . . . . . . . . . . . . . .  6
+       2.1.3.  Configuration Data Volatility  . . . . . . . . . . . .  6
+       2.1.4.  Protocol Selection . . . . . . . . . . . . . . . . . .  6
+       2.1.5.  Common Data Model  . . . . . . . . . . . . . . . . . .  6
+       2.1.6.  Operational Impact . . . . . . . . . . . . . . . . . .  7
+     2.2.  Name Server Types  . . . . . . . . . . . . . . . . . . . .  7
+   3.  Management Operation Types . . . . . . . . . . . . . . . . . .  7
+     3.1.  Control Requirements . . . . . . . . . . . . . . . . . . .  8
+       3.1.1.  Needed Control Operations  . . . . . . . . . . . . . .  8
+       3.1.2.  Asynchronous Status Notifications  . . . . . . . . . .  8
+     3.2.  Configuration Requirements . . . . . . . . . . . . . . . .  9
+       3.2.1.  Served Zone Modification . . . . . . . . . . . . . . .  9
+       3.2.2.  Trust Anchor Management  . . . . . . . . . . . . . . .  9
+       3.2.3.  Security Expectations  . . . . . . . . . . . . . . . .  9
+       3.2.4.  TSIG Key Management  . . . . . . . . . . . . . . . . .  9
+       3.2.5.  DNS Protocol Authorization Management  . . . . . . . . 10
+     3.3.  Monitoring Requirements  . . . . . . . . . . . . . . . . . 10
+     3.4.  Alarm and Event Requirements . . . . . . . . . . . . . . . 11
+   4.  Security Requirements  . . . . . . . . . . . . . . . . . . . . 11
+     4.1.  Authentication . . . . . . . . . . . . . . . . . . . . . . 11
+     4.2.  Integrity Protection . . . . . . . . . . . . . . . . . . . 11
+     4.3.  Confidentiality  . . . . . . . . . . . . . . . . . . . . . 11
+     4.4.  Authorization  . . . . . . . . . . . . . . . . . . . . . . 12
+     4.5.  Solution Impacts on Security . . . . . . . . . . . . . . . 12
+   5.  Other Requirements . . . . . . . . . . . . . . . . . . . . . . 12
+     5.1.  Extensibility  . . . . . . . . . . . . . . . . . . . . . . 12
+       5.1.1.  Vendor Extensions  . . . . . . . . . . . . . . . . . . 13
+       5.1.2.  Extension Identification . . . . . . . . . . . . . . . 13
+       5.1.3.  Name-Space Collision Protection  . . . . . . . . . . . 13
+   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
+   7.  Document History . . . . . . . . . . . . . . . . . . . . . . . 13
+   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 14
+   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
+     9.1. Normative References  . . . . . . . . . . . . . . . . . . . 14
+     9.2. Informative References  . . . . . . . . . . . . . . . . . . 15
+   Appendix A.  Deployment Scenarios  . . . . . . . . . . . . . . . . 16
+     A.1.  Non-Standard Zones . . . . . . . . . . . . . . . . . . . . 16
+     A.2.  Redundancy Sharing . . . . . . . . . . . . . . . . . . . . 16
+     A.3.  DNSSEC Management  . . . . . . . . . . . . . . . . . . . . 17
+
+
+
+Hardaker                      Informational                     [Page 3]
+
+RFC 6168           Name Server Management Requirements          May 2011
+
+
+1.  Introduction
+
+   Management of name servers for the Domain Name System (DNS) [RFC1034]
+   [RFC1035] has traditionally been done using vendor-specific
+   monitoring, configuration, and control methods.  Although some
+   service monitoring platforms can test the functionality of the DNS
+   itself, there is not an interoperable way to manage (monitor,
+   control, and configure) the internal aspects of a name server itself.
+
+   Previous standardization work within the IETF resulted in the
+   creation of two SNMP MIB modules [RFC1611] [RFC1612], but they failed
+   to achieve significant implementation and deployment.  The perceived
+   reasons behind the failure for the two MIB modules are documented in
+   [RFC3197].
+
+   This document discusses the requirements of a management system for
+   name servers and can be used as a shopping list of needed features
+   for such a system.  This document only discusses requirements for
+   managing the name server component of a system -- not other elements
+   of the system itself.
+
+   Specifically out of scope for this document are requirements
+   associated with the management of stub resolvers.  It is not the
+   intent of this document to document stub resolver requirements,
+   although some of the requirements listed are applicable to stub
+   resolvers as well.
+
+   The task of creating a management system for managing DNS servers is
+   not expected to be a small one.  It is likely that components of the
+   solution will need to be designed in parts over time; these
+   requirements take this into consideration.  In particular,
+   Section 5.1 discusses the need for future extensibility of the base
+   management solution.  This document is intended to be a roadmap
+   towards a desired outcome and is not intended to define an "all-or-
+   nothing" system.  Successful interoperable management of name
+   servers, even in part, is expected to be beneficial to network
+   operators compared to the entirely custom solutions that are used at
+   the time of this writing.
+
+1.1.  Requirements Notation
+
+   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].
+
+
+
+
+
+
+
+Hardaker                      Informational                     [Page 4]
+
+RFC 6168           Name Server Management Requirements          May 2011
+
+
+1.2.  Terminology
+
+   This document is consistent with the terminology defined in Section 2
+   of [RFC4033].  Additional terminology needed for this document is
+   described below:
+
+   Name Server:  When we are discussing servers that don't fall into a
+      more specific type of server category defined in other documents,
+      this document will refer to them generically as "name servers".
+      In particular, "name servers" can be considered to be any valid
+      combination of authoritative, recursive, validating, or security-
+      aware.  The more specific name server labels will be used when
+      this document refers only to a specific type of server.  However,
+      the term "name server", in this document, will not include stub
+      resolvers.
+
+1.3.  Document Layout and Requirements
+
+   This document is written so that each numbered section will contain
+   only a single requirement if it contains one at all.  Each
+   requirement will contain needed wording from the terminology
+   described in Section 1.1.  Subsections, however, might exist with
+   additional related requirements.  The document is laid out in this
+   way so that a specific requirement can be uniquely referred to using
+   the section number itself and the document version from which it
+   came.
+
+2.  Management Architecture Requirements
+
+   This section discusses requirements that reflect the needs of the
+   expected deployment environments.
+
+2.1.  Expected Deployment Scenarios
+
+   DNS zones vary greatly in the type of content published within them.
+   Name servers, too, are deployed with a wide variety of configurations
+   to support the diversity of the deployed content.  It is important
+   that a management solution trying to meet the criteria specified in
+   this document consider supporting the largest number of potential
+   deployment cases as possible.  Further deployment scenarios that are
+   not used as direct examples of specific requirements are listed in
+   Appendix A.
+
+
+
+
+
+
+
+
+
+Hardaker                      Informational                     [Page 5]
+
+RFC 6168           Name Server Management Requirements          May 2011
+
+
+2.1.1.  Zone Size Constraints
+
+   The management solution MUST support both name servers that are
+   serving a small number of potentially very large zones (e.g., Top
+   Level Domains (TLDs)) as well as name servers that are serving a very
+   large number of small zones.  Both deployment scenarios are common.
+
+2.1.2.  Name Server Discovery
+
+   Large enterprise network deployments may contain multiple name
+   servers operating within the boundaries of the enterprise network.
+   These name servers may each be serving multiple zones both in and out
+   of the parent enterprise's zone.  Finding and managing large numbers
+   of name servers would be a useful feature of the resulting management
+   solution.  The management solution MAY support the ability to
+   discover previously unknown instances of name servers operating
+   within a deployed network.
+
+2.1.3.  Configuration Data Volatility
+
+   Configuration data is defined as data that relates only to the
+   configuration of a server and the zones it serves.  It specifically
+   does not include data from the zone contents that is served through
+   DNS itself.  The solution MUST support servers that remain statically
+   configured over time as well as servers that have numerous zones
+   being added and removed within an hour.  Both deployment scenarios
+   are common.
+
+2.1.4.  Protocol Selection
+
+   There are many requirements in this document for many different types
+   of management operations (see Section 3 for further details).  It is
+   possible that no one protocol will ideally fill all the needs of the
+   requirements listed in this document, and thus multiple protocols
+   might be needed to produce a completely functional management system.
+   Multiple protocols might be used to create the complete management
+   solution, but the solution SHOULD require only one.
+
+2.1.5.  Common Data Model
+
+   Defining a standardized protocol (or set of protocols) to use for
+   managing name servers would be a step forward in achieving an
+   interoperable management solution.  However, just defining a protocol
+   to use by itself would not achieve the entire end goal of a complete
+   interoperable management solution.  Devices also need to represent
+   their internal management interface using a common management data
+   model.  The solution MUST create a common data model that management
+   stations can make use of when sending or collecting data from a
+
+
+
+Hardaker                      Informational                     [Page 6]
+
+RFC 6168           Name Server Management Requirements          May 2011
+
+
+   managed device so it can successfully manage equipment from vendors
+   as if they were generic DNS servers.  This common data model is
+   needed for the operations discussion in Section 3.  Note that this
+   does not preclude the fact that name server vendors might provide
+   additional management infrastructure beyond a base management
+   specification, as discussed further in Section 5.1.
+
+2.1.6.  Operational Impact
+
+   It is impossible to add new features to an existing server (such as
+   the inclusion of a management infrastructure) and not impact the
+   existing service and/or server in some fashion.  At a minimum, for
+   example, more memory, disk, and/or CPU resources will be required to
+   implement a new management system.  However, the impact to the
+   existing DNS service MUST be minimized since the DNS service itself
+   is still the primary service to be offered by the modified name
+   server.  The management solution MUST NOT result in an increase of
+   the number of unhandled DNS requests.
+
+2.2.  Name Server Types
+
+   There are multiple ways in which name servers can be deployed.  Name
+   servers can take on any of the following roles:
+
+   o  Master Servers
+
+   o  Slave Servers
+
+   o  Recursive Servers
+
+   The management solution SHOULD support all of these types of name
+   servers as they are all equally important.  Note that "Recursive
+   Servers" can be further broken down by the security sub-roles they
+   might implement, as defined in section 2 of [RFC4033].  These sub-
+   roles are also important to support within any management solution.
+
+   As stated earlier, the management of stub resolvers is considered out
+   of scope for this document.
+
+3.  Management Operation Types
+
+   Management operations can traditionally be broken into four
+   categories:
+
+   o  Control
+
+   o  Configuration
+
+
+
+
+Hardaker                      Informational                     [Page 7]
+
+RFC 6168           Name Server Management Requirements          May 2011
+
+
+   o  Health and Monitoring
+
+   o  Alarms and Events
+
+   This section discusses detailed requirements for each of these four
+   management categories.
+
+3.1.  Control Requirements
+
+   The management solution MUST be capable of performing basic service
+   control operations.
+
+3.1.1.  Needed Control Operations
+
+   These operations SHOULD include, at a minimum, the following
+   operations:
+
+   o  Starting the name server
+
+   o  Reloading the service configuration
+
+   o  Reloading all of the zone data
+
+   o  Reloading individual zone data sets
+
+   o  Restarting the name server
+
+   o  Stopping the name server
+
+   Note that no restriction is placed on how the management system
+   implements these operations.  In particular, at least "starting the
+   name server" will require a minimal management system component to
+   exist independently of the name server itself.
+
+3.1.2.  Asynchronous Status Notifications
+
+   Some control operations might take a long time to complete.  As an
+   example, some name servers take a long time to perform reloads of
+   large zones.  Because of these timing issues, the management solution
+   SHOULD take this into consideration and offer a mechanism to ease the
+   burden associated with awaiting the status of a long-running command.
+   This could, for example, result in the use of asynchronous
+   notifications for returning the status of a long-running task, or it
+   might require the management station to poll for the status of a
+   given task using monitoring commands.  These and other potential
+   solutions need to be evaluated carefully to select one that balances
+   the result delivery needs with the perceived implementation costs.
+
+
+
+
+Hardaker                      Informational                     [Page 8]
+
+RFC 6168           Name Server Management Requirements          May 2011
+
+
+   Also, see the related discussion in Section 3.4 on notification
+   messages for supporting delivery of alarm and event messages.
+
+3.2.  Configuration Requirements
+
+   Many features of name servers need to be configured before the server
+   can be considered functional.  The management solution MUST be able
+   to provide name servers with configuration data.  The most important
+   data to be configured, for example, is the served zone data itself.
+
+3.2.1.  Served Zone Modification
+
+   The ability to add, modify, and delete zones being served by name
+   servers is needed.  Although there are already solutions for zone
+   content modification (such as Dynamic DNS (DDNS) [RFC2136] [RFC3007],
+   full zone transfer (AXFR) [RFC5936], and incremental zone transfer
+   (IXFR) [RFC1995]) that might be used as part of the final management
+   solution, the management system SHOULD still be able to create a new
+   zone (with enough minimal data to allow the other mechanisms to
+   function as well) and to delete a zone.  This might be, for example,
+   a management operation that allows for the creation of at least the
+   initial SOA (Start of Authority) record for a new zone, since that is
+   the minimum amount of zone data needed for the other operations to
+   function.
+
+3.2.2.  Trust Anchor Management
+
+   The solution SHOULD support the ability to add, modify, and delete
+   trust anchors that are used by DNS Security (DNSSEC) [RFC4033]
+   [RFC4034] [RFC4035] [RFC4509] [RFC5011] [RFC5155].  These trust
+   anchors might be configured using the data from the DNSKEY Resource
+   Records (RRs) themselves or by using Delegation Signer (DS)
+   fingerprints.
+
+3.2.3.  Security Expectations
+
+   DNSSEC validating resolvers need to make policy decisions about the
+   requests being processed.  For example, they need to be configured
+   with a list of zones expected to be secured by DNSSEC.  The
+   management solution SHOULD be able to add, modify, and delete
+   attributes of DNSSEC security policies.
+
+3.2.4.  TSIG Key Management
+
+   TSIG [RFC2845] allows transaction-level authentication of DNS
+   traffic.  The management solution SHOULD be able to add, modify, and
+   delete TSIG keys known to the name server.
+
+
+
+
+Hardaker                      Informational                     [Page 9]
+
+RFC 6168           Name Server Management Requirements          May 2011
+
+
+3.2.5.  DNS Protocol Authorization Management
+
+   The management solution SHOULD have the ability to add, modify, and
+   delete authorization settings for the DNS protocols itself.  Do not
+   confuse this with the ability to manage the authorization associated
+   with the management protocol itself, which is discussed later in
+   Section 4.4.  There are a number of authorization settings that are
+   used by a name server.  Example authorization settings that the
+   solution might need to cover are:
+
+   o  Access to operations on zone data (e.g., DDNS)
+
+   o  Access to certain zone data from certain sources (e.g., from
+      particular network subnets)
+
+   o  Access to specific DNS protocol services (e.g., recursive service)
+
+   Note: the above list is expected to be used as a collection of
+   examples and is not a complete list of needed authorization
+   protections.
+
+3.3.  Monitoring Requirements
+
+   Monitoring is the process of collecting aspects of the internal state
+   of a name server at a given moment in time.  The solution MUST be
+   able to monitor the health of a name server to determine its
+   operational status, load, and other internal attributes.  Example
+   parameters that the solution might need to collect and analyze are:
+
+   o  Number of requests sent, responses sent, number of errors, average
+      response latency, and other performance counters
+
+   o  Server status (e.g., "serving data", "starting up", "shutting
+      down", etc.)
+
+   o  Access control violations
+
+   o  List of zones being served
+
+   o  Detailed statistics about clients interacting with the name server
+      (e.g., top 10 clients requesting data).
+
+   Note: the above list is expected to be used as a collection of
+   examples and is not a complete list of needed monitoring operations.
+   In particular, some monitoring statistics are expected to be
+   computationally or resource expensive and are considered to be "nice
+   to have" as opposed to "necessary to have".
+
+
+
+
+Hardaker                      Informational                    [Page 10]
+
+RFC 6168           Name Server Management Requirements          May 2011
+
+
+3.4.  Alarm and Event Requirements
+
+   Events occurring at the name server that trigger alarm notifications
+   can quickly inform a management station about critical issues.  A
+   management solution SHOULD include support for delivery of alarm
+   conditions.
+
+   Example alarm conditions might include:
+
+   o  The server's status is changing (e.g., it is starting up,
+      reloading configuration, restarting or shutting down).
+
+   o  A needed resource (e.g., memory or disk space) is exhausted or
+      nearing exhaustion.
+
+   o  An authorization violation was detected.
+
+   o  The server has not received any data traffic (e.g., DNS requests
+      or NOTIFYs) recently (aka the "lonely warning").  This condition
+      might indicate a problem with the server's deployment.
+
+   o  The number of errors has exceeded a configured threshold.
+
+4.  Security Requirements
+
+   The management solution will need to be appropriately secured against
+   attacks on the management infrastructure.
+
+4.1.  Authentication
+
+   The solution MUST support mutual authentication.  The management
+   client needs to be assured that the management operations are being
+   transferred to and from the correct name server.  The managed name
+   server needs to authenticate the system that is accessing the
+   management infrastructure within itself.
+
+4.2.  Integrity Protection
+
+   Management operations MUST be protected from modification while in
+   transit from the management client to the server.
+
+4.3.  Confidentiality
+
+   The management solution MUST support message confidentiality.  The
+   potential transfer of sensitive configuration is expected (such as
+   TSIG keys or security policies).  The solution does not, however,
+   necessarily need to provide confidentiality to data that would
+   normally be carried without confidentiality by the DNS system itself.
+
+
+
+Hardaker                      Informational                    [Page 11]
+
+RFC 6168           Name Server Management Requirements          May 2011
+
+
+4.4.  Authorization
+
+   The solution SHOULD provide an authorization model capable of
+   selectively authorizing individual management requests for any
+   management protocols it introduces to the completed system.  This
+   authorization differs from the authorization previously discussed in
+   Section 3.2.5 in that this requirement is concerned solely with
+   authorization of the management system itself.
+
+   There are a number of authorization settings that might be used by a
+   managed system to determine whether the managing entity has
+   authorization to perform the given management task.  Example
+   authorization settings that the solution might need to cover are:
+
+   o  Access to the configuration that specifies which zones are to be
+      served
+
+   o  Access to the management system infrastructure
+
+   o  Access to other control operations
+
+   o  Access to other configuration operations
+
+   o  Access to monitoring operations
+
+   Note: the above list is expected to be used as a collection of
+   examples and is not a complete list of needed authorization
+   protections.
+
+4.5.  Solution Impacts on Security
+
+   The solution MUST minimize the security risks introduced to the
+   complete name server system.  It is impossible to add new
+   infrastructure to a server and not impact the security in some
+   fashion as the introduction of a management protocol alone will
+   provide a new avenue for potential attack.  Although the added
+   management benefits will be worth the increased risks, the solution
+   still needs to minimize this impact as much as possible.
+
+5.  Other Requirements
+
+5.1.  Extensibility
+
+   The management solution is expected to change and expand over time as
+   lessons are learned and new DNS features are deployed.  Thus, the
+   solution MUST be flexible and able to accommodate new future
+   management operations.  The solution might, for example, make use of
+   protocol versioning or capability description exchanges to ensure
+
+
+
+Hardaker                      Informational                    [Page 12]
+
+RFC 6168           Name Server Management Requirements          May 2011
+
+
+   that management stations and name servers that weren't written to the
+   same specification version can still interoperate to the best of
+   their combined ability.
+
+5.1.1.  Vendor Extensions
+
+   It MUST be possible for vendors to extend the standardized management
+   model with vendor-specific extensions to support additional features
+   offered by their products.
+
+5.1.2.  Extension Identification
+
+   It MUST be possible for a management station to understand which
+   parts of returned data are specific to a given vendor or other
+   standardized extension.  The data returned needs to be appropriately
+   marked, through the use of name spaces or similar mechanisms, to
+   ensure that the base management model data can be logically separated
+   from the extension data without needing to understand the extension
+   data itself.
+
+5.1.3.  Name-Space Collision Protection
+
+   It MUST be possible to protect against multiple extensions
+   conflicting with each other.  The use of name-space protection
+   mechanisms for communicated management variables is common practice
+   to protect against such problems.  Name-space identification
+   techniques also frequently solve the "Extension Identification"
+   requirement discussed in Section 5.1.2.
+
+6.  Security Considerations
+
+   Any management protocol for which conformance to this document is
+   claimed needs to fully support the criteria discussed in Section 4 in
+   order to protect the management infrastructure itself.  The DNS is a
+   core Internet service, and management traffic that protects it could
+   be the target of attacks designed to subvert that service.  Because
+   the management infrastructure will be adding additional interfaces to
+   that service, it is critical that the management infrastructure
+   support adequate protections against network attacks.
+
+7.  Document History
+
+   A requirement-gathering discussion was held at the December 2007 IETF
+   meeting in Vancouver, BC, Canada, and a follow-up meeting was held at
+   the March 2008 IETF meeting in Philadelphia.  This document is a
+   compilation of the results of those discussions as well as
+   discussions on the DCOMA mailing list.
+
+
+
+
+Hardaker                      Informational                    [Page 13]
+
+RFC 6168           Name Server Management Requirements          May 2011
+
+
+8.  Acknowledgments
+
+   This document is the result of discussions within the DCOMA design
+   team chaired by Jaap Akkerhuis.  This team consisted of a large
+   number of people, all of whom provided valuable insight and input
+   into the discussions surrounding name server management.  The text of
+   this document was written from notes taken during meetings as well as
+   from contributions sent to the DCOMA mailing list.  This work
+   documents the consensus of the DCOMA design team.
+
+   In particular, the following team members contributed significantly
+   to the text in the document:
+
+      Stephane Bortzmeyer
+      Stephen Morris
+      Phil Regnauld
+
+   Further editing contributions and wording suggestions were made by
+   Alfred Hoenes and Doug Barton.
+
+9.  References
+
+9.1.  Normative References
+
+   [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.
+
+   [RFC1995]  Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
+              August 1996.
+
+   [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.
+
+   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake, D., and B.
+              Wellington, "Secret Key Transaction Authentication for DNS
+              (TSIG)", RFC 2845, May 2000.
+
+   [RFC3007]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
+              Update", RFC 3007, November 2000.
+
+
+
+
+
+Hardaker                      Informational                    [Page 14]
+
+RFC 6168           Name Server Management Requirements          May 2011
+
+
+   [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.
+
+   [RFC4509]  Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
+              (DS) Resource Records (RRs)", RFC 4509, May 2006.
+
+   [RFC5011]  StJohns, M., "Automated Updates of DNS Security (DNSSEC)
+              Trust Anchors", RFC 5011, September 2007.
+
+   [RFC5155]  Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
+              Security (DNSSEC) Hashed Authenticated Denial of
+              Existence", RFC 5155, March 2008.
+
+   [RFC5936]  Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol
+              (AXFR)", RFC 5936, June 2010.
+
+9.2.  Informative References
+
+   [RFC1611]  Austein, R. and J. Saperia, "DNS Server MIB Extensions",
+              RFC 1611, May 1994.
+
+   [RFC1612]  Austein, R. and J. Saperia, "DNS Resolver MIB Extensions",
+              RFC 1612, May 1994.
+
+   [RFC2182]  Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection
+              and Operation of Secondary DNS Servers", BCP 16, RFC 2182,
+              July 1997.
+
+   [RFC3197]  Austein, R., "Applicability Statement for DNS MIB
+              Extensions", RFC 3197, November 2001.
+
+
+
+
+
+
+
+
+
+
+
+
+Hardaker                      Informational                    [Page 15]
+
+RFC 6168           Name Server Management Requirements          May 2011
+
+
+Appendix A.  Deployment Scenarios
+
+   This appendix documents some additional deployment scenarios that
+   have been traditionally difficult to manage.  They are provided as
+   guidance to protocol developers as data points of real-world name
+   server management problems.
+
+A.1.  Non-Standard Zones
+
+   If an organization uses non-standard zones (for example a purely
+   local TLD), synchronizing all the name servers for these zones is
+   usually a time-consuming task.  It is made worse when two
+   organizations with conflicting zones merge.  This situation is not a
+   recommended deployment scenario (and is even heavily discouraged),
+   but it is, unfortunately, seen in the wild.
+
+   It is typically implemented using "forwarding" zones.  But there is
+   no way to ensure automatically that all the resolvers have the same
+   set of zones to forward at any given time.  New zones might be added
+   to a local forwarding recursive server, for example, without
+   modifying the rest of the deployed forwarding servers.  It is hoped
+   that a management solution that could handle the configuration of
+   zone forwarding would finally allow management of servers deployed in
+   this fashion.
+
+A.2.  Redundancy Sharing
+
+   For reliability reasons, it is recommended that zone operators follow
+   the guidelines documented in [RFC2182], which recommends that
+   multiple name servers be configured for each zone and that the name
+   servers be separated both physically and via connectivity routes.  A
+   common solution is to establish DNS-serving partnerships: "I'll host
+   your zones and you'll host mine".  Both entities benefit from
+   increased DNS reliability via the wider service distribution.  This
+   frequently occurs between cooperating but otherwise unrelated
+   entities (such as between two distinct companies) as well as between
+   affiliated organizations (such as between branch offices within a
+   single company).
+
+   The configuration of these relationships are currently required to be
+   manually configured and maintained.  Changes to the list of zones
+   that are cross-hosted are manually negotiated between the cooperating
+   network administrators and configured by hand.  A management protocol
+   with the ability to provide selective authorization, as discussed in
+   Section 4.4, would solve many of the management difficulties between
+   cooperating organizations.
+
+
+
+
+
+Hardaker                      Informational                    [Page 16]
+
+RFC 6168           Name Server Management Requirements          May 2011
+
+
+A.3.  DNSSEC Management
+
+   There are many different DNSSEC deployment strategies that may be
+   used for mission-critical zones.  The following list describes some
+   example deployment scenarios that might warrant different management
+   strategies.
+
+      All contents and DNSSEC keying information controlled and operated
+      by a single organization
+
+      Zone contents controlled and operated by one organization, all
+      DNSSEC keying information controlled and operated by a second
+      organization.
+
+      Zone contents controlled and operated by one organization, zone
+      signing keys (ZSKs) controlled and operated by a second
+      organization, and key signing keys (KSKs) controlled and operated
+      by a third organization.
+
+   Although this list is not exhaustive in the potential ways that zone
+   data can be divided up, it should be sufficient to illustrate the
+   potential ways in which zone data can be controlled by multiple
+   entities.
+
+   The end result of all of these strategies, however, will be the same:
+   a live zone containing DNSSEC-related resource records.  Many of the
+   above strategies are merely different ways of preparing a zone for
+   serving.  A management solution that includes support for managing
+   DNSSEC zone data may wish to take into account these potential
+   management scenarios.
+
+Author's Address
+
+   Wes Hardaker
+   Sparta, Inc.
+   P.O. Box 382
+   Davis, CA  95617
+   US
+
+   Phone: +1 530 792 1913
+   EMail: ietf@hardakers.net
+
+
+
+
+
+
+
+
+
+
+Hardaker                      Informational                    [Page 17]
+
diff --git a/doc/rfc/rfc6672.txt b/doc/rfc/rfc6672.txt
new file mode 100644
index 0000000000..1534cf4ce8
--- /dev/null
+++ b/doc/rfc/rfc6672.txt
@@ -0,0 +1,1235 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                           S. Rose
+Request for Comments: 6672                                          NIST
+Obsoletes: 2672                                            W. Wijngaards
+Updates: 3363                                                 NLnet Labs
+Category: Standards Track                                      June 2012
+ISSN: 2070-1721
+
+
+                      DNAME Redirection in the DNS
+
+Abstract
+
+   The DNAME record provides redirection for a subtree of the domain
+   name tree in the DNS.  That is, all names that end with a particular
+   suffix are redirected to another part of the DNS.  This document
+   obsoletes the original specification in RFC 2672 as well as updates
+   the document on representing IPv6 addresses in DNS (RFC 3363).
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6672.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rose & Wijngaards            Standards Track                    [Page 1]
+
+RFC 6672                    DNAME Redirection                  June 2012
+
+
+Copyright Notice
+
+   Copyright (c) 2012 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.
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rose & Wijngaards            Standards Track                    [Page 2]
+
+RFC 6672                    DNAME Redirection                  June 2012
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
+     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  4
+   2.  The DNAME Resource Record  . . . . . . . . . . . . . . . . . .  5
+     2.1.  Format . . . . . . . . . . . . . . . . . . . . . . . . . .  5
+     2.2.  The DNAME Substitution . . . . . . . . . . . . . . . . . .  5
+     2.3.  DNAME Owner Name Matching the QNAME  . . . . . . . . . . .  6
+     2.4.  Names next to and below a DNAME Record . . . . . . . . . .  7
+     2.5.  Compression of the DNAME Record  . . . . . . . . . . . . .  7
+   3.  Processing . . . . . . . . . . . . . . . . . . . . . . . . . .  8
+     3.1.  CNAME Synthesis  . . . . . . . . . . . . . . . . . . . . .  8
+     3.2.  Server Algorithm . . . . . . . . . . . . . . . . . . . . .  9
+     3.3.  Wildcards  . . . . . . . . . . . . . . . . . . . . . . . . 10
+     3.4.  Acceptance and Intermediate Storage  . . . . . . . . . . . 11
+       3.4.1.  Resolver Algorithm . . . . . . . . . . . . . . . . . . 11
+   4.  DNAME Discussions in Other Documents . . . . . . . . . . . . . 12
+   5.  Other Issues with DNAME  . . . . . . . . . . . . . . . . . . . 13
+     5.1.  Canonical Hostnames Cannot Be below DNAME Owners . . . . . 13
+     5.2.  Dynamic Update and DNAME . . . . . . . . . . . . . . . . . 13
+     5.3.  DNSSEC and DNAME . . . . . . . . . . . . . . . . . . . . . 14
+       5.3.1.  Signed DNAME, Unsigned Synthesized CNAME . . . . . . . 14
+       5.3.2.  DNAME Bit in NSEC Type Map . . . . . . . . . . . . . . 14
+       5.3.3.  DNAME Chains as Strong as the Weakest Link . . . . . . 14
+       5.3.4.  Validators Must Understand DNAME . . . . . . . . . . . 14
+         5.3.4.1.  Invalid Name Error Response Caused by DNAME in
+                   Bitmap . . . . . . . . . . . . . . . . . . . . . . 15
+         5.3.4.2.  Valid Name Error Response Involving DNAME in
+                   Bitmap . . . . . . . . . . . . . . . . . . . . . . 15
+         5.3.4.3.  Response with Synthesized CNAME  . . . . . . . . . 16
+   6.  Examples of DNAME Use in a Zone  . . . . . . . . . . . . . . . 16
+     6.1.  Organizational Renaming  . . . . . . . . . . . . . . . . . 16
+     6.2.  Classless Delegation of Shorter Prefixes . . . . . . . . . 17
+     6.3.  Network Renumbering Support  . . . . . . . . . . . . . . . 17
+   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18
+   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18
+   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 18
+   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
+     10.1. Normative References . . . . . . . . . . . . . . . . . . . 19
+     10.2. Informative References . . . . . . . . . . . . . . . . . . 20
+   Appendix A.  Changes from RFC 2672 . . . . . . . . . . . . . . . . 21
+     A.1.  Changes to Server Behavior . . . . . . . . . . . . . . . . 21
+     A.2.  Changes to Client Behavior . . . . . . . . . . . . . . . . 21
+
+
+
+
+
+
+
+
+Rose & Wijngaards            Standards Track                    [Page 3]
+
+RFC 6672                    DNAME Redirection                  June 2012
+
+
+1.  Introduction
+
+   DNAME is a DNS resource record type originally defined in RFC 2672
+   [RFC2672].  DNAME provides redirection from a part of the DNS name
+   tree to another part of the DNS name tree.
+
+   The DNAME RR and the CNAME RR [RFC1034] cause a lookup to
+   (potentially) return data corresponding to a domain name different
+   from the queried domain name.  The difference between the two
+   resource records is that the CNAME RR directs the lookup of data at
+   its owner to another single name, whereas a DNAME RR directs lookups
+   for data at descendants of its owner's name to corresponding names
+   under a different (single) node of the tree.
+
+   For example, take looking through a zone (see RFC 1034 [RFC1034],
+   Section 4.3.2, step 3) for the domain name "foo.example.com", and a
+   DNAME resource record is found at "example.com" indicating that all
+   queries under "example.com" be directed to "example.net".  The lookup
+   process will return to step 1 with the new query name of
+   "foo.example.net".  Had the query name been "www.foo.example.com",
+   the new query name would be "www.foo.example.net".
+
+   This document is a revision of the original specification of DNAME in
+   RFC 2672 [RFC2672].  DNAME was conceived to help with the problem of
+   maintaining address-to-name mappings in a context of network
+   renumbering.  With a careful setup, a renumbering event in the
+   network causes no change to the authoritative server that has the
+   address-to-name mappings.  Examples in practice are classless reverse
+   address space delegations.
+
+   Another usage of DNAME lies in aliasing of name spaces.  For example,
+   a zone administrator may want subtrees of the DNS to contain the same
+   information.  Examples include punycode [RFC3492] alternates for
+   domain spaces.
+
+   This revision of the DNAME specification does not change the wire
+   format or the handling of DNAME resource records.  Discussion is
+   added on problems that may be encountered when using DNAME.
+
+1.1.  Requirements Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED" "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in RFC
+   2119 [RFC2119].
+
+
+
+
+
+
+Rose & Wijngaards            Standards Track                    [Page 4]
+
+RFC 6672                    DNAME Redirection                  June 2012
+
+
+2.  The DNAME Resource Record
+
+2.1.  Format
+
+   The DNAME RR has mnemonic DNAME and type code 39 (decimal).  It is
+   CLASS-insensitive.
+
+   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 presentation format of the RR is as follows:
+
+           <owner> <ttl> <class> DNAME <target>
+
+   The effect of the DNAME RR is the substitution of the record's
+   <target> for its owner name, as a suffix of a domain name.  This
+   substitution is to be applied for all names below the owner name of
+   the DNAME RR.  This substitution has to be applied for every DNAME RR
+   found in the resolution process, which allows fairly lengthy valid
+   chains of DNAME RRs.
+
+   Details of the substitution process, methods to avoid conflicting
+   resource records, and rules for specific corner cases are given in
+   the following subsections.
+
+2.2.  The DNAME Substitution
+
+   When following step 3 of the algorithm in RFC 1034 [RFC1034], Section
+   4.3.2, "start matching down, label by label, in the zone" and a node
+   is found to own a DNAME resource record, a DNAME substitution occurs.
+   The name being sought may be the original query name or a name that
+   is the result of a CNAME resource record being followed or a
+   previously encountered DNAME.  As in the case when finding a CNAME
+   resource record or NS resource record set, the processing of a DNAME
+   will happen prior to finding the desired domain name.
+
+   A DNAME substitution is performed by replacing the suffix labels of
+   the name being sought matching the owner name of the DNAME 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.  See the table of examples for common cases and corner
+   cases.
+
+   In the table below, the QNAME refers to the query name.  The owner is
+   the DNAME owner domain name, and the target refers to the target of
+   the DNAME record.  The result is the resulting name after performing
+   the DNAME substitution on the query name. "no match" means that the
+
+
+
+Rose & Wijngaards            Standards Track                    [Page 5]
+
+RFC 6672                    DNAME Redirection                  June 2012
+
+
+   query did not match the DNAME, and thus no substitution is performed
+   and a possible error message is returned (if no other result is
+   possible).  Thus, every line contains one example substitution.  In
+   the examples below, 'cyc' and 'shortloop' contain loops.
+
+    QNAME            owner  DNAME   target         result
+    ---------------- -------------- -------------- -----------------
+    com.             example.com.   example.net.   <no match>
+    example.com.     example.com.   example.net.   [0]
+    a.example.com.   example.com.   example.net.   a.example.net.
+    a.b.example.com. example.com.   example.net.   a.b.example.net.
+    ab.example.com.  b.example.com. example.net.   <no match>
+    foo.example.com. example.com.   example.net.   foo.example.net.
+    a.x.example.com. x.example.com. example.net.   a.example.net.
+    a.example.com.   example.com.   y.example.net. a.y.example.net.
+    cyc.example.com. example.com.   example.com.   cyc.example.com.
+    cyc.example.com. example.com.   c.example.com. cyc.c.example.com.
+    shortloop.x.x.   x.             .              shortloop.x.
+    shortloop.x.     x.             .              shortloop.
+
+   [0] The result depends on the QTYPE.  If the QTYPE = DNAME, then
+       the result is "example.com.", else "<no match>".
+
+                   Table 1. DNAME Substitution Examples
+
+   It is possible for DNAMEs to form loops, just as CNAMEs can form
+   loops.  DNAMEs and CNAMEs can chain together to form loops.  A single
+   corner case DNAME can form a loop.  Resolvers and servers should be
+   cautious in devoting resources to a query, but be aware that fairly
+   long chains of DNAMEs may be valid.  Zone content administrators
+   should take care to ensure that there are no loops that could occur
+   when using DNAME or DNAME/CNAME redirection.
+
+   The domain name can get too long during substitution.  For example,
+   suppose the target name of the DNAME RR is 250 octets in length
+   (multiple labels), if an incoming QNAME that has a first label over 5
+   octets in length, the result would be a name over 255 octets.  If
+   this occurs, the server returns an RCODE of YXDOMAIN [RFC2136].  The
+   DNAME record and its signature (if the zone is signed) are included
+   in the answer as proof for the YXDOMAIN (value 6) RCODE.
+
+2.3.  DNAME Owner Name Matching the QNAME
+
+   Unlike a CNAME RR, a DNAME RR redirects DNS names subordinate to its
+   owner name; the owner name of a DNAME is not redirected itself.  The
+   domain name that owns a DNAME record is allowed to have other
+   resource record types at that domain name, except DNAMEs, CNAMEs, or
+   other types that have restrictions on what they can coexist with.
+
+
+
+Rose & Wijngaards            Standards Track                    [Page 6]
+
+RFC 6672                    DNAME Redirection                  June 2012
+
+
+   When there is a match of the QTYPE to a type (or types) also owned by
+   the owner name, the response is sourced from the owner name.  For
+   example, a QTYPE of ANY would return the (available) types at the
+   owner name, not the target name.
+
+   DNAME RRs MUST NOT appear at the same owner name as an NS RR unless
+   the owner name is the zone apex; if it is not the zone apex, then the
+   NS RR signifies a delegation point, and the DNAME RR must in that
+   case appear below the zone cut at the zone apex of the child zone.
+
+   If a DNAME record is present at the zone apex, there is still a need
+   to have the customary SOA and NS resource records there as well.
+   Such a DNAME cannot be used to mirror a zone completely, as it does
+   not mirror the zone apex.
+
+   These rules also allow DNAME records to be queried through caches
+   that are RFC 1034 [RFC1034] compliant and are DNAME unaware.
+
+2.4.  Names next to and below a DNAME Record
+
+   Resource records MUST NOT exist at any subdomain of the owner of a
+   DNAME RR.  To get the contents for names subordinate to that owner
+   name, the DNAME redirection must be invoked and the resulting target
+   queried.  A server MAY refuse to load a zone that has data at a
+   subdomain of a domain name owning a DNAME RR.  If the server does
+   load the zone, those names below the DNAME RR will be occluded as
+   described in RFC 2136 [RFC2136], Section 7.18.  Also, a server ought
+   to refuse to load a zone subordinate to the owner of a DNAME record
+   in the ancestor zone.  See Section 5.2 for further discussion related
+   to dynamic update.
+
+   DNAME is a singleton type, meaning only one DNAME is allowed per
+   name.  The owner name of a DNAME can only have one DNAME RR, and no
+   CNAME RRs can exist at that name.  These rules make sure that for a
+   single domain name, only one redirection exists; thus, there's no
+   confusion about which one to follow.  A server ought to refuse to
+   load a zone that violates these rules.
+
+2.5.  Compression of the DNAME Record
+
+   The DNAME owner name can be compressed like any other owner name.
+   The DNAME RDATA target name MUST NOT be sent out in compressed form
+   and MUST be downcased for DNS Security Extensions (DNSSEC)
+   validation.
+
+
+
+
+
+
+
+Rose & Wijngaards            Standards Track                    [Page 7]
+
+RFC 6672                    DNAME Redirection                  June 2012
+
+
+   Although the previous DNAME specification [RFC2672] (that is
+   obsoleted by this specification) talked about signaling to allow
+   compression of the target name, such signaling has never been
+   specified, nor is it specified in this document.
+
+   RFC 2672 (obsoleted by this document) states that the Extended DNS
+   (EDNS) version has a means for understanding DNAME and DNAME target
+   name compression.  This document revises RFC 2672, in that there is
+   no EDNS version signaling for DNAME.
+
+3.  Processing
+
+3.1.  CNAME Synthesis
+
+   When preparing a response, a server performing a DNAME substitution
+   will, in all cases, include the relevant DNAME RR in the answer
+   section.  Relevant cases includes the following:
+
+   1.  The DNAME is being employed as a substitution instruction.
+
+   2.  The DNAME itself matches the QTYPE, and the owner name matches
+       QNAME.
+
+   When the owner name matches the QNAME and the QTYPE matches another
+   type owned there, the DNAME is not included in the answer.
+
+   A CNAME RR with Time to Live (TTL) equal to the corresponding DNAME
+   RR is synthesized and included in the answer section when the DNAME
+   is employed as a substitution instruction.  The owner name of the
+   CNAME is the QNAME of the query.  The DNSSEC specification ([RFC4033]
+   [RFC4034] [RFC4035]) says that the synthesized CNAME does not have to
+   be signed.  The signed DNAME has an RRSIG, and a validating resolver
+   can check the CNAME against the DNAME record and validate the
+   signature over the DNAME RR.
+
+   Servers MUST be able to answer a query for a synthesized CNAME.  Like
+   other query types, this invokes the DNAME, and then the server
+   synthesizes the CNAME and places it into the answer section.  If the
+   server in question is a cache, the synthesized CNAME's TTL SHOULD be
+   equal to the decremented TTL of the cached DNAME.
+
+   Resolvers MUST be able to handle a synthesized CNAME TTL of zero or a
+   value equal to the TTL of the corresponding DNAME record (as some
+   older, authoritative server implementations set the TTL of
+   synthesized CNAMEs to zero).  A TTL of zero means that the CNAME can
+   be discarded immediately after processing the answer.
+
+
+
+
+
+Rose & Wijngaards            Standards Track                    [Page 8]
+
+RFC 6672                    DNAME Redirection                  June 2012
+
+
+3.2.  Server Algorithm
+
+   Below is the revised version of the server algorithm, which appears
+   in RFC 2672, Section 4.1.
+
+   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:
+
+       A.  If the whole of QNAME is matched, we have found the node.
+
+           If the data at the node is a CNAME, and QTYPE does not match
+           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.
+
+           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 sub-zone 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 DNAME record.
+
+           If a DNAME 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 MUST
+
+
+
+
+Rose & Wijngaards            Standards Track                    [Page 9]
+
+RFC 6672                    DNAME Redirection                  June 2012
+
+
+           synthesize a CNAME record as described above and include it
+           in the answer section.  Go back to step 1.
+
+           If there was no DNAME 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 or DNAME.  If the name is
+           original, set an authoritative name error in the response and
+           exit.  Otherwise, just exit.
+
+           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.  If the data at the node with the "*" label is
+           a CNAME, and QTYPE doesn't match CNAME, copy the CNAME RR
+           into the answer section of the response changing the owner
+           name to the QNAME, change QNAME to the canonical name in the
+           CNAME RR, and go back to step 1.  Otherwise, go to step 6.
+
+   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 DNAME
+       record is present at an ancestor of QNAME, copy that DNAME 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 to answer the
+       query.  Store the results, including any intermediate CNAMEs and
+       DNAMEs, in the answer section of the response.
+
+   6.  Using local data only, attempt to add other RRs that may be
+       useful to the additional section of the query.  Exit.
+
+   Note that there will be at most one ancestor with a DNAME as
+   described in step 4 unless some zone's data is in violation of the
+   no-descendants limitation in Section 3.  An implementation might take
+   advantage of this limitation by stopping the search of step 3c or
+   step 4 when a DNAME record is encountered.
+
+3.3.  Wildcards
+
+   The use of DNAME in conjunction with wildcards is discouraged
+   [RFC4592].  Thus, records of the form "*.example.com DNAME
+   example.net" SHOULD NOT be used.
+
+
+
+
+Rose & Wijngaards            Standards Track                   [Page 10]
+
+RFC 6672                    DNAME Redirection                  June 2012
+
+
+   The interaction between the expansion of the wildcard and the
+   redirection of the DNAME is non-deterministic.  Due to the fact that
+   the processing is non-deterministic, DNSSEC validating resolvers may
+   not be able to validate a wildcarded DNAME.
+
+   A server MAY give a warning that the behavior is unspecified if such
+   a wildcarded DNAME is loaded.  The server MAY refuse it, refuse to
+   load the zone, or refuse dynamic updates.
+
+3.4.  Acceptance and Intermediate Storage
+
+   Recursive caching name servers can encounter data at names below the
+   owner name of a DNAME RR, due to a change at the authoritative server
+   where data from before and after the change resides in the cache.
+   This conflict situation is a transitional phase that ends when the
+   old data times out.  The caching name server can opt to store both
+   old and new data and treat each as if the other did not exist, or
+   drop the old data, or drop the longer domain name.  In any approach,
+   consistency returns after the older data TTL times out.
+
+   Recursive caching name servers MUST perform CNAME synthesis on behalf
+   of clients.
+
+   If a recursive caching name server encounters a DNSSEC validated
+   DNAME RR that contradicts information already in the cache (excluding
+   CNAME records), it SHOULD cache the DNAME RR, but it MAY cache the
+   CNAME record received along with it, subject to the rules for CNAME.
+   If the DNAME RR cannot be validated via DNSSEC (i.e., not BOGUS, but
+   not able to validate), the recursive caching server SHOULD NOT cache
+   the DNAME RR but MAY cache the CNAME record received along with it,
+   subject to the rules for CNAME.
+
+3.4.1.  Resolver Algorithm
+
+   Below is the revised version of the resolver algorithm, which appears
+   in RFC 2672, Section 4.2.
+
+   1.  See if the answer is in local information or can be synthesized
+       from a cached DNAME; if so, return it to the client.
+
+   2.  Find the best servers to ask.
+
+   3.  Send queries until one returns a response.
+
+
+
+
+
+
+
+
+Rose & Wijngaards            Standards Track                   [Page 11]
+
+RFC 6672                    DNAME Redirection                  June 2012
+
+
+   4.  Analyze the response, either:
+
+       A.  If the response answers the question or contains a name
+           error, cache the data as well as return 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 DNAME and that is not the answer
+           itself, cache the DNAME (upon successful DNSSEC validation if
+           the client is a validating resolver).  If substitution of the
+           DNAME's target name for its owner name 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.
+
+4.  DNAME Discussions in Other Documents
+
+   In Section 10.3 of [RFC2181], the discussion on MX and NS records
+   touches on redirection by CNAMEs, but this also holds for DNAMEs.
+
+   Section 10.3 ("MX and NS records") of [RFC2181] states:
+
+           The domain name used as the value of a NS resource record,
+           or part of the value of a MX resource record must not be
+           an alias.  Not only is the specification clear on this
+           point, but using an alias in either of these positions
+           neither works as well as might be hoped, nor well fulfills
+           the ambition that may have led to this approach.  This
+           domain name must have as its value one or more address
+           records.  Currently those will be A records, however in
+           the future other record types giving addressing
+           information may be acceptable.  It can also have other
+           RRs, but never a CNAME RR.
+
+   The DNAME RR is discussed in RFC 3363, Section 4, on A6 and DNAME.
+   The opening premise of this section is demonstrably wrong, and so the
+   conclusion based on that premise is wrong.  In particular, [RFC3363]
+   deprecates the use of DNAME in the IPv6 reverse tree.  Based on the
+
+
+
+Rose & Wijngaards            Standards Track                   [Page 12]
+
+RFC 6672                    DNAME Redirection                  June 2012
+
+
+   experience gained in the meantime, [RFC3363] is revised, dropping all
+   constraints on having DNAME RRs in these zones [RFC6434].  This would
+   greatly improve the manageability of the IPv6 reverse tree.  These
+   changes are made explicit below.
+
+   In [RFC3363], the following paragraph is updated by this document,
+   and the use of DNAME RRs in the reverse tree is no longer deprecated.
+
+     The issues for DNAME in the reverse mapping tree appears to be
+     closely tied to the need to use fragmented A6 in the main tree: if
+     one is necessary, so is the other, and if one isn't necessary, the
+     other isn't either.  Therefore, in moving RFC 2874 to experimental,
+     the intent of this document is that use of DNAME RRs in the reverse
+     tree be deprecated.
+
+5.  Other Issues with DNAME
+
+   There are several issues to be aware of about the use of DNAME.
+
+5.1.  Canonical Hostnames Cannot Be below DNAME Owners
+
+   The names listed as target names of MX, NS, PTR, and SRV [RFC2782]
+   records must be canonical hostnames.  This means no CNAME or DNAME
+   redirection may be present during DNS lookup of the address records
+   for the host.  This is discussed in RFC 2181 [RFC2181], Section 10.3,
+   and RFC 1912 [RFC1912], Section 2.4.  For SRV, see RFC 2782
+   [RFC2782], page 4.
+
+   The upshot of this is that although the lookup of a PTR record can
+   involve DNAMEs, the name listed in the PTR record cannot fall under a
+   DNAME.  The same holds for NS, SRV, and MX records.  For example,
+   when punycode [RFC3492] alternates for a zone use DNAME, then the NS,
+   MX, SRV, and PTR records that point to that zone must use names that
+   are not aliases in their RDATA.  Then, what must be done is to have
+   the domain names with DNAME substitution already applied to it as the
+   MX, NS, PTR, and SRV data.  These are valid canonical hostnames.
+
+5.2.  Dynamic Update and DNAME
+
+   DNAME records can be added, changed, and removed in a zone using
+   dynamic update transactions.  Adding a DNAME RR to a zone occludes
+   any domain names that may exist under the added DNAME.
+
+   If a dynamic update message attempts to add a DNAME with a given
+   owner name, but a CNAME is associated with that name, then the server
+   MUST ignore the DNAME.  If a DNAME is already associated with that
+   name, then it is replaced with the new DNAME.  Otherwise, add the
+   DNAME.  If a CNAME is added with a given owner name, but a DNAME is
+
+
+
+Rose & Wijngaards            Standards Track                   [Page 13]
+
+RFC 6672                    DNAME Redirection                  June 2012
+
+
+   associated with that name, then the CNAME MUST be ignored.  Similar
+   behavior occurs for dynamic updates to an owner name of a CNAME RR
+   [RFC2136].
+
+5.3.  DNSSEC and DNAME
+
+   The following subsections specify the behavior of implementations
+   that understand both DNSSEC and DNAME (synthesis).
+
+5.3.1.  Signed DNAME, Unsigned Synthesized CNAME
+
+   In any response, a signed DNAME RR indicates a non-terminal
+   redirection of the query.  There might or might not be a server-
+   synthesized CNAME in the answer section; if there is, the CNAME will
+   never be signed.  For a DNSSEC validator, verification of the DNAME
+   RR and then that the CNAME was properly synthesized is sufficient
+   proof.
+
+5.3.2.  DNAME Bit in NSEC Type Map
+
+   In any negative response, the NSEC or NSEC3 [RFC5155] record type
+   bitmap SHOULD be checked to see that there was no DNAME that could
+   have been applied.  If the DNAME bit in the type bitmap is set and
+   the query name is a subdomain of the closest encloser that is
+   asserted, then DNAME substitution should have been done, but the
+   substitution has not been done as specified.
+
+5.3.3.  DNAME Chains as Strong as the Weakest Link
+
+   A response can contain a chain of DNAME and CNAME redirections.  That
+   chain can end in a positive answer or a negative reply (no name error
+   or no data error).  Each step in that chain results in resource
+   records being added to the answer or authority section of the
+   response.  Only if all steps are secure can the AD (Authentic Data)
+   bit be set for the response.  If one of the steps is bogus, the
+   result is bogus.
+
+5.3.4.  Validators Must Understand DNAME
+
+   Below are examples of why DNSSEC validators MUST understand DNAME.
+   In the examples, SOA records, wildcard denial NSECs, and other
+   material not under discussion have been omitted or shortened.
+
+
+
+
+
+
+
+
+
+Rose & Wijngaards            Standards Track                   [Page 14]
+
+RFC 6672                    DNAME Redirection                  June 2012
+
+
+5.3.4.1.  Invalid Name Error Response Caused by DNAME in Bitmap
+
+   ;; Header: QR AA RCODE=3(NXDOMAIN)
+   ;; OPT PSEUDOSECTION:
+   ; EDNS: version: 0, flags: do; udp: 4096
+
+   ;; Question
+   foo.bar.example.com. IN A
+   ;; Authority
+   bar.example.com. NSEC dub.example.com. A DNAME
+   bar.example.com. RRSIG NSEC [valid signature]
+
+   If this is the received response, then only by understanding that the
+   DNAME bit in the NSEC bitmap means that foo.bar.example.com needed to
+   have been redirected by the DNAME, the validator can see that it is a
+   BOGUS reply from an attacker that collated existing records from the
+   DNS to create a confusing reply.
+
+   If the DNAME bit had not been set in the NSEC record above, then the
+   answer would have validated as a correct name error response.
+
+5.3.4.2.  Valid Name Error Response Involving DNAME in Bitmap
+
+   ;; Header: QR AA RCODE=3(NXDOMAIN)
+   ;; OPT PSEUDOSECTION:
+   ; EDNS: version: 0, flags: do; udp: 4096
+
+   ;; Question
+   cee.example.com. IN A
+   ;; Authority
+   bar.example.com. NSEC dub.example.com. A DNAME
+   bar.example.com. RRSIG NSEC [valid signature]
+
+   This response has the same NSEC records as the example above, but
+   with this query name (cee.example.com), the answer is validated,
+   because 'cee' does not get redirected by the DNAME at 'bar'.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rose & Wijngaards            Standards Track                   [Page 15]
+
+RFC 6672                    DNAME Redirection                  June 2012
+
+
+5.3.4.3.  Response with Synthesized CNAME
+
+   ;; Header: QR AA RCODE=0(NOERROR)
+   ;; OPT PSEUDOSECTION:
+   ; EDNS: version: 0, flags: do; udp: 4096
+
+   ;; Question
+   foo.bar.example.com. IN A
+   ;; Answer
+   bar.example.com. DNAME bar.example.net.
+   bar.example.com. RRSIG DNAME [valid signature]
+   foo.bar.example.com. CNAME foo.bar.example.net.
+
+   The response shown above has the synthesized CNAME included.
+   However, the CNAME has no signature, since the server does not sign
+   online.  So this response cannot be trusted.  It could be altered by
+   an attacker to be foo.bar.example.com CNAME bla.bla.example.  The
+   DNAME record does have its signature included, since it does not
+   change.  The validator must verify the DNAME signature and then
+   recursively resolve further in order to query for the
+   foo.bar.example.net A record.
+
+6.  Examples of DNAME Use in a Zone
+
+   Below are some examples of the use of DNAME in a zone.  These
+   examples are by no means exhaustive.
+
+6.1.  Organizational Renaming
+
+   If an organization with domain name FROBOZZ.EXAMPLE.NET became part
+   of an organization with domain name ACME.EXAMPLE.COM, it might ease
+   transition by placing information such as this in its old zone.
+
+       frobozz.example.net.  DNAME    frobozz-division.acme.example.com.
+                             MX       10       mailhub.acme.example.com.
+
+   The response to an extended recursive query for
+   www.frobozz.example.net would contain, in the answer section, the
+   DNAME record shown above and the relevant RRs for www.frobozz-
+   division.acme.example.com.
+
+   If an organization wants to have aliases for names, for a different
+   spelling or language, the same example applies.  Note that the MX RR
+   at the zone apex is not redirected and has to be repeated in the
+   target zone.  Also note that the services at mailhub or www.frobozz-
+   division.acme.example.com. have to recognize and handle the aliases.
+
+
+
+
+
+Rose & Wijngaards            Standards Track                   [Page 16]
+
+RFC 6672                    DNAME Redirection                  June 2012
+
+
+6.2.  Classless Delegation of Shorter Prefixes
+
+   The classless scheme for in-addr.arpa delegation [RFC2317] can be
+   extended to prefixes shorter than 24 bits by use of the DNAME record.
+   For example, the prefix 192.0.8.0/22 can be delegated by the
+   following records.
+
+       $ORIGIN 0.192.in-addr.arpa.
+       8/22    NS       ns.slash-22-holder.example.com.
+       8       DNAME    8.8/22
+       9       DNAME    9.8/22
+       10      DNAME    10.8/22
+       11      DNAME    11.8/22
+
+   A typical entry in the resulting reverse zone for some host with
+   address 192.0.9.33 might be as follows:
+
+        $ORIGIN 8/22.0.192.in-addr.arpa.
+        33.9    PTR     somehost.slash-22-holder.example.com.
+
+   The advisory remarks in [RFC2317] concerning the choice of the "/"
+   character apply here as well.
+
+6.3.  Network Renumbering Support
+
+   If IPv4 network renumbering were common, maintenance of address space
+   delegation could be simplified by using DNAME records instead of NS
+   records to delegate.
+
+       $ORIGIN new-style.in-addr.arpa.
+       189.190           DNAME    in-addr.example.net.
+
+       $ORIGIN in-addr.example.net.
+       188               DNAME    in-addr.customer.example.com.
+
+       $ORIGIN in-addr.customer.example.
+       1                 PTR      www.customer.example.com
+       2                 PTR      mailhub.customer.example.com.
+       ; etc ...
+
+   This would allow the address space 190.189.0.0/16 assigned to the ISP
+   "example.net" to be changed without having to alter the zone data
+   describing the use of that space by the ISP and its customers.
+
+
+
+
+
+
+
+
+Rose & Wijngaards            Standards Track                   [Page 17]
+
+RFC 6672                    DNAME Redirection                  June 2012
+
+
+   Renumbering IPv4 networks is currently so arduous a task that
+   updating the DNS is only a small part of the labor, so this scheme
+   may have a low value.  But it is hoped that in IPv6 the renumbering
+   task will be quite different, and the DNAME mechanism may play a
+   useful part.
+
+7.  IANA Considerations
+
+   The DNAME resource record type code 39 (decimal) originally was
+   registered by [RFC2672] in the DNS Resource Record (RR) Types
+   registry table at http://www.iana.org/assignments/dns-parameters.
+   IANA has updated the DNS resource record registry to point to this
+   document for RR type 39.
+
+8.  Security Considerations
+
+   DNAME redirects queries elsewhere, which may impact security based on
+   policy and the security status of the zone with the DNAME and the
+   redirection zone's security status.  For validating resolvers, the
+   lowest security status of the links in the chain of CNAME and DNAME
+   redirections is applied to the result.
+
+   If a validating resolver accepts wildcarded DNAMEs, this creates
+   security issues.  Since the processing of a wildcarded DNAME is non-
+   deterministic and the CNAME that was substituted by the server has no
+   signature, the resolver may choose a different result than what the
+   server meant, and consequently end up at the wrong destination.  Use
+   of wildcarded DNAMEs is discouraged in any case [RFC4592].
+
+   A validating resolver MUST understand DNAME, according to [RFC4034].
+   The examples in Section 5.3.4 illustrate this need.
+
+9.  Acknowledgments
+
+   The authors of this document would like to acknowledge Matt Larson
+   for beginning this effort to address the issues related to the DNAME
+   RR type.  The authors would also like to acknowledge Paul Vixie, Ed
+   Lewis, Mark Andrews, Mike StJohns, Niall O'Reilly, Sam Weiler, Alfred
+   Hoenes, and Kevin Darcy for their reviews and comments on this
+   document.
+
+
+
+
+
+
+
+
+
+
+
+Rose & Wijngaards            Standards Track                   [Page 18]
+
+RFC 6672                    DNAME Redirection                  June 2012
+
+
+10.  References
+
+10.1.  Normative References
+
+   [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.
+
+   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
+              Specification", RFC 2181, July 1997.
+
+   [RFC2317]  Eidnes, H., de Groot, G., and P. Vixie, "Classless IN-
+              ADDR.ARPA delegation", BCP 20, RFC 2317, March 1998.
+
+   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
+              specifying the location of services (DNS SRV)", RFC 2782,
+              February 2000.
+
+   [RFC3597]  Gustafsson, A., "Handling of Unknown DNS Resource Record
+              (RR) Types", RFC 3597, September 2003.
+
+   [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.
+
+   [RFC4592]  Lewis, E., "The Role of Wildcards in the Domain Name
+              System", RFC 4592, July 2006.
+
+   [RFC5155]  Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
+              Security (DNSSEC) Hashed Authenticated Denial of
+              Existence", RFC 5155, March 2008.
+
+
+
+Rose & Wijngaards            Standards Track                   [Page 19]
+
+RFC 6672                    DNAME Redirection                  June 2012
+
+
+10.2.  Informative References
+
+   [RFC1912]  Barr, D., "Common DNS Operational and Configuration
+              Errors", RFC 1912, February 1996.
+
+   [RFC2672]  Crawford, M., "Non-Terminal DNS Name Redirection",
+              RFC 2672, August 1999.
+
+   [RFC3363]  Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
+              Hain, "Representing Internet Protocol version 6 (IPv6)
+              Addresses in the Domain Name System (DNS)", RFC 3363,
+              August 2002.
+
+   [RFC3492]  Costello, A., "Punycode: A Bootstring encoding of Unicode
+              for Internationalized Domain Names in Applications
+              (IDNA)", RFC 3492, March 2003.
+
+   [RFC6434]  Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node
+              Requirements", RFC 6434, December 2011.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rose & Wijngaards            Standards Track                   [Page 20]
+
+RFC 6672                    DNAME Redirection                  June 2012
+
+
+Appendix A.  Changes from RFC 2672
+
+A.1.  Changes to Server Behavior
+
+   Major changes to server behavior from the original DNAME
+   specification are summarized below:
+
+   o  The rules for DNAME substitution have been clarified in
+      Section 2.2.
+
+   o  The EDNS option to signal DNAME understanding and compression has
+      never been specified, and this document clarifies that there is no
+      signaling method (Section 2.5).
+
+   o  The TTL for synthesized CNAME RRs is now set to the TTL of the
+      DNAME, not zero (Section 3.1).
+
+   o  Recursive caching servers MUST perform CNAME synthesis on behalf
+      of clients (Section 3.4).
+
+   o  The revised server algorithm is detailed in Section 3.2.
+
+   o  Rules for dynamic update messages adding a DNAME or CNAME RR to a
+      zone where a CNAME or DNAME already exists are detailed in
+      Section 5.2.
+
+A.2.  Changes to Client Behavior
+
+   Major changes to client behavior from the original DNAME
+   specification are summarized below:
+
+   o  Clients MUST be able to accept synthesized CNAME RR's with a TTL
+      of either zero or the TTL of the DNAME RR that accompanies the
+      CNAME RR.
+
+   o  DNSSEC-aware clients SHOULD cache DNAME RRs and MAY cache
+      synthesized CNAME RRs they receive in the same response.  DNSSEC-
+      aware clients SHOULD also check the NSEC/NSEC3 type bitmap to
+      verify that DNAME redirection is to be done.  DNSSEC validators
+      MUST understand DNAME (Section 5.3).
+
+   o  The revised client algorithm is detailed in Section 3.4.1.
+
+
+
+
+
+
+
+
+
+Rose & Wijngaards            Standards Track                   [Page 21]
+
+RFC 6672                    DNAME Redirection                  June 2012
+
+
+Authors' Addresses
+
+   Scott Rose
+   NIST
+   100 Bureau Dr.
+   Gaithersburg, MD  20899
+   USA
+
+   Phone: +1-301-975-8439
+   Fax:   +1-301-975-6238
+   EMail: scott.rose@nist.gov
+
+
+   Wouter Wijngaards
+   NLnet Labs
+   Science Park 140
+   Amsterdam  1098 XH
+   The Netherlands
+
+   Phone: +31-20-888-4551
+   EMail: wouter@nlnetlabs.nl
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rose & Wijngaards            Standards Track                   [Page 22]
+
diff --git a/doc/rfc/rfc6698.txt b/doc/rfc/rfc6698.txt
new file mode 100644
index 0000000000..95e7cf4f5c
--- /dev/null
+++ b/doc/rfc/rfc6698.txt
@@ -0,0 +1,2075 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                        P. Hoffman
+Request for Comments: 6698                                VPN Consortium
+Category: Standards Track                                    J. Schlyter
+ISSN: 2070-1721                                                 Kirei AB
+                                                             August 2012
+
+
+         The DNS-Based Authentication of Named Entities (DANE)
+             Transport Layer Security (TLS) Protocol: TLSA
+
+Abstract
+
+   Encrypted communication on the Internet often uses Transport Layer
+   Security (TLS), which depends on third parties to certify the keys
+   used.  This document improves on that situation by enabling the
+   administrators of domain names to specify the keys used in that
+   domain's TLS servers.  This requires matching improvements in TLS
+   client software, but no change in TLS server software.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6698.
+
+Copyright Notice
+
+   Copyright (c) 2012 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.
+
+
+
+
+Hoffman & Schlyter           Standards Track                    [Page 1]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Background and Motivation ..................................3
+      1.2. Securing the Association of a Domain Name with a
+           Server's Certificate .......................................4
+      1.3. Method for Securing Certificate Associations ...............5
+      1.4. Terminology ................................................6
+   2. The TLSA Resource Record ........................................7
+      2.1. TLSA RDATA Wire Format .....................................7
+           2.1.1. The Certificate Usage Field .........................7
+           2.1.2. The Selector Field ..................................8
+           2.1.3. The Matching Type Field .............................9
+           2.1.4. The Certificate Association Data Field ..............9
+      2.2. TLSA RR Presentation Format ................................9
+      2.3. TLSA RR Examples ..........................................10
+   3. Domain Names for TLSA Certificate Associations .................10
+   4. Use of TLSA Records in TLS .....................................11
+      4.1. Usable Certificate Associations ...........................11
+   5. TLSA and DANE Use Cases and Requirements .......................13
+   6. Mandatory-to-Implement Features ................................15
+   7. IANA Considerations ............................................15
+      7.1. TLSA RRtype ...............................................15
+      7.2. TLSA Certificate Usages ...................................15
+      7.3. TLSA Selectors ............................................16
+      7.4. TLSA Matching Types .......................................16
+   8. Security Considerations ........................................16
+      8.1. Comparing DANE to Public CAs ..............................18
+           8.1.1. Risk of Key Compromise .............................19
+           8.1.2. Impact of Key Compromise ...........................20
+           8.1.3. Detection of Key Compromise ........................20
+           8.1.4. Spoofing Hostnames .................................20
+      8.2. DNS Caching ...............................................21
+      8.3. External DNSSEC Validators ................................21
+   9. Acknowledgements ...............................................22
+   10. References ....................................................22
+      10.1. Normative References .....................................22
+      10.2. Informative References ...................................23
+   Appendix A. Operational Considerations for Deploying TLSA
+               Records ...............................................25
+     A.1. Creating TLSA Records ......................................25
+       A.1.1. Ambiguities and Corner Cases When TLS Clients
+              Build Trust Chains .....................................26
+       A.1.2. Choosing a Selector Type ...............................26
+     A.2. Provisioning TLSA Records in DNS ...........................28
+       A.2.1. Provisioning TLSA Records with Aliases .................28
+     A.3. Securing the Last Hop ......................................30
+     A.4. Handling Certificate Rollover ..............................31
+
+
+
+Hoffman & Schlyter           Standards Track                    [Page 2]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+   Appendix B. Pseudocode for Using TLSA .............................32
+     B.1. Helper Functions ...........................................32
+     B.2. Main TLSA Pseudocode .......................................33
+   Appendix C. Examples ..............................................35
+
+1.  Introduction
+
+1.1.  Background and Motivation
+
+   Applications that communicate over the Internet often need to prevent
+   eavesdropping, tampering, or forgery of their communications.  The
+   Transport Layer Security (TLS) protocol provides this kind of
+   communications security over the Internet, using channel encryption.
+
+   The security properties of encryption systems depend strongly on the
+   keys that they use.  If secret keys are revealed, or if public keys
+   can be replaced by fake keys (that is, a key not corresponding to the
+   entity identified in the certificate), these systems provide little
+   or no security.
+
+   TLS uses certificates to bind keys and names.  A certificate combines
+   a published key with other information such as the name of the
+   service that uses the key, and this combination is digitally signed
+   by another key.  Having a key in a certificate is only helpful if one
+   trusts the other key that signed the certificate.  If that other key
+   was itself revealed or substituted, then its signature is worthless
+   in proving anything about the first key.
+
+   On the Internet, this problem has been solved for years by entities
+   called "Certification Authorities" (CAs).  CAs protect their secret
+   key vigorously, while supplying their public key to the software
+   vendors who build TLS clients.  They then sign certificates, and
+   supply those to TLS servers.  TLS client software uses a set of these
+   CA keys as "trust anchors" to validate the signatures on certificates
+   that the client receives from TLS servers.  Client software typically
+   allows any CA to usefully sign any other certificate.
+
+   The public CA model upon which TLS has depended is fundamentally
+   vulnerable because it allows any of these CAs to issue a certificate
+   for any domain name.  A single trusted CA that betrays its trust,
+   either voluntarily or by providing less-than-vigorous protection for
+   its secrets and capabilities, can undermine the security offered by
+   any certificates employed with TLS.  This problem arises because a
+   compromised CA can issue a replacement certificate that contains a
+   fake key.  Recent experiences with compromises of CAs or their
+   trusted partners have led to very serious security problems, such as
+   the governments of multiple countries attempting to wiretap and/or
+   subvert major TLS-protected web sites trusted by millions of users.
+
+
+
+Hoffman & Schlyter           Standards Track                    [Page 3]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+   The DNS Security Extensions (DNSSEC) provide a similar model that
+   involves trusted keys signing the information for untrusted keys.
+   However, DNSSEC provides three significant improvements.  Keys are
+   tied to names in the Domain Name System (DNS), rather than to
+   arbitrary identifying strings; this is more convenient for Internet
+   protocols.  Signed keys for any domain are accessible online through
+   a straightforward query using the standard DNSSEC protocol, so there
+   is no problem distributing the signed keys.  Most significantly, the
+   keys associated with a domain name can only be signed by a key
+   associated with the parent of that domain name; for example, the keys
+   for "example.com" can only be signed by the keys for "com", and the
+   keys for "com" can only be signed by the DNS root.  This prevents an
+   untrustworthy signer from compromising anyone's keys except those in
+   their own subdomains.  Like TLS, DNSSEC relies on public keys that
+   come built into the DNSSEC client software, but these keys come only
+   from a single root domain rather than from a multiplicity of CAs.
+
+   DNS-Based Authentication of Named Entities (DANE) offers the option
+   to use the DNSSEC infrastructure to store and sign keys and
+   certificates that are used by TLS.  DANE is envisioned as a
+   preferable basis for binding public keys to DNS names, because the
+   entities that vouch for the binding of public key data to DNS names
+   are the same entities responsible for managing the DNS names in
+   question.  While the resulting system still has residual security
+   vulnerabilities, it restricts the scope of assertions that can be
+   made by any entity, consistent with the naming scope imposed by the
+   DNS hierarchy.  As a result, DANE embodies the security "principle of
+   least privilege" that is lacking in the current public CA model.
+
+1.2.  Securing the Association of a Domain Name with a Server's
+      Certificate
+
+   A TLS client begins a connection by exchanging messages with a TLS
+   server.  For many application protocols, it looks up the server's
+   name using the DNS to get an Internet Protocol (IP) address
+   associated with the name.  It then begins a connection to a
+   particular port at that address, and sends an initial message there.
+   However, the client does not yet know whether an adversary is
+   intercepting and/or altering its communication before it reaches the
+   TLS server.  It does not even know whether the real TLS server
+   associated with that domain name has ever received its initial
+   messages.
+
+   The first response from the server in TLS may contain a certificate.
+   In order for the TLS client to authenticate that it is talking to the
+   expected TLS server, the client must validate that this certificate
+   is associated with the domain name used by the client to get to the
+   server.  Currently, the client must extract the domain name from the
+
+
+
+Hoffman & Schlyter           Standards Track                    [Page 4]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+   certificate and must successfully validate the certificate, including
+   chaining to a trust anchor.
+
+   There is a different way to authenticate the association of the
+   server's certificate with the intended domain name without trusting
+   an external CA.  Given that the DNS administrator for a domain name
+   is authorized to give identifying information about the zone, it
+   makes sense to allow that administrator to also make an authoritative
+   binding between the domain name and a certificate that might be used
+   by a host at that domain name.  The easiest way to do this is to use
+   the DNS, securing the binding with DNSSEC.
+
+   There are many use cases for such functionality.  [RFC6394] lists the
+   ones to which the DNS RRtype in this document apply.  [RFC6394] also
+   lists many requirements, most of which this document is believed to
+   meet.  Section 5 covers the applicability of this document to the use
+   cases in detail.  The protocol in this document can generally be
+   referred to as the "DANE TLSA" protocol.  ("TLSA" does not stand for
+   anything; it is just the name of the RRtype.)
+
+   This document applies to both TLS [RFC5246] and Datagram TLS (DTLS)
+   [RFC6347].  In order to make the document more readable, it mostly
+   only talks about "TLS", but in all cases, it means "TLS or DTLS".
+   Although the references in this paragraph are to TLS and DTLS
+   version 1.2, the DANE TLSA protocol can also be used with earlier
+   versions of TLS and DTLS.
+
+   This document only relates to securely associating certificates for
+   TLS and DTLS with host names; retrieving certificates from DNS for
+   other protocols is handled in other documents.  For example, keys for
+   IPsec are covered in [RFC4025], and keys for Secure SHell (SSH) are
+   covered in [RFC4255].
+
+1.3.  Method for Securing Certificate Associations
+
+   A certificate association is formed from a piece of information
+   identifying a certificate and the domain name where the server
+   application runs.  The combination of a trust anchor and a domain
+   name can also be a certificate association.
+
+   A DNS query can return multiple certificate associations, such as in
+   the case of a server that is changing from one certificate to another
+   (described in more detail in Appendix A.4).
+
+   This document only applies to PKIX [RFC5280] certificates, not
+   certificates of other formats.
+
+
+
+
+
+Hoffman & Schlyter           Standards Track                    [Page 5]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+   This document defines a secure method to associate the certificate
+   that is obtained from the TLS server with a domain name using DNS;
+   the DNS information needs to be protected by DNSSEC.  Because the
+   certificate association was retrieved based on a DNS query, the
+   domain name in the query is by definition associated with the
+   certificate.  Note that this document does not cover how to associate
+   certificates with domain names for application protocols that depend
+   on SRV, NAPTR, and similar DNS resource records.  It is expected that
+   future documents will cover methods for making those associations,
+   and those documents may or may not need to update this one.
+
+   DNSSEC, which is defined in [RFC4033], [RFC4034], and [RFC4035], uses
+   cryptographic keys and digital signatures to provide authentication
+   of DNS data.  Information that is retrieved from the DNS and that is
+   validated using DNSSEC is thereby proved to be the authoritative
+   data.  The DNSSEC signature needs to be validated on all responses
+   that use DNSSEC in order to assure the proof of origin of the data.
+
+   This document does not specify how DNSSEC validation occurs because
+   there are many different proposals for how a client might get
+   validated DNSSEC results, such as from a DNSSEC-aware resolver that
+   is coded in the application, from a trusted DNSSEC resolver on the
+   machine on which the application is running, or from a trusted DNSSEC
+   resolver with which the application is communicating over an
+   authenticated and integrity-protected channel or network.  This is
+   described in more detail in Section 7 of [RFC4033].
+
+   This document only relates to getting the DNS information for the
+   certificate association securely using DNSSEC; other secure DNS
+   mechanisms are out of scope.
+
+1.4.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+   This document also makes use of standard PKIX, DNSSEC, TLS, and DNS
+   terminology.  See [RFC5280], [RFC4033], [RFC5246], and STD 13
+   [RFC1034] [RFC1035], respectively, for these terms.  In addition,
+   terms related to TLS-protected application services and DNS names are
+   taken from [RFC6125].
+
+
+
+
+
+
+
+
+
+Hoffman & Schlyter           Standards Track                    [Page 6]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+2.  The TLSA Resource Record
+
+   The TLSA DNS resource record (RR) is used to associate a TLS server
+   certificate or public key with the domain name where the record is
+   found, thus forming a "TLSA certificate association".  The semantics
+   of how the TLSA RR is interpreted are given later in this document.
+
+   The type value for the TLSA RR type is defined in Section 7.1.
+
+   The TLSA RR is class independent.
+
+   The TLSA RR has no special Time to Live (TTL) requirements.
+
+2.1.  TLSA RDATA Wire Format
+
+   The RDATA for a TLSA RR consists of a one-octet certificate usage
+   field, a one-octet selector field, a one-octet matching type field,
+   and the certificate association data field.
+
+                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Cert. Usage  |   Selector    | Matching Type |               /
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               /
+   /                                                               /
+   /                 Certificate Association Data                  /
+   /                                                               /
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+2.1.1.  The Certificate Usage Field
+
+   A one-octet value, called "certificate usage", specifies the provided
+   association that will be used to match the certificate presented in
+   the TLS handshake.  This value is defined in a new IANA registry (see
+   Section 7.2) in order to make it easier to add additional certificate
+   usages in the future.  The certificate usages defined in this
+   document are:
+
+      0 -- Certificate usage 0 is used to specify a CA certificate, or
+      the public key of such a certificate, that MUST be found in any of
+      the PKIX certification paths for the end entity certificate given
+      by the server in TLS.  This certificate usage is sometimes
+      referred to as "CA constraint" because it limits which CA can be
+      used to issue certificates for a given service on a host.  The
+      presented certificate MUST pass PKIX certification path
+      validation, and a CA certificate that matches the TLSA record MUST
+      be included as part of a valid certification path.  Because this
+      certificate usage allows both trust anchors and CA certificates,
+
+
+
+Hoffman & Schlyter           Standards Track                    [Page 7]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+      the certificate might or might not have the basicConstraints
+      extension present.
+
+      1 -- Certificate usage 1 is used to specify an end entity
+      certificate, or the public key of such a certificate, that MUST be
+      matched with the end entity certificate given by the server in
+      TLS.  This certificate usage is sometimes referred to as "service
+      certificate constraint" because it limits which end entity
+      certificate can be used by a given service on a host.  The target
+      certificate MUST pass PKIX certification path validation and MUST
+      match the TLSA record.
+
+      2 -- Certificate usage 2 is used to specify a certificate, or the
+      public key of such a certificate, that MUST be used as the trust
+      anchor when validating the end entity certificate given by the
+      server in TLS.  This certificate usage is sometimes referred to as
+      "trust anchor assertion" and allows a domain name administrator to
+      specify a new trust anchor -- for example, if the domain issues
+      its own certificates under its own CA that is not expected to be
+      in the end users' collection of trust anchors.  The target
+      certificate MUST pass PKIX certification path validation, with any
+      certificate matching the TLSA record considered to be a trust
+      anchor for this certification path validation.
+
+      3 -- Certificate usage 3 is used to specify a certificate, or the
+      public key of such a certificate, that MUST match the end entity
+      certificate given by the server in TLS.  This certificate usage is
+      sometimes referred to as "domain-issued certificate" because it
+      allows for a domain name administrator to issue certificates for a
+      domain without involving a third-party CA.  The target certificate
+      MUST match the TLSA record.  The difference between certificate
+      usage 1 and certificate usage 3 is that certificate usage 1
+      requires that the certificate pass PKIX validation, but PKIX
+      validation is not tested for certificate usage 3.
+
+   The certificate usages defined in this document explicitly only apply
+   to PKIX-formatted certificates in DER encoding [X.690].  If TLS
+   allows other formats later, or if extensions to this RRtype are made
+   that accept other formats for certificates, those certificates will
+   need their own certificate usage values.
+
+2.1.2.  The Selector Field
+
+   A one-octet value, called "selector", specifies which part of the TLS
+   certificate presented by the server will be matched against the
+   association data.  This value is defined in a new IANA registry (see
+   Section 7.3).  The selectors defined in this document are:
+
+
+
+
+Hoffman & Schlyter           Standards Track                    [Page 8]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+      0 -- Full certificate: the Certificate binary structure as defined
+      in [RFC5280]
+
+      1 -- SubjectPublicKeyInfo: DER-encoded binary structure as defined
+      in [RFC5280]
+
+   (Note that the use of "selector" in this document is completely
+   unrelated to the use of "selector" in DomainKeys Identified Mail
+   (DKIM) [RFC6376].)
+
+2.1.3.  The Matching Type Field
+
+   A one-octet value, called "matching type", specifies how the
+   certificate association is presented.  This value is defined in a new
+   IANA registry (see Section 7.4).  The types defined in this document
+   are:
+
+      0 -- Exact match on selected content
+
+      1 -- SHA-256 hash of selected content [RFC6234]
+
+      2 -- SHA-512 hash of selected content [RFC6234]
+
+   If the TLSA record's matching type is a hash, having the record use
+   the same hash algorithm that was used in the signature in the
+   certificate (if possible) will assist clients that support a small
+   number of hash algorithms.
+
+2.1.4.  The Certificate Association Data Field
+
+   This field specifies the "certificate association data" to be
+   matched.  These bytes are either raw data (that is, the full
+   certificate or its SubjectPublicKeyInfo, depending on the selector)
+   for matching type 0, or the hash of the raw data for matching types 1
+   and 2.  The data refers to the certificate in the association, not to
+   the TLS ASN.1 Certificate object.
+
+2.2.  TLSA RR Presentation Format
+
+   The presentation format of the RDATA portion (as defined in
+   [RFC1035]) is as follows:
+
+   o  The certificate usage field MUST be represented as an 8-bit
+      unsigned integer.
+
+   o  The selector field MUST be represented as an 8-bit unsigned
+      integer.
+
+
+
+
+Hoffman & Schlyter           Standards Track                    [Page 9]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+   o  The matching type field MUST be represented as an 8-bit unsigned
+      integer.
+
+   o  The certificate association data field MUST be represented as a
+      string of hexadecimal characters.  Whitespace is allowed within
+      the string of hexadecimal characters, as described in [RFC1035].
+
+2.3.  TLSA RR Examples
+
+   In the following examples, the domain name is formed using the rules
+   in Section 3.
+
+   An example of a hashed (SHA-256) association of a PKIX CA
+   certificate:
+
+   _443._tcp.www.example.com. IN TLSA (
+      0 0 1 d2abde240d7cd3ee6b4b28c54df034b9
+            7983a1d16e8a410e4561cb106618e971 )
+
+   An example of a hashed (SHA-512) subject public key association of a
+   PKIX end entity certificate:
+
+   _443._tcp.www.example.com. IN TLSA (
+      1 1 2 92003ba34942dc74152e2f2c408d29ec
+            a5a520e7f2e06bb944f4dca346baf63c
+            1b177615d466f6c4b71c216a50292bd5
+            8c9ebdd2f74e38fe51ffd48c43326cbc )
+
+   An example of a full certificate association of a PKIX end entity
+   certificate:
+
+   _443._tcp.www.example.com. IN TLSA (
+      3 0 0 30820307308201efa003020102020... )
+
+3.  Domain Names for TLSA Certificate Associations
+
+   Unless there is a protocol-specific specification that is different
+   than this one, TLSA resource records are stored at a prefixed DNS
+   domain name.  The prefix is prepared in the following manner:
+
+   1.  The decimal representation of the port number on which a TLS-
+       based service is assumed to exist is prepended with an underscore
+       character ("_") to become the left-most label in the prepared
+       domain name.  This number has no leading zeros.
+
+
+
+
+
+
+
+Hoffman & Schlyter           Standards Track                   [Page 10]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+   2.  The protocol name of the transport on which a TLS-based service
+       is assumed to exist is prepended with an underscore character
+       ("_") to become the second left-most label in the prepared domain
+       name.  The transport names defined for this protocol are "tcp",
+       "udp", and "sctp".
+
+   3.  The base domain name is appended to the result of step 2 to
+       complete the prepared domain name.  The base domain name is the
+       fully qualified DNS domain name [RFC1035] of the TLS server, with
+       the additional restriction that every label MUST meet the rules
+       of [RFC0952].  The latter restriction means that, if the query is
+       for an internationalized domain name, it MUST use the A-label
+       form as defined in [RFC5890].
+
+   For example, to request a TLSA resource record for an HTTP server
+   running TLS on port 443 at "www.example.com",
+   "_443._tcp.www.example.com" is used in the request.  To request a
+   TLSA resource record for an SMTP server running the STARTTLS protocol
+   on port 25 at "mail.example.com", "_25._tcp.mail.example.com" is
+   used.
+
+4.  Use of TLSA Records in TLS
+
+   Section 2.1 of this document defines the mandatory matching rules for
+   the data from the TLSA certificate associations and the certificates
+   received from the TLS server.
+
+   The TLS session that is to be set up MUST be for the specific port
+   number and transport name that was given in the TLSA query.
+
+   Some specifications for applications that run over TLS, such as
+   [RFC2818] for HTTP, require that the server's certificate have a
+   domain name that matches the host name expected by the client.  Some
+   specifications, such as [RFC6125], detail how to match the identity
+   given in a PKIX certificate with those expected by the user.
+
+   If a TLSA record has certificate usage 2, the corresponding TLS
+   server SHOULD send the certificate that is referenced just like it
+   currently sends intermediate certificates.
+
+4.1.  Usable Certificate Associations
+
+   An implementation of this protocol makes a DNS query for TLSA
+   records, validates these records using DNSSEC, and uses the resulting
+   TLSA records and validation status to modify its responses to the TLS
+   server.
+
+
+
+
+
+Hoffman & Schlyter           Standards Track                   [Page 11]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+   Determining whether a TLSA RRSet can be used MUST be based on the
+   DNSSEC validation state (as defined in [RFC4033]).
+
+   o  A TLSA RRSet whose DNSSEC validation state is secure MUST be used
+      as a certificate association for TLS unless a local policy would
+      prohibit the use of the specific certificate association in the
+      secure TLSA RRSet.
+
+   o  If the DNSSEC validation state on the response to the request for
+      the TLSA RRSet is bogus, this MUST cause TLS not to be started or,
+      if the TLS negotiation is already in progress, MUST cause the
+      connection to be aborted.
+
+   o  A TLSA RRSet whose DNSSEC validation state is indeterminate or
+      insecure cannot be used for TLS and MUST be considered unusable.
+
+   Clients that validate the DNSSEC signatures themselves MUST use
+   standard DNSSEC validation procedures.  Clients that rely on another
+   entity to perform the DNSSEC signature validation MUST use a secure
+   mechanism between themselves and the validator.  Examples of secure
+   transports to other hosts include TSIG [RFC2845], SIG(0) [RFC2931],
+   and IPsec [RFC6071].  Note that it is not sufficient to use secure
+   transport to a DNS resolver that does not do DNSSEC signature
+   validation.  See Section 8.3 for more security considerations related
+   to external validators.
+
+   If a certificate association contains a certificate usage, selector,
+   or matching type that is not understood by the TLS client, that
+   certificate association MUST be considered unusable.  If the
+   comparison data for a certificate is malformed, the certificate
+   association MUST be considered unusable.
+
+   If a certificate association contains a matching type or certificate
+   association data that uses a cryptographic algorithm that is
+   considered too weak for the TLS client's policy, the certificate
+   association MUST be considered unusable.
+
+   If an application receives zero usable certificate associations from
+   a DNS request or from its cache, it processes TLS in the normal
+   fashion without any input from the TLSA records.  If an application
+   receives one or more usable certificate associations, it attempts to
+   match each certificate association with the TLS server's end entity
+   certificate until a successful match is found.  During the TLS
+   handshake, if none of the certificate associations matches the
+   certificate given by the TLS server, the TLS client MUST abort the
+   handshake.
+
+
+
+
+
+Hoffman & Schlyter           Standards Track                   [Page 12]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+   An attacker who is able to divert a user to a server under his
+   control is also likely to be able to block DNS requests from the user
+   or DNS responses being sent to the user.  Thus, in order to achieve
+   any security benefit from certificate usage 0 or 1, an application
+   that sends a request for TLSA records needs to get either a valid
+   signed response containing TLSA records or verification that the
+   domain is insecure or indeterminate.  If a request for a TLSA record
+   does not meet one of those two criteria but the application continues
+   with the TLS handshake anyway, the application has gotten no benefit
+   from TLSA and SHOULD NOT make any internal or external indication
+   that TLSA was applied.  If an application has a configuration setting
+   that has turned on TLSA use, or has any indication that TLSA is in
+   use (regardless of whether or not this is configurable), that
+   application either MUST NOT start a TLS connection or it MUST abort a
+   TLS handshake if both of the two criteria above are not met.
+
+   The application can perform the TLSA lookup before initiating the TLS
+   handshake, or do it during the TLS handshake: the choice is up to the
+   client.
+
+5.  TLSA and DANE Use Cases and Requirements
+
+   The different types of certificate associations defined in TLSA are
+   matched with various sections of [RFC6394].  The use cases from
+   Section 3 of [RFC6394] are covered in this document as follows:
+
+   3.1 CA Constraints -- Implemented using certificate usage 0.
+
+   3.2 Certificate Constraints -- Implemented using certificate usage 1.
+
+   3.3 Trust Anchor Assertion and Domain-Issued Certificates --
+      Implemented using certificate usages 2 and 3, respectively.
+
+   The requirements from Section 4 of [RFC6394] are covered in this
+   document as follows:
+
+   Multiple Ports -- The TLSA records for different application services
+      running on a single host can be distinguished through the service
+      name and port number prefixed to the host name (see Section 3).
+
+   No Downgrade -- Section 4 specifies the conditions under which a
+      client can process and act upon TLSA records.  Specifically, if
+      the DNSSEC status for the TLSA resource record set is determined
+      to be bogus, the TLS connection (if started) will fail.
+
+   Encapsulation -- Encapsulation is covered in the TLSA response
+      semantics.
+
+
+
+
+Hoffman & Schlyter           Standards Track                   [Page 13]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+   Predictability -- The appendices of this specification provide
+      operational considerations and implementation guidance in order to
+      enable application developers to form a consistent interpretation
+      of the recommended client behavior.
+
+   Opportunistic Security -- If a client conformant to this
+      specification can reliably determine the presence of a TLSA
+      record, it will attempt to use this information.  Conversely, if a
+      client can reliably determine the absence of any TLSA record, it
+      will fall back to processing TLS in the normal fashion.  This is
+      discussed in Section 4.
+
+   Combination -- Multiple TLSA records can be published for a given
+      host name, thus enabling the client to construct multiple TLSA
+      certificate associations that reflect different assertions.  No
+      support is provided to combine two TLSA certificate associations
+      in a single operation.
+
+   Roll-over -- TLSA records are processed in the normal manner within
+      the scope of the DNS protocol, including the TTL expiration of the
+      records.  This ensures that clients will not latch onto assertions
+      made by expired TLSA records, and will be able to transition from
+      using one public key or certificate usage to another.
+
+   Simple Key Management -- The SubjectPublicKeyInfo selector in the
+      TLSA record provides a mode that enables a domain holder to only
+      have to maintain a single long-lived public/private key pair
+      without the need to manage certificates.  Appendix A outlines the
+      usefulness and the potential downsides to using this mode.
+
+   Minimal Dependencies -- This specification relies on DNSSEC to
+      protect the origin authenticity and integrity of the TLSA resource
+      record set.  Additionally, if DNSSEC validation is not performed
+      on the system that wishes to use TLSA certificate bindings, this
+      specification requires that the "last mile" be over a secure
+      transport.  There are no other deployment dependencies for this
+      approach.
+
+   Minimal Options -- The operating modes map precisely to the DANE use
+      cases and requirements.  DNSSEC use is mandatory in that this
+      specification encourages applications to use only those TLSA
+      records that are shown to be validated.
+
+   Wildcards -- Wildcards are covered in a limited manner in the TLSA
+      request syntax; see Appendix A.
+
+   Redirection -- Redirection is covered in the TLSA request syntax; see
+      Appendix A.
+
+
+
+Hoffman & Schlyter           Standards Track                   [Page 14]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+6.  Mandatory-to-Implement Features
+
+   TLS clients conforming to this specification MUST be able to
+   correctly interpret TLSA records with certificate usages 0, 1, 2,
+   and 3.  TLS clients conforming to this specification MUST be able to
+   compare a certificate association with a certificate from the TLS
+   handshake using selector types 0 and 1, and matching type 0 (no hash
+   used) and matching type 1 (SHA-256), and SHOULD be able to make such
+   comparisons with matching type 2 (SHA-512).
+
+7.  IANA Considerations
+
+   IANA has made the assignments in this section.
+
+   In the following sections, "RFC Required" was chosen for TLSA
+   certificate usages and "Specification Required" for selectors and
+   matching types because of the amount of detail that is likely to be
+   needed for implementers to correctly implement new certificate usages
+   as compared to new selectors and matching types.
+
+7.1.  TLSA RRtype
+
+   This document uses a new DNS RR type, TLSA, whose value (52) was
+   allocated by IANA from the Resource Record (RR) TYPEs subregistry of
+   the Domain Name System (DNS) Parameters registry.
+
+7.2.  TLSA Certificate Usages
+
+   This document creates a new registry, "TLSA Certificate Usages".  The
+   registry policy is "RFC Required".  The initial entries in the
+   registry are:
+
+   Value    Short description                       Reference
+   ----------------------------------------------------------
+   0        CA constraint                           RFC 6698
+   1        Service certificate constraint          RFC 6698
+   2        Trust anchor assertion                  RFC 6698
+   3        Domain-issued certificate               RFC 6698
+   4-254    Unassigned
+   255      Private use
+
+   Applications to the registry can request specific values that have
+   yet to be assigned.
+
+
+
+
+
+
+
+
+Hoffman & Schlyter           Standards Track                   [Page 15]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+7.3.  TLSA Selectors
+
+   This document creates a new registry, "TLSA Selectors".  The registry
+   policy is "Specification Required".  The initial entries in the
+   registry are:
+
+   Value    Short description                       Reference
+   ----------------------------------------------------------
+   0        Full certificate                        RFC 6698
+   1        SubjectPublicKeyInfo                    RFC 6698
+   2-254    Unassigned
+   255      Private use
+
+   Applications to the registry can request specific values that have
+   yet to be assigned.
+
+7.4.  TLSA Matching Types
+
+   This document creates a new registry, "TLSA Matching Types".  The
+   registry policy is "Specification Required".  The initial entries in
+   the registry are:
+
+   Value    Short description                       Reference
+   ----------------------------------------------------------
+   0        No hash used                            RFC 6698
+   1        SHA-256                                 RFC 6234
+   2        SHA-512                                 RFC 6234
+   3-254    Unassigned
+   255      Private use
+
+   Applications to the registry can request specific values that have
+   yet to be assigned.
+
+8.  Security Considerations
+
+   The security of the DNS RRtype described in this document relies on
+   the security of DNSSEC to verify that the TLSA record has not been
+   altered.
+
+   A rogue DNS administrator who changes the A, AAAA, and/or TLSA
+   records for a domain name can cause the client to go to an
+   unauthorized server that will appear authorized, unless the client
+   performs PKIX certification path validation and rejects the
+   certificate.  That administrator could probably get a certificate
+   issued by some CA anyway, so this is not an additional threat.
+
+
+
+
+
+
+Hoffman & Schlyter           Standards Track                   [Page 16]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+   If the authentication mechanism for adding or changing TLSA data in a
+   zone is weaker than the authentication mechanism for changing the A
+   and/or AAAA records, a man-in-the-middle who can redirect traffic to
+   his site may be able to impersonate the attacked host in TLS if he
+   can use the weaker authentication mechanism.  A better design for
+   authenticating DNS would be to have the same level of authentication
+   used for all DNS additions and changes for a particular domain name.
+
+   Secure Socket Layer (SSL) proxies can sometimes act as a man-in-the-
+   middle for TLS clients.  In these scenarios, the clients add a new
+   trust anchor whose private key is kept on the SSL proxy; the proxy
+   intercepts TLS requests, creates a new TLS session with the intended
+   host, and sets up a TLS session with the client using a certificate
+   that chains to the trust anchor installed in the client by the proxy.
+   In such environments, using TLSA records will prevent the SSL proxy
+   from functioning as expected because the TLS client will get a
+   certificate association from the DNS that will not match the
+   certificate that the SSL proxy uses with the client.  The client,
+   seeing the proxy's new certificate for the supposed destination, will
+   not set up a TLS session.
+
+   Client treatment of any information included in the trust anchor is a
+   matter of local policy.  This specification does not mandate that
+   such information be inspected or validated by the server's domain
+   name administrator.
+
+   If a server's certificate is revoked, or if an intermediate CA in a
+   chain between the server and a trust anchor has its certificate
+   revoked, a TLSA record with a certificate usage of 2 that matches the
+   revoked certificate would in essence override the revocation because
+   the client would treat that revoked certificate as a trust anchor and
+   thus not check its revocation status.  Because of this, domain
+   administrators need to be responsible for being sure that the keys or
+   certificates used in TLSA records with a certificate usage of 2 are
+   in fact able to be used as reliable trust anchors.
+
+   Certificates that are delivered in TLSA with certificate usage 2
+   fundamentally change the way the TLS server's end entity certificate
+   is evaluated.  For example, the server's certificate might chain to
+   an existing CA through an intermediate CA that has certain policy
+   restrictions, and the certificate would not pass those restrictions
+   and thus normally be rejected.  That intermediate CA could issue
+   itself a new certificate without the policy restrictions and tell its
+   customers to use that certificate with certificate usage 2.  This in
+   essence allows an intermediate CA to become a trust anchor for
+   certificates that the end user might have expected to chain to an
+   existing trust anchor.
+
+
+
+
+Hoffman & Schlyter           Standards Track                   [Page 17]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+   If an administrator wishes to stop using a TLSA record, the
+   administrator can simply remove it from the DNS.  Normal clients will
+   stop using the TLSA record after the TTL has expired.  Replay attacks
+   against the TLSA record are not possible after the expiration date on
+   the RRsig of the TLSA record that was removed.
+
+   Generators of TLSA records should be aware that the client's full
+   trust of a certificate association retrieved from a TLSA record may
+   be a matter of local policy.  While such trust is limited to the
+   specific domain name, protocol, and port for which the TLSA query was
+   made, local policy may decline to accept the certificate (for reasons
+   such as weak cryptography), as is also the case with PKIX trust
+   anchors.
+
+8.1.  Comparing DANE to Public CAs
+
+   As stated above, the security of the DNS RRtype described in this
+   document relies on the security of DNSSEC to verify that the TLSA
+   record has not been altered.  This section describes where the
+   security of public CAs and the security of TLSA are similar and
+   different.  This section applies equally to other security-related
+   DNS RRtypes such as keys for IPsec and SSH.
+
+   DNSSEC forms certificates (the binding of an identity to a key) by
+   combining a DNSKEY, DS, or DLV resource record with an associated
+   RRSIG record.  These records then form a signing chain extending from
+   the client's trust anchors to the RR of interest.
+
+   Although the DNSSEC protocol does not enforce it, DNSKEYs are often
+   marked with a SEP flag indicating whether the key is a Zone Signing
+   Key (ZSK) or a Key Signing Key (KSK).  ZSKs protect records in the
+   zone (including DS and DLV records), and KSKs protect ZSK DNSKEY
+   records.  This allows KSKs to be stored offline.
+
+   The TLSA RRtype allows keys from the DNSSEC PKI hierarchy to
+   authenticate keys wrapped in PKIX certificates for a particular host
+   name, protocol, and port.
+
+   With the exception of the DLV RRtype, all of these certificates
+   constrain the keys they identify to names that are within the zone
+   signing the certificate.  In order for a domain's DLV resource
+   records to be honored, the domain must be configured as a DLV domain,
+   and the domain's DNSKEYs must be configured as trust anchors or be
+   authentic [RFC5074].
+
+
+
+
+
+
+
+Hoffman & Schlyter           Standards Track                   [Page 18]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+8.1.1.  Risk of Key Compromise
+
+   The risk that a given certificate that has a valid signing chain is
+   fake is related to the number of keys that can contribute to the
+   validation of the certificate, the quality of protection each private
+   key receives, the value of each key to an attacker, and the value of
+   falsifying the certificate.
+
+   DNSSEC allows any set of domains to be configured as trust anchors
+   and/or DLVs, but most clients are likely to use the root zone as
+   their only trust anchor.  Also, because a given DNSKEY can only sign
+   resource records for that zone, the number of private keys capable of
+   compromising a given TLSA resource record is limited to the number of
+   zones between the TLSA resource record and the nearest trust anchor,
+   plus any configured DLV domains.  Typically, this will be six keys,
+   half of which will be KSKs.
+
+   PKIX only describes how to validate a certificate based on a client-
+   chosen set of trust anchors, but says nothing about how many trust
+   anchors to use or how they should be constrained.  As currently
+   deployed, most PKIX clients use a large number of trust anchors
+   provided with the client or operating system software.  These trust
+   anchors are selected carefully, but with a desire for broad
+   interoperability.  The trust anchors and CA certificates for public
+   CAs rarely have name constraints applied.
+
+   A combination of technical protections, process controls, and
+   personnel experience contribute to the quality of security that keys
+   receive.
+
+   o  The security surrounding DNSSEC DNSKEYs varies significantly.  The
+      KSK/ZSK split allows the KSK to be stored offline and protected
+      more carefully than the ZSK, but not all domains do so.  The
+      security applied to a zone's DNSKEYs should be proportional to the
+      value of the domain, but that is difficult to estimate.  For
+      example, the root DNSKEY has protections and controls comparable
+      to or exceeding those of public CAs.  On the other end of the
+      spectrum, small domains might provide no more protection to their
+      keys than they do to their other data.
+
+   o  The security surrounding public CAs also varies.  However, due to
+      financial incentives and standards imposed by clients for
+      acceptance into their trust anchor stores, CAs generally employ
+      security experts and protect their keys carefully, though highly
+      public compromises have occurred.
+
+
+
+
+
+
+Hoffman & Schlyter           Standards Track                   [Page 19]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+8.1.2.  Impact of Key Compromise
+
+   The impact of a key compromise differs significantly between the two
+   models.
+
+   o  DNSKEYs are inherently limited in what they can sign, so a
+      compromise of the DNSKEY for "example.com" provides no avenue of
+      attack against "example.org".  Even the impact of a compromise of
+      .com's DNSKEY, while considerable, would be limited to .com
+      domains.  Only the compromise of the root DNSKEY would have the
+      equivalent impact of an unconstrained public CA.
+
+   o  Public CAs are not typically constrained in what names they can
+      sign, and therefore a compromise of even one CA allows the
+      attacker to generate a certificate for any name in the DNS.  A
+      domain holder can get a certificate from any willing CA, or even
+      multiple CAs simultaneously, making it impossible for a client to
+      determine whether the certificate it is validating is legitimate
+      or fraudulent.
+
+   Because a TLSA certificate association is constrained to its
+   associated name, protocol, and port, the PKIX certificate is
+   similarly constrained, even if its public CAs signing the certificate
+   (if any) are not.
+
+8.1.3.  Detection of Key Compromise
+
+   If a key is compromised, rapid and reliable detection is important in
+   order to limit the impact of the compromise.  In this regard, neither
+   model prevents an attacker from near-invisibly attacking their
+   victim, provided that the necessary keys are compromised.
+
+   If a public CA is compromised, only the victim will see the
+   fraudulent certificate, as there is typically no publicly accessible
+   directory of all the certificates issued by a CA that can be
+   inspected.  DNS resource records are typically published publicly.
+   However, the attacker could also allow the uncompromised records to
+   be published to the Internet as usual but provide a compromised DNS
+   view to the victim to achieve the same effect.
+
+8.1.4.  Spoofing Hostnames
+
+   Some CAs implement technical controls to ensure that certificates are
+   not issued to domains with names similar to domains that are popular
+   and prone to attack.  Of course, an attacker can attempt to
+   circumvent this restriction by finding a CA willing to issue the
+   certificate anyway.  However, by using DNSSEC and TLSA, the attacker
+   can circumvent this check completely.
+
+
+
+Hoffman & Schlyter           Standards Track                   [Page 20]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+8.2.  DNS Caching
+
+   Implementations of this protocol rely heavily on the DNS, and are
+   thus prone to security attacks based on the deliberate
+   mis-association of TLSA records and DNS names.  Implementations need
+   to be cautious in assuming the continuing validity of an association
+   between a TLSA record and a DNS name.
+
+   In particular, implementations SHOULD rely on their DNS resolver for
+   confirmation of an association between a TLSA record and a DNS name,
+   rather than caching the result of previous domain name lookups.  Many
+   platforms already can cache domain name lookups locally when
+   appropriate, and they SHOULD be configured to do so.  It is proper
+   for these lookups to be cached, however, only when the TTL (Time To
+   Live) information reported by the DNS makes it likely that the cached
+   information will remain useful.
+
+   If implementations cache the results of domain name lookups in order
+   to achieve a performance improvement, they MUST observe the TTL
+   information reported by DNS.  Implementations that fail to follow
+   this rule could be spoofed or have access denied when a previously
+   accessed server's TLSA record changes, such as during a certificate
+   rollover.
+
+8.3.  External DNSSEC Validators
+
+   Due to a lack of DNSSEC support in the most commonly deployed stub
+   resolvers today, some ISPs have begun checking DNSSEC in the
+   recursive resolvers they provide to their customers, setting the
+   Authentic Data (AD) flag as appropriate.  DNSSEC-aware clients could
+   use that data, ignoring the fact that the DNSSEC data has been
+   validated externally.  Because there is typically no authentication
+   of the recursive resolver or integrity protection of the data and AD
+   flag between the client and the recursive resolver, this can be
+   trivially spoofed by an attacker.
+
+   However, even with secure communications between a host and the
+   external validating resolver, there is a risk that the external
+   validator could become compromised.  Nothing prevents a compromised
+   external DNSSEC validator from claiming that all the records it
+   provides are secure, even if the data is falsified, unless the client
+   checks the DNSSEC data itself (rendering the external validator
+   unnecessary).
+
+   For this reason, DNSSEC validation is best performed on-host, even
+   when a secure path to an external validator is available.
+
+
+
+
+
+Hoffman & Schlyter           Standards Track                   [Page 21]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+9.  Acknowledgements
+
+   Many of the ideas in this document have been discussed over many
+   years.  More recently, the ideas have been discussed by the authors
+   and others in a more focused fashion.  In particular, some of the
+   ideas and words here originated with Paul Vixie, Dan Kaminsky, Jeff
+   Hodges, Phillip Hallam-Baker, Simon Josefsson, Warren Kumari, Adam
+   Langley, Ben Laurie, Ilari Liusvaara, Ondrej Mikle, Scott Schmit,
+   Ondrej Sury, Richard Barnes, Jim Schaad, Stephen Farrell, Suresh
+   Krishnaswamy, Peter Palfrader, Pieter Lexis, Wouter Wijngaards, John
+   Gilmore, and Murray Kucherawy.
+
+   This document has also been greatly helped by many active
+   participants of the DANE Working Group.
+
+10.  References
+
+10.1.  Normative References
+
+   [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.
+
+   [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.
+
+   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
+              (TLS) Protocol Version 1.2", RFC 5246, August 2008.
+
+   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
+              Housley, R., and W. Polk, "Internet X.509 Public Key
+              Infrastructure Certificate and Certificate Revocation List
+              (CRL) Profile", RFC 5280, May 2008.
+
+
+
+
+Hoffman & Schlyter           Standards Track                   [Page 22]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+   [RFC6125]  Saint-Andre, P. and J. Hodges, "Representation and
+              Verification of Domain-Based Application Service Identity
+              within Internet Public Key Infrastructure Using X.509
+              (PKIX) Certificates in the Context of Transport Layer
+              Security (TLS)", RFC 6125, March 2011.
+
+   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
+              Security Version 1.2", RFC 6347, January 2012.
+
+10.2.  Informative References
+
+   [RFC0952]  Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet
+              host table specification", RFC 952, October 1985.
+
+   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
+              specifying the location of services (DNS SRV)", RFC 2782,
+              February 2000.
+
+   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
+
+   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
+              Wellington, "Secret Key Transaction Authentication for DNS
+              (TSIG)", RFC 2845, May 2000.
+
+   [RFC2931]  Eastlake 3rd, D., "DNS Request and Transaction Signatures
+              ( SIG(0)s)", RFC 2931, September 2000.
+
+   [RFC4025]  Richardson, M., "A Method for Storing IPsec Keying
+              Material in DNS", RFC 4025, March 2005.
+
+   [RFC4255]  Schlyter, J. and W. Griffin, "Using DNS to Securely
+              Publish Secure Shell (SSH) Key Fingerprints", RFC 4255,
+              January 2006.
+
+   [RFC4641]  Kolkman, O. and R. Gieben, "DNSSEC Operational Practices",
+              RFC 4641, September 2006.
+
+   [RFC5074]  Weiler, S., "DNSSEC Lookaside Validation (DLV)", RFC 5074,
+              November 2007.
+
+   [RFC5890]  Klensin, J., "Internationalized Domain Names for
+              Applications (IDNA): Definitions and Document Framework",
+              RFC 5890, August 2010.
+
+   [RFC6066]  Eastlake 3rd, D., "Transport Layer Security (TLS)
+              Extensions: Extension Definitions", RFC 6066,
+              January 2011.
+
+
+
+
+Hoffman & Schlyter           Standards Track                   [Page 23]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+   [RFC6071]  Frankel, S. and S. Krishnan, "IP Security (IPsec) and
+              Internet Key Exchange (IKE) Document Roadmap", RFC 6071,
+              February 2011.
+
+   [RFC6234]  Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
+              (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011.
+
+   [RFC6376]  Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
+              "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376,
+              September 2011.
+
+   [RFC6394]  Barnes, R., "Use Cases and Requirements for DNS-Based
+              Authentication of Named Entities (DANE)", RFC 6394,
+              October 2011.
+
+   [X.690]    "Recommendation ITU-T X.690 (2002) | ISO/IEC 8825-1:2002,
+              Information technology - ASN.1 encoding rules:
+              Specification of Basic Encoding Rules (BER), Canonical
+              Encoding Rules (CER) and Distinguished Encoding Rules
+              (DER)", July 2002.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman & Schlyter           Standards Track                   [Page 24]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+Appendix A.  Operational Considerations for Deploying TLSA Records
+
+A.1.  Creating TLSA Records
+
+   When creating TLSA records, care must be taken to avoid
+   misconfigurations.  Section 4 of this document states that a TLSA
+   RRSet whose validation state is secure MUST be used.  This means that
+   the existence of such a RRSet effectively disables other forms of
+   name and path validation.  A misconfigured TLSA RRSet will
+   effectively disable access to the TLS server for all conforming
+   clients, and this document does not provide any means of making a
+   gradual transition to using TLSA.
+
+   When creating TLSA records with certificate usage 0 (CA certificate)
+   or usage 2 (trust anchor), one needs to understand the implications
+   when choosing between selector type 0 (Full certificate) and 1
+   (SubjectPublicKeyInfo).  A careful choice is required because
+   different methods for building trust chains are used by different TLS
+   clients.  The following outlines the cases that one ought to be aware
+   of and discusses the implications of the choice of selector type.
+
+   Certificate usage 2 is not affected by the different types of chain
+   building when the end entity certificate is the same as the trust
+   anchor certificate.
+
+A.1.1.  Ambiguities and Corner Cases When TLS Clients Build Trust Chains
+
+   TLS clients can implement their own chain-building code rather than
+   rely on the chain presented by the TLS server.  This means that,
+   except for the end entity certificate, any certificate presented in
+   the suggested chain might or might not be present in the final chain
+   built by the client.
+
+   Certificates that the client can use to replace certificates from the
+   original chain include:
+
+   o  Client's trust anchors
+
+   o  Certificates cached locally
+
+   o  Certificates retrieved from a URI listed in an Authority
+      Information Access X.509v3 extension
+
+   CAs frequently reissue certificates with different validity periods,
+   signature algorithms (such as a different hash algorithm in the
+   signature algorithm), CA key pairs (such as for a cross-certificate),
+
+
+
+
+
+Hoffman & Schlyter           Standards Track                   [Page 25]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+   or PKIX extensions where the public key and subject remain the same.
+   These reissued certificates are the certificates that the TLS client
+   can use in place of an original certificate.
+
+   Clients are known to exchange or remove certificates that could cause
+   TLSA certificate associations that rely on the full certificate to
+   fail.  For example:
+
+   o  The client considers the signature algorithm of a certificate to
+      no longer be sufficiently secure.
+
+   o  The client might not have an associated root certificate in its
+      trust store and instead uses a cross-certificate with an identical
+      subject and public key.
+
+A.1.2.  Choosing a Selector Type
+
+   In this section, "false-negative failure" means that a client will
+   not accept the TLSA certificate association for a certificate
+   designated by the DNS administrator.  Also, "false-positive
+   acceptance" means that the client accepts a TLSA association for a
+   certificate that is not designated by the DNS administrator.
+
+A.1.2.1.  Selector Type 0 (Full Certificate)
+
+   The "Full certificate" selector provides the most precise
+   specification of a TLSA certificate association, capturing all
+   fields of the PKIX certificate.  For a DNS administrator, the best
+   course to avoid false-negative failures in the client when using this
+   selector is:
+
+   1.  If a CA issued a replacement certificate, don't associate to CA
+       certificates that have a signature algorithm with a hash that is
+       considered weak by local policy.
+
+   2.  Determine how common client applications process the TLSA
+       certificate association using a fresh client installation -- that
+       is, with the local certificate cache empty.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman & Schlyter           Standards Track                   [Page 26]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+A.1.2.2.  Selector Type 1 (SubjectPublicKeyInfo)
+
+   A SubjectPublicKeyInfo selector gives greater flexibility in avoiding
+   some false-negative failures caused by trust-chain-building
+   algorithms used in clients.
+
+   One specific use case ought to be noted: creating a TLSA certificate
+   association to CA certificate I1 that directly signed end entity
+   certificate S1 of the server.  The case can be illustrated by the
+   following graph:
+
+           +----+                      +----+
+           | I1 |                      | I2 |
+           +----+                      +----+
+              |                           |
+              v                           v
+           +----+                      +----+
+           | S1 |                      | S1 |
+           +----+                      +----+
+   Certificate chain sent by    A different validation path
+   server in TLS handshake      built by the TLS client
+
+   I2 is a reissued version of CA certificate I1 (that is, it has a
+   different hash in its signature algorithm).
+
+   In the above scenario, both certificates I1 and I2 that sign S1 need
+   to have identical SubjectPublicKeyInfo fields because the key used to
+   sign S1 is fixed.  An association to SubjectPublicKeyInfo (selector
+   type 1) will always succeed in such a case, but an association with a
+   full certificate (selector type 0) might not work due to a false-
+   negative failure.
+
+   The attack surface is a bit broader compared to the "Full
+   certificate" selector: the DNS administrator might unintentionally
+   specify an association that would lead to false-positive acceptance.
+
+   o  The administrator must know or trust that the CA does not engage
+      in bad practices, such as not sharing the key of I1 for unrelated
+      CA certificates (which would lead to trust-chain redirection).  If
+      possible, the administrator ought to review all CA certificates
+      that have the same SubjectPublicKeyInfo field.
+
+   o  The administrator ought to understand whether some PKIX extension
+      may adversely affect security of the association.  If possible,
+      administrators ought to review all CA certificates that share the
+      SubjectPublicKeyInfo.
+
+
+
+
+
+Hoffman & Schlyter           Standards Track                   [Page 27]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+   o  The administrator ought to understand that any CA could, in the
+      future, issue a certificate that contains the same
+      SubjectPublicKeyInfo.  Therefore, new chains can crop up in the
+      future without any warning.
+
+   Using the SubjectPublicKeyInfo selector for association with a
+   certificate in a chain above I1 needs to be decided on a case-by-case
+   basis: there are too many possibilities based on the issuing CA's
+   practices.  Unless the full implications of such an association are
+   understood by the administrator, using selector type 0 is a better
+   option from a security perspective.
+
+A.2.  Provisioning TLSA Records in DNS
+
+A.2.1.  Provisioning TLSA Records with Aliases
+
+   The TLSA resource record is not special in the DNS; it acts exactly
+   like any other RRtype where the queried name has one or more labels
+   prefixed to the base name, such as the SRV RRtype [RFC2782].  This
+   affects the way that the TLSA resource record is used when aliasing
+   in the DNS.
+
+   Note that the IETF sometimes adds new types of aliasing in the DNS.
+   If that happens in the future, those aliases might affect TLSA
+   records, hopefully in a good way.
+
+A.2.1.1.  Provisioning TLSA Records with CNAME Records
+
+   Using CNAME to alias in DNS only aliases from the exact name given,
+   not any zones below the given name.  For example, assume that a zone
+   file has only the following:
+
+   sub1.example.com.          IN CNAME sub2.example.com.
+
+   In this case, a request for the A record at "bottom.sub1.example.com"
+   would not return any records because the CNAME given only aliases the
+   name given.  Assume, instead, the zone file has the following:
+
+   sub3.example.com.          IN CNAME sub4.example.com.
+   bottom.sub3.example.com.   IN CNAME bottom.sub4.example.com.
+
+   In this case, a request for the A record at bottom.sub3.example.com
+   would in fact return whatever value for the A record exists at
+   bottom.sub4.example.com.
+
+
+
+
+
+
+
+Hoffman & Schlyter           Standards Track                   [Page 28]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+   Application implementations and full-service resolvers request DNS
+   records using libraries that automatically follow CNAME (and DNAME)
+   aliasing.  This allows hosts to put TLSA records in their own zones
+   or to use CNAME to do redirection.
+
+   If the owner of the original domain wants a TLSA record for the same,
+   they simply enter it under the defined prefix:
+
+   ; No TLSA record in target domain
+   ;
+   sub5.example.com.            IN CNAME sub6.example.com.
+   _443._tcp.sub5.example.com.  IN TLSA 1 1 1 308202c5308201ab...
+   sub6.example.com.            IN A 192.0.2.1
+   sub6.example.com.            IN AAAA 2001:db8::1
+
+   If the owner of the original domain wants to have the target domain
+   host the TLSA record, the original domain uses a CNAME record:
+
+   ; TLSA record for original domain has CNAME to target domain
+   ;
+   sub5.example.com.            IN CNAME sub6.example.com.
+   _443._tcp.sub5.example.com.  IN CNAME _443._tcp.sub6.example.com.
+   sub6.example.com.            IN A 192.0.2.1
+   sub6.example.com.            IN AAAA 2001:db8::1
+   _443._tcp.sub6.example.com.  IN TLSA 1 1 1 536a570ac49d9ba4...
+
+   Note that it is acceptable for both the original domain and the
+   target domain to have TLSA records, but the two records are
+   unrelated.  Consider the following:
+
+   ; TLSA record in both the original and target domain
+   ;
+   sub5.example.com.            IN CNAME sub6.example.com.
+   _443._tcp.sub5.example.com.  IN TLSA 1 1 1 308202c5308201ab...
+   sub6.example.com.            IN A 192.0.2.1
+   sub6.example.com.            IN AAAA 2001:db8::1
+   _443._tcp.sub6.example.com.  IN TLSA 1 1 1 ac49d9ba4570ac49...
+
+   In this example, someone looking for the TLSA record for
+   sub5.example.com would always get the record whose value starts with
+   "308202c5308201ab"; the TLSA record whose value starts with
+   "ac49d9ba4570ac49" would only be sought by someone who is looking for
+   the TLSA record for sub6.example.com, and never for sub5.example.com.
+   Note that deploying different certificates for multiple services
+   located at a shared TLS listener often requires the use of TLS SNI
+   (Server Name Indication) [RFC6066].
+
+
+
+
+
+Hoffman & Schlyter           Standards Track                   [Page 29]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+   Note that these methods use the normal method for DNS aliasing using
+   CNAME: the DNS client requests the record type that they actually
+   want.
+
+A.2.1.2.  Provisioning TLSA Records with DNAME Records
+
+   Using DNAME records allows a zone owner to alias an entire subtree of
+   names below the name that has the DNAME.  This allows the wholesale
+   aliasing of prefixed records such as those used by TLSA, SRV, and so
+   on without aliasing the name itself.  However, because DNAME can only
+   be used for subtrees of a base name, it is rarely used to alias
+   individual hosts that might also be running TLS.
+
+   ; TLSA record in target domain, visible in original domain via DNAME
+   ;
+   sub5.example.com.            IN CNAME sub6.example.com.
+   _tcp.sub5.example.com.       IN DNAME _tcp.sub6.example.com.
+   sub6.example.com.            IN A 192.0.2.1
+   sub6.example.com.            IN AAAA 2001:db8::1
+   _443._tcp.sub6.example.com.  IN TLSA 1 1 1 536a570ac49d9ba4...
+
+A.2.1.3.  Provisioning TLSA Records with Wildcards
+
+   Wildcards are generally not terribly useful for RRtypes that require
+   prefixing because one can only wildcard at a layer below the host
+   name.  For example, if one wants to have the same TLSA record for
+   every TCP port for www.example.com, the result might be:
+
+   *._tcp.www.example.com.    IN TLSA 1 1 1 5c1502a6549c423b...
+
+   This is possibly useful in some scenarios where the same service is
+   offered on many ports or the same certificate and/or key is used for
+   all services on a host.  Note that the domain being searched for is
+   not necessarily related to the domain name found in the certificate,
+   so a certificate with a wildcard in it is not searched for using a
+   wildcard in the search request.
+
+A.3.  Securing the Last Hop
+
+   As described in Section 4, an application processing TLSA records
+   must know the DNSSEC validity of those records.  There are many ways
+   for the application to determine this securely, and this
+   specification does not mandate any single method.
+
+
+
+
+
+
+
+
+Hoffman & Schlyter           Standards Track                   [Page 30]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+   Some common methods for an application to know the DNSSEC validity of
+   TLSA records include:
+
+   o  The application can have its own DNS resolver and DNSSEC
+      validation stack.
+
+   o  The application can communicate through a trusted channel (such as
+      requests to the operating system under which the application is
+      running) to a local DNS resolver that does DNSSEC validation.
+
+   o  The application can communicate through a secured channel (such as
+      requests running over TLS, IPsec, TSIG, or SIG(0)) to a non-local
+      DNS resolver that does DNSSEC validation.
+
+   o  The application can communicate through a secured channel (such as
+      requests running over TLS, IPsec, TSIG, or SIG(0)) to a non-local
+      DNS resolver that does not do DNSSEC validation, but gets
+      responses through a secured channel from a different DNS resolver
+      that does DNSSEC validation.
+
+A.4.  Handling Certificate Rollover
+
+   Certificate rollover is handled in much the same way as for rolling
+   DNSSEC zone signing keys using the pre-publish key rollover method
+   [RFC4641].  Suppose example.com has a single TLSA record for a TLS
+   service on TCP port 990:
+
+   _990._tcp.example.com IN TLSA 1 1 1 1CFC98A706BCF3683015...
+
+   To start the rollover process, obtain or generate the new certificate
+   or SubjectPublicKeyInfo to be used after the rollover and generate
+   the new TLSA record.  Add that record alongside the old one:
+
+   _990._tcp.example.com IN TLSA 1 1 1 1CFC98A706BCF3683015...
+   _990._tcp.example.com IN TLSA 1 1 1 62D5414CD1CC657E3D30...
+
+   After the new records have propagated to the authoritative
+   nameservers and the TTL of the old record has expired, switch to the
+   new certificate on the TLS server.  Once this has occurred, the old
+   TLSA record can be removed:
+
+   _990._tcp.example.com IN TLSA 1 1 1 62D5414CD1CC657E3D30...
+
+   This completes the certificate rollover.
+
+
+
+
+
+
+
+Hoffman & Schlyter           Standards Track                   [Page 31]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+Appendix B.  Pseudocode for Using TLSA
+
+   This appendix describes, in pseudocode format, the interactions given
+   earlier in this specification.  If the steps below disagree with the
+   text earlier in the document, the steps earlier in the document ought
+   to be considered correct and this text incorrect.
+
+   Note that this pseudocode is more strict than the normative text.
+   For instance, it forces an order on the evaluation of criteria, which
+   is not mandatory from the normative text.
+
+B.1.  Helper Functions
+
+   // implement the function for exiting
+   function Finish (F) = {
+     if (F == ABORT_TLS) {
+       abort the TLS handshake or prevent TLS from starting
+       exit
+     }
+
+     if (F == NO_TLSA) {
+       fall back to non-TLSA certificate validation
+       exit
+     }
+
+     if (F == ACCEPT) {
+       accept the TLS connection
+       exit
+     }
+
+     // unreachable
+   }
+
+   // implement the selector function
+   function Select (S, X) = {
+     // Full certificate
+     if (S == 0) {
+       return X in DER encoding
+     }
+
+     // SubjectPublicKeyInfo
+     if (S == 1) {
+       return X.SubjectPublicKeyInfo in DER encoding
+     }
+
+     // unreachable
+   }
+
+
+
+
+Hoffman & Schlyter           Standards Track                   [Page 32]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+   // implement the matching function
+   function Match (M, X, Y) {
+     // Exact match on selected content
+     if (M == 0) {
+       return (X == Y)
+     }
+
+     // SHA-256 hash of selected content
+     if (M == 1) {
+       return (SHA-256(X) == Y)
+     }
+
+     // SHA-512 hash of selected content
+     if (M == 2) {
+       return (SHA-512(X) == Y)
+     }
+
+     // unreachable
+   }
+
+B.2.  Main TLSA Pseudocode
+
+   TLS connect using [transport] to [name] on [port] and receiving end
+   entity cert C for the TLS server:
+
+   (TLSArecords, ValState) = DNSSECValidatedLookup(
+     domainname=_[port]._[transport].[name], RRtype=TLSA)
+
+   // check for states that would change processing
+   if (ValState == BOGUS) {
+     Finish(ABORT_TLS)
+   }
+   if ((ValState == INDETERMINATE) or (ValState == INSECURE)) {
+     Finish(NO_TLSA)
+   }
+   // if here, ValState must be SECURE
+
+   for each R in TLSArecords {
+     // unusable records include unknown certUsage, unknown
+     // selectorType, unknown matchingType, erroneous RDATA, and
+     // prohibited by local policy
+     if (R is unusable) {
+       remove R from TLSArecords
+     }
+   }
+   if (length(TLSArecords) == 0) {
+     Finish(NO_TLSA)
+   }
+
+
+
+Hoffman & Schlyter           Standards Track                   [Page 33]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+   // A TLS client might have multiple trust anchors that it might use
+   //    when validating the TLS server's end entity (EE) certificate.
+   //    Also, there can be multiple PKIX certification paths for the
+   //    certificates given by the server in TLS.  Thus, there are
+   //    possibly many chains that might need to be tested during
+   //    PKIX path validation.
+
+   for each R in TLSArecords {
+
+     // pass PKIX certificate validation and chain through a CA cert
+     //    that comes from TLSA
+     if (R.certUsage == 0) {
+       for each PKIX certification path H {
+         if (C passes PKIX certification path validation in H) {
+           for each D in H {
+             if ((D is a CA certificate) and
+                 Match(R.matchingType, Select(R.selectorType, D),
+                       R.cert)) {
+               Finish(ACCEPT)
+             }
+           }
+         }
+       }
+     }
+
+     // pass PKIX certificate validation and match EE cert from TLSA
+     if (R.certUsage == 1) {
+       for each PKIX certification path H {
+         if ((C passes PKIX certificate validation in H) and
+                 Match(R.matchingType, Select(R.selectorType, C),
+                 R.cert)) {
+             Finish(ACCEPT)
+         }
+       }
+     }
+
+     // pass PKIX certification validation using TLSA record as the
+     //    trust anchor
+     if (R.certUsage == 2) {
+       // the following assert() is merely a formalization of the
+       // "trust anchor" condition for a certificate D matching R
+       assert(Match(R.matchingType, Select(R.selectorType, D), R.cert))
+
+
+
+
+
+
+
+
+
+Hoffman & Schlyter           Standards Track                   [Page 34]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+       for each PKIX certification path H that has certificate D
+           matching R as the trust anchor {
+         if (C passes PKIX validation in H) {
+           Finish(ACCEPT);
+         }
+       }
+     }
+
+     // match the TLSA record and the TLS certificate
+     if (R.certUsage == 3) {
+       if Match(R.matchingType, Select(R.selectorType, C), R.cert)
+         Finish(ACCEPT)
+       }
+     }
+
+   }
+
+   // if here, then none of the TLSA records ended in "Finish(ACCEPT)"
+   //   so abort TLS
+   Finish(ABORT_TLS)
+
+Appendix C.  Examples
+
+   The following are examples of self-signed certificates that have been
+   generated with various selectors and matching types.  They were
+   generated with one piece of software, and validated by an individual
+   using other tools.
+
+   S = Selector
+   M = Matching Type
+
+   S M Association Data
+   0 0 30820454308202BC020900AB58D24E77AD2AF6300D06092A86
+       4886F70D0101050500306C310B3009060355040613024E4C31163014
+       0603550408130D4E6F6F72642D486F6C6C616E643112301006035504
+       071309416D7374657264616D310C300A060355040A13034F53333123
+       30210603550403131A64616E652E6B6965762E70726163746963756D
+       2E6F73332E6E6C301E170D3132303131363136353730335A170D3232
+       303131333136353730335A306C310B3009060355040613024E4C3116
+       30140603550408130D4E6F6F72642D486F6C6C616E64311230100603
+       5504071309416D7374657264616D310C300A060355040A13034F5333
+       312330210603550403131A64616E652E6B6965762E70726163746963
+       756D2E6F73332E6E6C308201A2300D06092A864886F70D0101010500
+       0382018F003082018A0282018100E62C84A5AFE59F0A2A6B250DEE68
+       7AC8C5C604F57D26CEB2119140FFAC38C4B9CBBE8923082E7F81626B
+       6AD5DEA0C8771C74E3CAA7F613054AEFA3673E48FFE47B3F7AF987DE
+       281A68230B24B9DA1A98DCBE51195B60E42FD7517C328D983E26A827
+       C877AB914EE4C1BFDEAD48BD25BE5F2C473BA9C1CBBDDDA0C374D0D5
+
+
+
+Hoffman & Schlyter           Standards Track                   [Page 35]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+       8C389CC3D6D8C20662E19CF768F32441B7F7D14AEA8966CE7C32A172
+       2AB38623D008029A9E4702883F8B977A1A1E5292BF8AD72239D40393
+       37B86A3AC60FA001290452177BF1798609A05A130F033457A5212629
+       FBDDB8E70E2A9E6556873C4F7CA46AE4A8B178F05FB319005E1C1C7D
+       4BD77DFA34035563C126AA2C3328B900E7990AC9787F01DA82F74C3D
+       4B6674CCECE1FD4C6EF9E6644F4635EDEDA39D8B0E2F7C8E06DAE775
+       6213BD3D60831175BE290442B4AFC5AE6F46B769855A067C1097E617
+       962529E166F22AEE10DDB981B8CD6FF17D3D70723169038DBFBC1A44
+       9C8D0D31BC683C5F3CE26148E42EC9BBD4D9F261569B25B53C1D7FC2
+       DDFF6B4CAC050203010001300D06092A864886F70D01010505000382
+       0181002B2ABE063E9C86AC4A1F7835372091079C8276A9C2C5D1EC57
+       64DE523FDDABDEAB3FD34E6FE6CBA054580A6785A663595D90132B93
+       D473929E81FA0887D2FFF78A81C7D014B97778AB6AC9E5E690F6F5A9
+       E92BB5FBAB71B857AE69B6E18BDCCB0BA6FCD9D4B084A34F3635148C
+       495D48FE635903B888EC1DEB2610548EDD48D63F86513A4562469831
+       48C0D5DB82D73A4C350A42BB661D763430FC6C8E5F9D13EA1B76AA52
+       A4C358E5EA04000F794618303AB6CEEA4E9A8E9C74D73C1B0B7BAF16
+       DEDE7696B5E2F206F777100F5727E1684D4132F5E692F47AF6756EA8
+       B421000BE031B5D8F0220E436B51FB154FE9595333C13A2403F9DE08
+       E5DDC5A22FD6182E339593E26374450220BC14F3E40FF33F084526B0
+       9C34250702E8A352B332CCCB0F9DE2CF2B338823B92AFC61C0B6B8AB
+       DB5AF718ED8DDA97C298E46B82A01B14814868CFA4F2C36268BFFF4A
+       591F42658BF75918902D3E426DFE1D5FF0FC6A212071F6DA8BD833FE
+       2E560D87775E8EE9333C05B6FB8EB56589D910DB5EA903
+
+   0 1 EFDDF0D915C7BDC5782C0881E1B2A95AD099FBDD06D7B1F779
+       82D9364338D955
+
+   0 2 81EE7F6C0ECC6B09B7785A9418F54432DE630DD54DC6EE9E3C
+       49DE547708D236D4C413C3E97E44F969E635958AA410495844127C04
+       883503E5B024CF7A8F6A94
+
+   1 0 308201A2300D06092A864886F70D01010105000382018F0030
+       82018A0282018100E62C84A5AFE59F0A2A6B250DEE687AC8C5C604F5
+       7D26CEB2119140FFAC38C4B9CBBE8923082E7F81626B6AD5DEA0C877
+       1C74E3CAA7F613054AEFA3673E48FFE47B3F7AF987DE281A68230B24
+       B9DA1A98DCBE51195B60E42FD7517C328D983E26A827C877AB914EE4
+       C1BFDEAD48BD25BE5F2C473BA9C1CBBDDDA0C374D0D58C389CC3D6D8
+       C20662E19CF768F32441B7F7D14AEA8966CE7C32A1722AB38623D008
+       029A9E4702883F8B977A1A1E5292BF8AD72239D4039337B86A3AC60F
+       A001290452177BF1798609A05A130F033457A5212629FBDDB8E70E2A
+       9E6556873C4F7CA46AE4A8B178F05FB319005E1C1C7D4BD77DFA3403
+       5563C126AA2C3328B900E7990AC9787F01DA82F74C3D4B6674CCECE1
+       FD4C6EF9E6644F4635EDEDA39D8B0E2F7C8E06DAE7756213BD3D6083
+       1175BE290442B4AFC5AE6F46B769855A067C1097E617962529E166F2
+       2AEE10DDB981B8CD6FF17D3D70723169038DBFBC1A449C8D0D31BC68
+       3C5F3CE26148E42EC9BBD4D9F261569B25B53C1D7FC2DDFF6B4CAC05
+       0203010001
+
+
+
+Hoffman & Schlyter           Standards Track                   [Page 36]
+
+RFC 6698            DNS-Based Authentication for TLS         August 2012
+
+
+   1 1 8755CDAA8FE24EF16CC0F2C918063185E433FAAF1415664911
+       D9E30A924138C4
+
+   1 2 D43165B4CDF8F8660AECCCC5344D9D9AE45FFD7E6AAB7AB9EE
+       C169B58E11F227ED90C17330CC17B5CCEF0390066008C720CEC6AAE5
+       33A934B3A2D7E232C94AB4
+
+Authors' Addresses
+
+   Paul Hoffman
+   VPN Consortium
+
+   EMail: paul.hoffman@vpnc.org
+
+
+   Jakob Schlyter
+   Kirei AB
+
+   EMail: jakob@kirei.se
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman & Schlyter           Standards Track                   [Page 37]
+
diff --git a/doc/rfc/rfc6840.txt b/doc/rfc/rfc6840.txt
new file mode 100644
index 0000000000..7ed54360ed
--- /dev/null
+++ b/doc/rfc/rfc6840.txt
@@ -0,0 +1,1179 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                    S. Weiler, Ed.
+Request for Comments: 6840                                  SPARTA, Inc.
+Updates: 4033, 4034, 4035, 5155                           D. Blacka, Ed.
+Category: Standards Track                                 Verisign, Inc.
+ISSN: 2070-1721                                            February 2013
+
+
+   Clarifications and Implementation Notes for DNS Security (DNSSEC)
+
+Abstract
+
+   This document is a collection of technical clarifications to the DNS
+   Security (DNSSEC) document set.  It is meant to serve as a resource
+   to implementors as well as a collection of DNSSEC errata that existed
+   at the time of writing.
+
+   This document updates the core DNSSEC documents (RFC 4033, RFC 4034,
+   and RFC 4035) as well as the NSEC3 specification (RFC 5155).  It also
+   defines NSEC3 and SHA-2 (RFC 4509 and RFC 5702) as core parts of the
+   DNSSEC specification.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6840.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Weiler & Blacka              Standards Track                    [Page 1]
+
+RFC 6840               DNSSEC Implementation Notes         February 2013
+
+
+Copyright Notice
+
+   Copyright (c) 2013 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.
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Weiler & Blacka              Standards Track                    [Page 2]
+
+RFC 6840               DNSSEC Implementation Notes         February 2013
+
+
+Table of Contents
+
+   1. Introduction and Terminology ....................................4
+      1.1. Structure of This Document .................................4
+      1.2. Terminology ................................................4
+   2. Important Additions to DNSSEC ...................................4
+      2.1. NSEC3 Support ..............................................4
+      2.2. SHA-2 Support ..............................................5
+   3. Scaling Concerns ................................................5
+      3.1. Implement a BAD Cache ......................................5
+   4. Security Concerns ...............................................5
+      4.1. Clarifications on Nonexistence Proofs ......................5
+      4.2. Validating Responses to an ANY Query .......................6
+      4.3. Check for CNAME ............................................6
+      4.4. Insecure Delegation Proofs .................................7
+   5. Interoperability Concerns .......................................7
+      5.1. Errors in Canonical Form Type Code List ....................7
+      5.2. Unknown DS Message Digest Algorithms .......................7
+      5.3. Private Algorithms .........................................8
+      5.4. Caution about Local Policy and Multiple RRSIGs .............9
+      5.5. Key Tag Calculation ........................................9
+      5.6. Setting the DO Bit on Replies ..............................9
+      5.7. Setting the AD Bit on Queries .............................10
+      5.8. Setting the AD Bit on Replies .............................10
+      5.9. Always Set the CD Bit on Queries ..........................10
+      5.10. Nested Trust Anchors .....................................11
+      5.11. Mandatory Algorithm Rules ................................11
+      5.12. Ignore Extra Signatures from Unknown Keys ................12
+   6. Minor Corrections and Clarifications ...........................12
+      6.1. Finding Zone Cuts .........................................12
+      6.2. Clarifications on DNSKEY Usage ............................12
+      6.3. Errors in Examples ........................................13
+      6.4. Errors in RFC 5155 ........................................13
+   7. Security Considerations ........................................13
+   8. References .....................................................14
+      8.1. Normative References ......................................14
+      8.2. Informative References ....................................15
+   Appendix A. Acknowledgments .......................................16
+   Appendix B. Discussion of Setting the CD Bit ......................16
+   Appendix C. Discussion of Trust Anchor Preference Options .........19
+      C.1. Closest Encloser ..........................................19
+      C.2. Accept Any Success ........................................20
+      C.3. Preference Based on Source ................................20
+
+
+
+
+
+
+
+
+Weiler & Blacka              Standards Track                    [Page 3]
+
+RFC 6840               DNSSEC Implementation Notes         February 2013
+
+
+1.  Introduction and Terminology
+
+   This document lists some additions, clarifications, and corrections
+   to the core DNSSEC specification, as originally described in
+   [RFC4033], [RFC4034], and [RFC4035], and later amended by [RFC5155].
+   (See Section 2 for more recent additions to that core document set.)
+
+   It is intended to serve as a resource for implementors and as a
+   repository of items existing at the time of writing that need to be
+   addressed when advancing the DNSSEC documents along the Standards
+   Track.
+
+1.1.  Structure of This Document
+
+   The clarifications and changes to DNSSEC are sorted according to
+   their importance, starting with ones which could, if ignored, lead to
+   security problems and progressing down to clarifications that are
+   expected to have little operational impact.
+
+1.2.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   [RFC2119].
+
+2.  Important Additions to DNSSEC
+
+   This section lists some documents that are now considered core DNSSEC
+   protocol documents in addition to those originally specified in
+   Section 10 of [RFC4033].
+
+2.1.  NSEC3 Support
+
+   [RFC5155] describes the use and behavior of the NSEC3 and NSEC3PARAM
+   records for hashed denial of existence.  Validator implementations
+   are strongly encouraged to include support for NSEC3 because a number
+   of highly visible zones use it.  Validators that do not support
+   validation of responses using NSEC3 will be hampered in validating
+   large portions of the DNS space.
+
+   [RFC5155] is now considered part of the DNS Security Document Family
+   as described by Section 10 of [RFC4033].
+
+
+
+
+
+
+
+
+Weiler & Blacka              Standards Track                    [Page 4]
+
+RFC 6840               DNSSEC Implementation Notes         February 2013
+
+
+   Note that the algorithm identifiers defined in [RFC5155] (DSA-NSEC3-
+   SHA1 and RSASHA1-NSEC3-SHA1) and [RFC5702] (RSASHA256 and RSASHA512)
+   signal that a zone might be using NSEC3, rather than NSEC.  The zone
+   may be using either, and validators supporting these algorithms MUST
+   support both NSEC3 and NSEC responses.
+
+2.2.  SHA-2 Support
+
+   [RFC4509] describes the use of SHA-256 as a digest algorithm in
+   Delegation Signer (DS) RRs.  [RFC5702] describes the use of the
+   RSASHA256 and RSASHA512 algorithms in DNSKEY and RRSIG RRs.
+   Validator implementations are strongly encouraged to include support
+   for these algorithms for DS, DNSKEY, and RRSIG records.
+
+   Both [RFC4509] and [RFC5702] are now considered part of the DNS
+   Security Document Family as described by Section 10 of [RFC4033].
+
+3.  Scaling Concerns
+
+3.1.  Implement a BAD Cache
+
+   Section 4.7 of [RFC4035] permits security-aware resolvers to
+   implement a BAD cache.  That guidance has changed: security-aware
+   resolvers SHOULD implement a BAD cache as described in [RFC4035].
+
+   This change in guidance is based on operational experience with
+   DNSSEC administrative errors leading to significant increases in DNS
+   traffic, with an accompanying realization that such events are more
+   likely and more damaging than originally supposed.  An example of one
+   such event is documented in "Rolling Over DNSSEC Keys" [Huston].
+
+4.  Security Concerns
+
+   This section provides clarifications that, if overlooked, could lead
+   to security issues.
+
+4.1.  Clarifications on Nonexistence Proofs
+
+   Section 5.4 of [RFC4035] under-specifies the algorithm for checking
+   nonexistence proofs.  In particular, the algorithm as presented would
+   allow a validator to interpret an NSEC or NSEC3 RR from an ancestor
+   zone as proving the nonexistence of an RR in a child zone.
+
+   An "ancestor delegation" NSEC RR (or NSEC3 RR) is one with:
+
+   o  the NS bit set,
+
+   o  the Start of Authority (SOA) bit clear, and
+
+
+
+Weiler & Blacka              Standards Track                    [Page 5]
+
+RFC 6840               DNSSEC Implementation Notes         February 2013
+
+
+   o  a signer field that is shorter than the owner name of the NSEC RR,
+      or the original owner name for the NSEC3 RR.
+
+   Ancestor delegation NSEC or NSEC3 RRs MUST NOT be used to assume
+   nonexistence of any RRs below that zone cut, which include all RRs at
+   that (original) owner name other than DS RRs, and all RRs below that
+   owner name regardless of type.
+
+   Similarly, the algorithm would also allow an NSEC RR at the same
+   owner name as a DNAME RR, or an NSEC3 RR at the same original owner
+   name as a DNAME, to prove the nonexistence of names beneath that
+   DNAME.  An NSEC or NSEC3 RR with the DNAME bit set MUST NOT be used
+   to assume the nonexistence of any subdomain of that NSEC/NSEC3 RR's
+   (original) owner name.
+
+4.2.  Validating Responses to an ANY Query
+
+   [RFC4035] does not address how to validate responses when QTYPE=*.
+   As described in Section 6.2.2 of [RFC1034], a proper response to
+   QTYPE=* may include a subset of the RRsets at a given name.  That is,
+   it is not necessary to include all RRsets at the QNAME in the
+   response.
+
+   When validating a response to QTYPE=*, all received RRsets that match
+   QNAME and QCLASS MUST be validated.  If any of those RRsets fail
+   validation, the answer is considered Bogus.  If there are no RRsets
+   matching QNAME and QCLASS, that fact MUST be validated according to
+   the rules in Section 5.4 of [RFC4035] (as clarified in this
+   document).  To be clear, a validator must not expect to receive all
+   records at the QNAME in response to QTYPE=*.
+
+4.3.  Check for CNAME
+
+   Section 5 of [RFC4035] says nothing explicit about validating
+   responses based on (or that should be based on) CNAMEs.  When
+   validating a NOERROR/NODATA response, validators MUST check the CNAME
+   bit in the matching NSEC or NSEC3 RR's type bitmap in addition to the
+   bit for the query type.
+
+   Without this check, an attacker could successfully transform a
+   positive CNAME response into a NOERROR/NODATA response by (for
+   example) simply stripping the CNAME RRset from the response.  A naive
+   validator would then note that the QTYPE was not present in the
+   matching NSEC/NSEC3 RR, but fail to notice that the CNAME bit was
+   set; thus, the response should have been a positive CNAME response.
+
+
+
+
+
+
+Weiler & Blacka              Standards Track                    [Page 6]
+
+RFC 6840               DNSSEC Implementation Notes         February 2013
+
+
+4.4.  Insecure Delegation Proofs
+
+   Section 5.2 of [RFC4035] specifies that a validator, when proving a
+   delegation is not secure, needs to check for the absence of the DS
+   and SOA bits in the NSEC (or NSEC3) type bitmap.  The validator also
+   MUST check for the presence of the NS bit in the matching NSEC (or
+   NSEC3) RR (proving that there is, indeed, a delegation), or
+   alternately make sure that the delegation is covered by an NSEC3 RR
+   with the Opt-Out flag set.
+
+   Without this check, an attacker could reuse an NSEC or NSEC3 RR
+   matching a non-delegation name to spoof an unsigned delegation at
+   that name.  This would claim that an existing signed RRset (or set of
+   signed RRsets) is below an unsigned delegation, thus not signed and
+   vulnerable to further attack.
+
+5.  Interoperability Concerns
+
+5.1.  Errors in Canonical Form Type Code List
+
+   When canonicalizing DNS names (for both ordering and signing), DNS
+   names in the RDATA section of NSEC resource records are not converted
+   to lowercase.  DNS names in the RDATA section of RRSIG resource
+   records are converted to lowercase.
+
+   The guidance in the above paragraph differs from what has been
+   published before but is consistent with current common practice.
+   Item 3 of Section 6.2 of [RFC4034] says that names in both of these
+   RR types should be converted to lowercase.  The earlier [RFC3755]
+   says that they should not.  Current practice follows neither document
+   fully.
+
+   Section 6.2 of [RFC4034] also erroneously lists HINFO as a record
+   that needs conversion to lowercase, and twice at that.  Since HINFO
+   records contain no domain names, they are not subject to case
+   conversion.
+
+5.2.  Unknown DS Message Digest Algorithms
+
+   Section 5.2 of [RFC4035] includes rules for how to handle delegations
+   to zones that are signed with entirely unsupported public key
+   algorithms, as indicated by the key algorithms shown in those zones'
+   DS RRsets.  It does not explicitly address how to handle DS records
+   that use unsupported message digest algorithms.  In brief, DS records
+   using unknown or unsupported message digest algorithms MUST be
+   treated the same way as DS records referring to DNSKEY RRs of unknown
+   or unsupported public key algorithms.
+
+
+
+
+Weiler & Blacka              Standards Track                    [Page 7]
+
+RFC 6840               DNSSEC Implementation Notes         February 2013
+
+
+   The existing text says:
+
+      If the validator does not support any of the algorithms listed in
+      an authenticated DS RRset, then the resolver has no supported
+      authentication path leading from the parent to the child.  The
+      resolver should treat this case as it would the case of an
+      authenticated NSEC RRset proving that no DS RRset exists, as
+      described above.
+
+   In other words, when determining the security status of a zone, a
+   validator disregards any authenticated DS records that specify
+   unknown or unsupported DNSKEY algorithms.  If none are left, the zone
+   is treated as if it were unsigned.
+
+   This document modifies the above text to additionally disregard
+   authenticated DS records using unknown or unsupported message digest
+   algorithms.
+
+5.3.  Private Algorithms
+
+   As discussed above, Section 5.2 of [RFC4035] requires that validators
+   make decisions about the security status of zones based on the public
+   key algorithms shown in the DS records for those zones.  In the case
+   of private algorithms, as described in Appendix A.1.1 of [RFC4034],
+   the eight-bit algorithm field in the DS RR is not conclusive about
+   what algorithm(s) is actually in use.
+
+   If no private algorithms appear in the DS RRset, or if any supported
+   algorithm appears in the DS RRset, no special processing is needed.
+   Furthermore, if the validator implementation does not support any
+   private algorithms, or only supports private algorithms using an
+   algorithm number not present in the DS RRset, no special processing
+   is needed.
+
+   In the remaining cases, the security status of the zone depends on
+   whether or not the resolver supports any of the private algorithms in
+   use (provided that these DS records use supported message digest
+   algorithms, as discussed in Section 5.2 of this document).  In these
+   cases, the resolver MUST retrieve the corresponding DNSKEY for each
+   private algorithm DS record and examine the public key field to
+   determine the algorithm in use.  The security-aware resolver MUST
+   ensure that the hash of the DNSKEY RR's owner name and RDATA matches
+   the digest in the DS RR as described in Section 5.2 of [RFC4035],
+   authenticating the DNSKEY.  If all of the retrieved and authenticated
+   DNSKEY RRs use unknown or unsupported private algorithms, then the
+   zone is treated as if it were unsigned.
+
+
+
+
+
+Weiler & Blacka              Standards Track                    [Page 8]
+
+RFC 6840               DNSSEC Implementation Notes         February 2013
+
+
+   Note that if none of the private algorithm DS RRs can be securely
+   matched to DNSKEY RRs and no other DS establishes that the zone is
+   secure, the referral should be considered Bogus data as discussed in
+   [RFC4035].
+
+   This clarification facilitates the broader use of private algorithms,
+   as suggested by [RFC4955].
+
+5.4.  Caution about Local Policy and Multiple RRSIGs
+
+   When multiple RRSIGs cover a given RRset, Section 5.3.3 of [RFC4035]
+   suggests that "the local resolver security policy determines whether
+   the resolver also has to test these RRSIG RRs and how to resolve
+   conflicts if these RRSIG RRs lead to differing results".
+
+   This document specifies that a resolver SHOULD accept any valid RRSIG
+   as sufficient, and only determine that an RRset is Bogus if all
+   RRSIGs fail validation.
+
+   If a resolver adopts a more restrictive policy, there's a danger that
+   properly signed data might unnecessarily fail validation due to cache
+   timing issues.  Furthermore, certain zone management techniques, like
+   the Double Signature Zone Signing Key Rollover method described in
+   Section 4.2.1.2 of [RFC6781], will not work reliably.  Such a
+   resolver is also vulnerable to malicious insertion of gibberish
+   signatures.
+
+5.5.  Key Tag Calculation
+
+   Appendix B.1 of [RFC4034] incorrectly defines the Key Tag field
+   calculation for algorithm 1.  It correctly says that the Key Tag is
+   the most significant 16 of the least significant 24 bits of the
+   public key modulus.  However, [RFC4034] then goes on to incorrectly
+   say that this is fourth-to-last and third-to-last octets of the
+   public key modulus.  It is, in fact, the third-to-last and second-to-
+   last octets.
+
+5.6.  Setting the DO Bit on Replies
+
+   As stated in Section 3 of [RFC3225], the DNSSEC OK (DO) bit of the
+   query MUST be copied in the response.  However, in order to
+   interoperate with implementations that ignore this rule on sending,
+   resolvers MUST ignore the DO bit in responses.
+
+
+
+
+
+
+
+
+Weiler & Blacka              Standards Track                    [Page 9]
+
+RFC 6840               DNSSEC Implementation Notes         February 2013
+
+
+5.7.  Setting the AD Bit on Queries
+
+   The semantics of the Authentic Data (AD) bit in the query were
+   previously undefined.  Section 4.6 of [RFC4035] instructed resolvers
+   to always clear the AD bit when composing queries.
+
+   This document defines setting the AD bit in a query as a signal
+   indicating that the requester understands and is interested in the
+   value of the AD bit in the response.  This allows a requester to
+   indicate that it understands the AD bit without also requesting
+   DNSSEC data via the DO bit.
+
+5.8.  Setting the AD Bit on Replies
+
+   Section 3.2.3 of [RFC4035] describes under which conditions a
+   validating resolver should set or clear the AD bit in a response.  In
+   order to interoperate with legacy stub resolvers and middleboxes that
+   neither understand nor ignore the AD bit, validating resolvers SHOULD
+   only set the AD bit when a response both meets the conditions listed
+   in Section 3.2.3 of [RFC4035], and the request contained either a set
+   DO bit or a set AD bit.
+
+5.9.  Always Set the CD Bit on Queries
+
+   When processing a request with the Checking Disabled (CD) bit set, a
+   resolver SHOULD attempt to return all response data, even data that
+   has failed DNSSEC validation.  Section 3.2.2 of [RFC4035] requires a
+   resolver processing a request with the CD bit set to set the CD bit
+   on its upstream queries.
+
+   This document further specifies that validating resolvers SHOULD set
+   the CD bit on every upstream query.  This is regardless of whether
+   the CD bit was set on the incoming query or whether it has a trust
+   anchor at or above the QNAME.
+
+   [RFC4035] is ambiguous about what to do when a cached response was
+   obtained with the CD bit unset, a case that only arises when the
+   resolver chooses not to set the CD bit on all upstream queries, as
+   specified above.  In the typical case, no new query is required, nor
+   does the cache need to track the state of the CD bit used to make a
+   given query.  The problem arises when the cached response is a server
+   failure (RCODE 2), which may indicate that the requested data failed
+   DNSSEC validation at an upstream validating resolver.  ([RFC2308]
+   permits caching of server failures for up to five minutes.)  In these
+   cases, a new query with the CD bit set is required.
+
+   Appendix B discusses more of the logic behind the recommendation
+   presented in this section.
+
+
+
+Weiler & Blacka              Standards Track                   [Page 10]
+
+RFC 6840               DNSSEC Implementation Notes         February 2013
+
+
+5.10.  Nested Trust Anchors
+
+   A DNSSEC validator may be configured such that, for a given response,
+   more than one trust anchor could be used to validate the chain of
+   trust to the response zone.  For example, imagine a validator
+   configured with trust anchors for "example." and "zone.example."
+   When the validator is asked to validate a response to
+   "www.sub.zone.example.", either trust anchor could apply.
+
+   When presented with this situation, DNSSEC validators have a choice
+   of which trust anchor(s) to use.  Which to use is a matter of
+   implementation choice.  Appendix C discusses several possible
+   algorithms.
+
+   It is possible and advisable to expose the choice of policy as a
+   configuration option.  As a default, it is suggested that validators
+   implement the "Accept Any Success" policy described in Appendix C.2
+   while exposing other policies as configuration options.
+
+   The "Accept Any Success" policy is to try all applicable trust
+   anchors until one gives a validation result of Secure, in which case
+   the final validation result is Secure.  If and only if all applicable
+   trust anchors give a result of Insecure, the final validation result
+   is Insecure.  If one or more trust anchors lead to a Bogus result and
+   there is no Secure result, then the final validation result is Bogus.
+
+5.11.  Mandatory Algorithm Rules
+
+   The last paragraph of Section 2.2 of [RFC4035] includes rules
+   describing which algorithms must be used to sign a zone.  Since these
+   rules have been confusing, they are restated using different language
+   here:
+
+      The DS RRset and DNSKEY RRset are used to signal which algorithms
+      are used to sign a zone.  The presence of an algorithm in either a
+      zone's DS or DNSKEY RRset signals that that algorithm is used to
+      sign the entire zone.
+
+      A signed zone MUST include a DNSKEY for each algorithm present in
+      the zone's DS RRset and expected trust anchors for the zone.  The
+      zone MUST also be signed with each algorithm (though not each key)
+      present in the DNSKEY RRset.  It is possible to add algorithms at
+      the DNSKEY that aren't in the DS record, but not vice versa.  If
+      more than one key of the same algorithm is in the DNSKEY RRset, it
+      is sufficient to sign each RRset with any subset of these DNSKEYs.
+      It is acceptable to sign some RRsets with one subset of keys (or
+      key) and other RRsets with a different subset, so long as at least
+
+
+
+
+Weiler & Blacka              Standards Track                   [Page 11]
+
+RFC 6840               DNSSEC Implementation Notes         February 2013
+
+
+      one DNSKEY of each algorithm is used to sign each RRset.
+      Likewise, if there are DS records for multiple keys of the same
+      algorithm, any subset of those may appear in the DNSKEY RRset.
+
+   This requirement applies to servers, not validators.  Validators
+   SHOULD accept any single valid path.  They SHOULD NOT insist that all
+   algorithms signaled in the DS RRset work, and they MUST NOT insist
+   that all algorithms signaled in the DNSKEY RRset work.  A validator
+   MAY have a configuration option to perform a signature completeness
+   test to support troubleshooting.
+
+5.12.  Ignore Extra Signatures from Unknown Keys
+
+   Validating resolvers MUST disregard RRSIGs in a zone that do not
+   (currently) have a corresponding DNSKEY in the zone.  Similarly, a
+   validating resolver MUST disregard RRSIGs with algorithm types that
+   don't exist in the DNSKEY RRset.
+
+   Good key rollover and algorithm rollover practices, as discussed in
+   RFC 6781 and its successor documents and as suggested by the rules in
+   the previous section, may require that such RRSIGs be present in a
+   zone.
+
+6.  Minor Corrections and Clarifications
+
+6.1.  Finding Zone Cuts
+
+   Appendix C.8 of [RFC4035] discusses sending DS queries to the servers
+   for a parent zone but does not state how to find those servers.
+   Specific instructions can be found in Section 4.2 of [RFC4035].
+
+6.2.  Clarifications on DNSKEY Usage
+
+   It is possible to use different DNSKEYs to sign different subsets of
+   a zone, constrained only by the rules in Section 5.11.  It is even
+   possible to use a different DNSKEY for each RRset in a zone, subject
+   only to practical limits on the size of the DNSKEY RRset and the
+   above rules.  However, be aware that there is no way to tell
+   resolvers what a particular DNSKEY is supposed to be used for -- any
+   DNSKEY in the zone's signed DNSKEY RRset may be used to authenticate
+   any RRset in the zone.  For example, if a weaker or less trusted
+   DNSKEY is being used to authenticate NSEC RRsets or all dynamically
+   updated records, that same DNSKEY can also be used to sign any other
+   RRsets from the zone.
+
+   Furthermore, note that the SEP bit setting has no effect on how a
+   DNSKEY may be used -- the validation process is specifically
+   prohibited from using that bit by Section 2.1.2 of [RFC4034].  It is
+
+
+
+Weiler & Blacka              Standards Track                   [Page 12]
+
+RFC 6840               DNSSEC Implementation Notes         February 2013
+
+
+   possible to use a DNSKEY without the SEP bit set as the sole secure
+   entry point to the zone, yet use a DNSKEY with the SEP bit set to
+   sign all RRsets in the zone (other than the DNSKEY RRset).  It is
+   also possible to use a single DNSKEY, with or without the SEP bit
+   set, to sign the entire zone, including the DNSKEY RRset itself.
+
+6.3.  Errors in Examples
+
+   The text in Appendix C.1 of [RFC4035] refers to the examples in
+   Appendix B.1 as "x.w.example.com" while B.1 uses "x.w.example".  This
+   is painfully obvious in the second paragraph where it states that the
+   RRSIG labels field value of 3 indicates that the answer was not the
+   result of wildcard expansion.  This is true for "x.w.example" but not
+   for "x.w.example.com", which of course has a label count of 4
+   (antithetically, a label count of 3 would imply the answer was the
+   result of a wildcard expansion).
+
+   The first paragraph of Appendix C.6 of [RFC4035] also has a minor
+   error: the reference to "a.z.w.w.example" should instead be
+   "a.z.w.example", as in the previous line.
+
+6.4.  Errors in RFC 5155
+
+   An NSEC3 record that matches an Empty Non-Terminal effectively has no
+   type associated with it.  This NSEC3 record has an empty type bit
+   map.  Section 3.2.1 of [RFC5155] contains the statement:
+
+      Blocks with no types present MUST NOT be included.
+
+   However, the same section contains a regular expression:
+
+      Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+
+
+   The plus sign in the regular expression indicates that there is one
+   or more of the preceding element.  This means that there must be at
+   least one window block.  If this window block has no types, it
+   contradicts with the first statement.  Therefore, the correct text in
+   Section 3.2.1 of [RFC5155] should be:
+
+      Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )*
+
+7.  Security Considerations
+
+   This document adds SHA-2 and NSEC3 support to the core DNSSEC
+   protocol.  Security considerations for those features are discussed
+   in the documents defining them.  Additionally, this document
+   addresses some ambiguities and omissions in the core DNSSEC documents
+   that, if not recognized and addressed in implementations, could lead
+
+
+
+Weiler & Blacka              Standards Track                   [Page 13]
+
+RFC 6840               DNSSEC Implementation Notes         February 2013
+
+
+   to security failures.  In particular, the validation algorithm
+   clarifications in Section 4 are critical for preserving the security
+   properties DNSSEC offers.  Furthermore, failure to address some of
+   the interoperability concerns in Section 5 could limit the ability to
+   later change or expand DNSSEC, including adding new algorithms.
+
+   The recommendation in Section 5.9 to always set the CD bit has
+   security implications.  By setting the CD bit, a resolver will not
+   benefit from more stringent validation rules or a more complete set
+   of trust anchors at an upstream validator.
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
+              STD 13, RFC 1034, November 1987.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3225]  Conrad, D., "Indicating Resolver Support of DNSSEC",
+              RFC 3225, December 2001.
+
+   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "DNS Security Introduction and Requirements",
+              RFC 4033, March 2005.
+
+   [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.
+
+   [RFC4509]  Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
+              (DS) Resource Records (RRs)", RFC 4509, May 2006.
+
+   [RFC5155]  Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
+              Security (DNSSEC) Hashed Authenticated Denial of
+              Existence", RFC 5155, March 2008.
+
+   [RFC5702]  Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY
+              and RRSIG Resource Records for DNSSEC", RFC 5702,
+              October 2009.
+
+
+
+
+
+Weiler & Blacka              Standards Track                   [Page 14]
+
+RFC 6840               DNSSEC Implementation Notes         February 2013
+
+
+8.2.  Informative References
+
+   [Huston]   Michaelson, G., Wallstrom, P., Arends, R., and G. Huston,
+              "Rolling Over DNSSEC Keys", Internet Protocol
+              Journal, Vol. 13, No.1, pp. 2-16, March 2010.
+
+   [RFC2308]  Andrews, M., "Negative Caching of DNS Queries (DNS
+              NCACHE)", RFC 2308, March 1998.
+
+   [RFC3755]  Weiler, S., "Legacy Resolver Compatibility for Delegation
+              Signer (DS)", RFC 3755, May 2004.
+
+   [RFC4955]  Blacka, D., "DNS Security (DNSSEC) Experiments", RFC 4955,
+              July 2007.
+
+   [RFC5011]  StJohns, M., "Automated Updates of DNS Security (DNSSEC)
+              Trust Anchors", STD 74, RFC 5011, September 2007.
+
+   [RFC5074]  Weiler, S., "DNSSEC Lookaside Validation (DLV)", RFC 5074,
+              November 2007.
+
+   [RFC6781]  Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
+              Operational Practices, Version 2", RFC 6781,
+              December 2012.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Weiler & Blacka              Standards Track                   [Page 15]
+
+RFC 6840               DNSSEC Implementation Notes         February 2013
+
+
+Appendix A.  Acknowledgments
+
+   The editors would like the thank Rob Austein for his previous work as
+   an editor of this document.
+
+   The editors are extremely grateful to those who, in addition to
+   finding errors and omissions in the DNSSEC document set, have
+   provided text suitable for inclusion in this document.
+
+   The lack of specificity about handling private algorithms, as
+   described in Section 5.3, and the lack of specificity in handling ANY
+   queries, as described in Section 4.2, were discovered by David
+   Blacka.
+
+   The error in algorithm 1 key tag calculation, as described in
+   Section 5.5, was found by Abhijit Hayatnagarkar.  Donald Eastlake
+   contributed text for Section 5.5.
+
+   The bug relating to delegation NSEC RR's in Section 4.1 was found by
+   Roy Badami.  Roy Arends found the related problem with DNAME.
+
+   The errors in the [RFC4035] examples were found by Roy Arends, who
+   also contributed text for Section 6.3 of this document.
+
+   Text on the mandatory algorithm rules was derived from suggestions by
+   Matthijs Mekking and Ed Lewis.
+
+   The CD bit logic was analyzed in depth by David Blacka, Olafur
+   Gudmundsson, Mike St. Johns, and Andrew Sullivan.
+
+   The editors would like to thank Alfred Hoenes, Ed Lewis, Danny Mayer,
+   Olafur Gudmundsson, Suzanne Woolf, Rickard Bellgrim, Mike St. Johns,
+   Mark Andrews, Wouter Wijngaards, Matthijs Mekking, Andrew Sullivan,
+   Jeremy Reed, Paul Hoffman, Mohan Parthasarathy, Florian Weimer,
+   Warren Kumari and Scott Rose for their contributions to this
+   document.
+
+Appendix B.  Discussion of Setting the CD Bit
+
+   [RFC4035] may be read as relying on the implicit assumption that
+   there is at most one validating system between the stub resolver and
+   the authoritative server for a given zone.  It is entirely possible,
+   however, for more than one validator to exist between a stub resolver
+   and an authoritative server.  If these different validators have
+   disjoint trust anchors configured, then it is possible that each
+   would be able to validate some portion of the DNS tree, but neither
+
+
+
+
+
+Weiler & Blacka              Standards Track                   [Page 16]
+
+RFC 6840               DNSSEC Implementation Notes         February 2013
+
+
+   is able to validate all of it.  Accordingly, it might be argued that
+   it is desirable not to set the CD bit on upstream queries, because
+   that allows for maximal validation.
+
+   In Section 5.9 of this document, it is recommended to set the CD bit
+   on an upstream query even when the incoming query arrives with CD=0.
+   This is for two reasons: it encourages a more predictable validation
+   experience as only one validator is always doing the validation, and
+   it ensures that all DNSSEC data that exists may be available from the
+   local cache should a query with CD=1 arrive.
+
+   As a matter of policy, it is possible to set the CD bit differently
+   than suggested in Section 5.9.  A different choice will, of course,
+   not always yield the benefits listed above.  It is beyond the scope
+   of this document to outline all of the considerations and counter
+   considerations for all possible policies.  Nevertheless, it is
+   possible to describe three approaches and their underlying philosophy
+   of operation.  These are laid out in the tables below.
+
+   The table that describes each model has five columns.  The first
+   column indicates the value of the CD bit that the resolver receives
+   (for instance, on the name server side in an iterative resolver, or
+   as local policy or from the API in the case of a stub).  The second
+   column indicates whether the query needs to be forwarded for
+   resolution (F) or can be satisfied from a local cache (C).  The third
+   column is a line number, so that it can be referred to later in the
+   table.  The fourth column indicates any relevant conditions at the
+   resolver, for example, whether the resolver has a covering trust
+   anchor, and so on.  If there are no parameters here, the column is
+   empty.  The fifth and final column indicates what action the resolver
+   takes.
+
+   The tables differentiate between "cached data" and "cached RCODE=2".
+   This is a shorthand; the point is that one has to treat RCODE=2
+   (server failure) as special, because it might indicate a validation
+   failure somewhere upstream.  The distinction is really between
+   "cached RCODE=2" and "cached everything else".
+
+   The tables are probably easiest to think of in terms of describing
+   what happens when a stub resolver sends a query to an intermediate
+   resolver, but they are perfectly general and can be applied to any
+   validating resolver.
+
+   Model 1: "always set"
+
+   This model is so named because the validating resolver sets the CD
+   bit on queries it makes regardless of whether it has a covering trust
+   anchor for the query.  The general philosophy represented by this
+
+
+
+Weiler & Blacka              Standards Track                   [Page 17]
+
+RFC 6840               DNSSEC Implementation Notes         February 2013
+
+
+   table is that only one resolver should be responsible for validation
+   irrespective of the possibility that an upstream resolver may be
+   present with trust anchors that cover different or additional QNAMEs.
+   It is the model recommended in Section 5.9 of this document.
+
+    CD F/C    line      conditions            action
+    ====================================================================
+    1   F      A1                             Set CD=1 on upstream query
+    0   F      A2                             Set CD=1 on upstream query
+    1   C      A3                             Return the cache contents
+                                               (data or RCODE=2)
+    0   C      A4       no covering TA        Return cache contents
+                                               (data or RCODE=2)
+    0   C      A5       covering TA           Validate cached result and
+                                               return it
+
+   Model 2: "never set when receiving CD=0"
+
+   This model is so named because it sets CD=0 on upstream queries for
+   all received CD=0 queries, even if it has a covering trust anchor.
+   The general philosophy represented by this table is that more than
+   one resolver may take responsibility for validating a QNAME and that
+   a validation failure for a QNAME by any resolver in the chain is a
+   validation failure for the query.  Using this model is NOT
+   RECOMMENDED.
+
+    CD F/C    line       conditions           action
+    ====================================================================
+    1  F      N1                              Set CD=1 on upstream query
+    0  F      N2                              Set CD=0 on upstream query
+    1  C      N3         cached data          Return cached data
+    1  C      N4         cached RCODE=2       Treat as line N1
+    0  C      N5         no covering TA       Return cache contents
+                                               (data or RCODE=2)
+    0  C      N6         covering TA &        Treat as line N2
+                          cached data was
+                          generated with CD=1
+    0  C      N7         covering TA &        Validate and return
+                          cached data was
+                          generated with CD=0
+
+
+   Model 3: "sometimes set"
+
+   This model is so named because it sets the CD bit on upstream queries
+   triggered by received CD=0 queries, based on whether the validator
+   has a trust anchor configured that covers the query.  If there is no
+   covering trust anchor, the resolver clears the CD bit in the upstream
+
+
+
+Weiler & Blacka              Standards Track                   [Page 18]
+
+RFC 6840               DNSSEC Implementation Notes         February 2013
+
+
+   query.  If there is a covering trust anchor, the resolver sets CD=1
+   and performs validation itself.  The general philosophy represented
+   by this table is that a resolver should try and validate QNAMEs for
+   which it has trust anchors and should not preclude validation by
+   other resolvers for QNAMEs for which it does not have covering trust
+   anchors.  Using this model is NOT RECOMMENDED.
+
+    CD F/C    line       conditions         action
+    ====================================================================
+    1  F      S1                            Set CD=1 on upstream query
+    0  F      S2         covering TA        Set CD=1 on upstream query
+    0  F      S3         no covering TA     Set CD=0 on upstream query
+    1  C      S4         cached data        Return cached data
+    1  C      S5         cached RCODE=2     Treat as line S1
+    0  C      S6         cached data was    Return cache contents
+                          generated with
+                          CD=0
+    0  C      S7         cached data was    Validate & return cache
+                          generated with     contents
+                          CD=1 &
+                          covering TA
+    0  C      S8         cached RCODE=2     Return cache contents
+    0  C      S9         cached data        Treat as line S3
+                          was generated
+                          with CD=1 &
+                          no covering
+                          TA
+
+
+Appendix C.  Discussion of Trust Anchor Preference Options
+
+   This section presents several different policies for validating
+   resolvers to use when they have a choice of trust anchors available
+   for validating a given answer.
+
+C.1.  Closest Encloser
+
+   One policy is to choose the trust anchor closest to the QNAME of the
+   response.  For example, consider a validator configured with trust
+   anchors for "example." and "zone.example."  When asked to validate a
+   response for "www.sub.zone.example.", a validator using the "Closest
+   Encloser" policy would choose the "zone.example." trust anchor.
+
+   This policy has the advantage of allowing the operator to trivially
+   override a parent zone's trust anchor with one that the operator can
+   validate in a stronger way, perhaps because the resolver operator is
+
+
+
+
+
+Weiler & Blacka              Standards Track                   [Page 19]
+
+RFC 6840               DNSSEC Implementation Notes         February 2013
+
+
+   affiliated with the zone in question.  This policy also minimizes the
+   number of public key operations needed, which is of benefit in
+   resource-constrained environments.
+
+   This policy has the disadvantage of giving the user some unexpected
+   and unnecessary validation failures when sub-zone trust anchors are
+   neglected.  As a concrete example, consider a validator that
+   configured a trust anchor for "zone.example." in 2009 and one for
+   "example." in 2011.  In 2012, "zone.example." rolls its Key Signing
+   Key (KSK) and updates its DS records, but the validator operator
+   doesn't update its trust anchor.  With the "Closest Encloser" policy,
+   the validator gets validation failures.
+
+C.2.  Accept Any Success
+
+   Another policy is to try all applicable trust anchors until one gives
+   a validation result of Secure, in which case the final validation
+   result is Secure.  If and only if all applicable trust anchors give a
+   result of Insecure, the final validation result is Insecure.  If one
+   or more trust anchors lead to a Bogus result and there is no Secure
+   result, then the final validation result is Bogus.
+
+   This has the advantage of causing the fewest validation failures,
+   which may deliver a better user experience.  If one trust anchor is
+   out of date (as in our above example), the user may still be able to
+   get a Secure validation result (and see DNS responses).
+
+   This policy has the disadvantage of making the validator subject to
+   the compromise of the weakest of these trust anchors, while making it
+   relatively painless to keep old trust anchors configured in
+   perpetuity.
+
+C.3.  Preference Based on Source
+
+   When the trust anchors have come from different sources (e.g.,
+   automated updates ([RFC5011]), one or more DNSSEC Lookaside
+   Validation (DLV) registries ([RFC5074]), and manual configuration), a
+   validator may wish to choose between them based on the perceived
+   reliability of those sources.  The order of precedence might be
+   exposed as a configuration option.
+
+   For example, a validator might choose to prefer trust anchors found
+   in a DLV registry over those manually configured on the theory that
+   the manually configured ones will not be as aggressively maintained.
+
+
+
+
+
+
+
+Weiler & Blacka              Standards Track                   [Page 20]
+
+RFC 6840               DNSSEC Implementation Notes         February 2013
+
+
+   Conversely, a validator might choose to prefer manually configured
+   trust anchors over those obtained from a DLV registry on the theory
+   that the manually configured ones have been more carefully
+   authenticated.
+
+   Or the validator might do something more complex: prefer a sub-set of
+   manually configured trust anchors (based on a configuration option),
+   then trust anchors that have been updated using the mechanism in
+   [RFC5011], then trust anchors from one DLV registry, then trust
+   anchors from a different DLV registry, then the rest of the manually
+   configured trust anchors.
+
+Authors' Addresses
+
+   Samuel Weiler (editor)
+   SPARTA, Inc.
+   7110 Samuel Morse Drive
+   Columbia, MD  21046
+   US
+
+   EMail: weiler@tislabs.com
+
+
+   David Blacka (editor)
+   Verisign, Inc.
+   12061 Bluemont Way
+   Reston, VA  20190
+   US
+
+   EMail: davidb@verisign.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Weiler & Blacka              Standards Track                   [Page 21]
+
diff --git a/doc/rfc/rfc6891.txt b/doc/rfc/rfc6891.txt
new file mode 100644
index 0000000000..bce1c78622
--- /dev/null
+++ b/doc/rfc/rfc6891.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                          J. Damas
+Request for Comments: 6891                         Bond Internet Systems
+STD: 75                                                         M. Graff
+Obsoletes: 2671, 2673
+Category: Standards Track                                       P. Vixie
+ISSN: 2070-1721                              Internet Systems Consortium
+                                                              April 2013
+
+
+                 Extension Mechanisms for DNS (EDNS(0))
+
+Abstract
+
+   The Domain Name System's wire protocol includes a number of fixed
+   fields whose range has been or soon will be exhausted and does not
+   allow requestors to advertise their capabilities to responders.  This
+   document describes backward-compatible mechanisms for allowing the
+   protocol to grow.
+
+   This document updates the Extension Mechanisms for DNS (EDNS(0))
+   specification (and obsoletes RFC 2671) based on feedback from
+   deployment experience in several implementations.  It also obsoletes
+   RFC 2673 ("Binary Labels in the Domain Name System") and adds
+   considerations on the use of extended labels in the DNS.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6891.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Damas, et al.                Standards Track                    [Page 1]
+
+RFC 6891                   EDNS(0) Extensions                 April 2013
+
+
+Copyright Notice
+
+   Copyright (c) 2013 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.
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Damas, et al.                Standards Track                    [Page 2]
+
+RFC 6891                   EDNS(0) Extensions                 April 2013
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
+   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
+   3.  EDNS Support Requirement . . . . . . . . . . . . . . . . . . .  5
+   4.  DNS Message Changes  . . . . . . . . . . . . . . . . . . . . .  5
+     4.1.  Message Header . . . . . . . . . . . . . . . . . . . . . .  5
+     4.2.  Label Types  . . . . . . . . . . . . . . . . . . . . . . .  5
+     4.3.  UDP Message Size . . . . . . . . . . . . . . . . . . . . .  6
+   5.  Extended Label Types . . . . . . . . . . . . . . . . . . . . .  6
+   6.  The OPT Pseudo-RR  . . . . . . . . . . . . . . . . . . . . . .  6
+     6.1.  OPT Record Definition  . . . . . . . . . . . . . . . . . .  6
+       6.1.1.  Basic Elements . . . . . . . . . . . . . . . . . . . .  6
+       6.1.2.  Wire Format  . . . . . . . . . . . . . . . . . . . . .  7
+       6.1.3.  OPT Record TTL Field Use . . . . . . . . . . . . . . .  9
+       6.1.4.  Flags  . . . . . . . . . . . . . . . . . . . . . . . .  9
+     6.2.  Behaviour  . . . . . . . . . . . . . . . . . . . . . . . . 10
+       6.2.1.  Cache Behaviour  . . . . . . . . . . . . . . . . . . . 10
+       6.2.2.  Fallback . . . . . . . . . . . . . . . . . . . . . . . 10
+       6.2.3.  Requestor's Payload Size . . . . . . . . . . . . . . . 10
+       6.2.4.  Responder's Payload Size . . . . . . . . . . . . . . . 11
+       6.2.5.  Payload Size Selection . . . . . . . . . . . . . . . . 11
+       6.2.6.  Support in Middleboxes . . . . . . . . . . . . . . . . 11
+   7.  Transport Considerations . . . . . . . . . . . . . . . . . . . 12
+   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
+   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
+     9.1.  OPT Option Code Allocation Procedure . . . . . . . . . . . 15
+   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
+     10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
+     10.2. Informative References . . . . . . . . . . . . . . . . . . 15
+   Appendix A.  Changes since RFCs 2671 and 2673  . . . . . . . . . . 16
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Damas, et al.                Standards Track                    [Page 3]
+
+RFC 6891                   EDNS(0) Extensions                 April 2013
+
+
+1.  Introduction
+
+   DNS [RFC1035] specifies a message format, and within such messages
+   there are standard formats for encoding options, errors, and name
+   compression.  The maximum allowable size of a DNS message over UDP
+   not using the extensions described in this document is 512 bytes.
+   Many of DNS's protocol limits, such as the maximum message size over
+   UDP, are too small to efficiently support the additional information
+   that can be conveyed in the DNS (e.g., several IPv6 addresses or DNS
+   Security (DNSSEC) signatures).  Finally, RFC 1035 does not define any
+   way for implementations to advertise their capabilities to any of the
+   other actors they interact with.
+
+   [RFC2671] added extension mechanisms to DNS.  These mechanisms are
+   widely supported, and a number of new DNS uses and protocol
+   extensions depend on the presence of these extensions.  This memo
+   refines and obsoletes [RFC2671].
+
+   Unextended agents will not know how to interpret the protocol
+   extensions defined in [RFC2671] and restated here.  Extended agents
+   need to be prepared for handling the interactions with unextended
+   clients in the face of new protocol elements and fall back gracefully
+   to unextended DNS.
+
+   EDNS is a hop-by-hop extension to DNS.  This means the use of EDNS is
+   negotiated between each pair of hosts in a DNS resolution process,
+   for instance, the stub resolver communicating with the recursive
+   resolver or the recursive resolver communicating with an
+   authoritative server.
+
+   [RFC2671] specified extended label types.  The only such label
+   proposed was in [RFC2673] for a label type called "Bit-String Label"
+   or "Binary Labels", with this latest term being the one in common
+   use.  For various reasons, introducing a new label type was found to
+   be extremely difficult, and [RFC2673] was moved to Experimental.
+   This document obsoletes [RFC2673], deprecating Binary Labels.
+   Extended labels remain defined, but their use is discouraged due to
+   practical difficulties with deployment; their use in the future
+   SHOULD only be considered after careful evaluation of the deployment
+   hindrances.
+
+2.  Terminology
+
+   "Requestor" refers to the side that sends a request.  "Responder"
+   refers to an authoritative, recursive resolver or other DNS component
+   that responds to questions.  Other terminology is used here as
+   defined in the RFCs cited by this document.
+
+
+
+
+Damas, et al.                Standards Track                    [Page 4]
+
+RFC 6891                   EDNS(0) Extensions                 April 2013
+
+
+   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].
+
+3.  EDNS Support Requirement
+
+   EDNS provides a mechanism to improve the scalability of DNS as its
+   uses get more diverse on the Internet.  It does this by enabling the
+   use of UDP transport for DNS messages with sizes beyond the limits
+   specified in RFC 1035 as well as providing extra data space for
+   additional flags and return codes (RCODEs).  However, implementation
+   experience indicates that adding new RCODEs should be avoided due to
+   the difficulty in upgrading the installed base.  Flags SHOULD be used
+   only when necessary for DNS resolution to function.
+
+   For many uses, an EDNS Option Code may be preferred.
+
+   Over time, some applications of DNS have made EDNS a requirement for
+   their deployment.  For instance, DNSSEC uses the additional flag
+   space introduced in EDNS to signal the request to include DNSSEC data
+   in a DNS response.
+
+   Given the increase in DNS response sizes when including larger data
+   items such as AAAA records, DNSSEC information (e.g., RRSIG or
+   DNSKEY), or large TXT records, the additional UDP payload
+   capabilities provided by EDNS can help improve the scalability of the
+   DNS by avoiding widespread use of TCP for DNS transport.
+
+4.  DNS Message Changes
+
+4.1.  Message Header
+
+   The DNS message header's second full 16-bit word is divided into a
+   4-bit OPCODE, a 4-bit RCODE, and a number of 1-bit flags (see Section
+   4.1.1 of [RFC1035]).  Some of these flag values were marked for
+   future use, and most of these have since been allocated.  Also, most
+   of the RCODE values are now in use.  The OPT pseudo-RR specified
+   below contains extensions to the RCODE bit field as well as
+   additional flag bits.
+
+4.2.  Label Types
+
+   The first 2 bits of a wire format domain label are used to denote the
+   type of the label.  [RFC1035] allocates 2 of the 4 possible types and
+   reserves the other 2.  More label types were defined in [RFC2671].
+   The use of the 2-bit combination defined by [RFC2671] to identify
+   extended label types remains valid.  However, it has been found that
+   deployment of new label types is noticeably difficult and so is only
+
+
+
+Damas, et al.                Standards Track                    [Page 5]
+
+RFC 6891                   EDNS(0) Extensions                 April 2013
+
+
+   recommended after careful evaluation of alternatives and the need for
+   deployment.
+
+4.3.  UDP Message Size
+
+   Traditional DNS messages are limited to 512 octets in size when sent
+   over UDP [RFC1035].  Fitting the increasing amounts of data that can
+   be transported in DNS in this 512-byte limit is becoming more
+   difficult.  For instance, inclusion of DNSSEC records frequently
+   requires a much larger response than a 512-byte message can hold.
+
+   EDNS(0) specifies a way to advertise additional features such as
+   larger response size capability, which is intended to help avoid
+   truncated UDP responses, which in turn cause retry over TCP.  It
+   therefore provides support for transporting these larger packet sizes
+   without needing to resort to TCP for transport.
+
+5.  Extended Label Types
+
+   The first octet in the on-the-wire representation of a DNS label
+   specifies the label type; the basic DNS specification [RFC1035]
+   dedicates the 2 most significant bits of that octet for this purpose.
+
+   [RFC2671] defined DNS label type 0b01 for use as an indication for
+   extended label types.  A specific extended label type was selected by
+   the 6 least significant bits of the first octet.  Thus, extended
+   label types were indicated by the values 64-127 (0b01xxxxxx) in the
+   first octet of the label.
+
+   Extended label types are extremely difficult to deploy due to lack of
+   support in clients and intermediate gateways, as described in
+   [RFC3363], which moved [RFC2673] to Experimental status; and
+   [RFC3364], which describes the pros and cons.  As such, proposals
+   that contemplate extended labels SHOULD weigh this deployment cost
+   against the possibility of implementing functionality in other ways.
+
+   Finally, implementations MUST NOT generate or pass Binary Labels in
+   their communications, as they are now deprecated.
+
+6.  The OPT Pseudo-RR
+
+6.1.  OPT Record Definition
+
+6.1.1.  Basic Elements
+
+   An OPT pseudo-RR (sometimes called a meta-RR) MAY be added to the
+   additional data section of a request.
+
+
+
+
+Damas, et al.                Standards Track                    [Page 6]
+
+RFC 6891                   EDNS(0) Extensions                 April 2013
+
+
+   The OPT RR has RR type 41.
+
+   If an OPT record is present in a received request, compliant
+   responders MUST include an OPT record in their respective responses.
+
+   An OPT record does not carry any DNS data.  It is used only to
+   contain control information pertaining to the question-and-answer
+   sequence of a specific transaction.  OPT RRs MUST NOT be cached,
+   forwarded, or stored in or loaded from master files.
+
+   The OPT RR MAY be placed anywhere within the additional data section.
+   When an OPT RR is included within any DNS message, it MUST be the
+   only OPT RR in that message.  If a query message with more than one
+   OPT RR is received, a FORMERR (RCODE=1) MUST be returned.  The
+   placement flexibility for the OPT RR does not override the need for
+   the TSIG or SIG(0) RRs to be the last in the additional section
+   whenever they are present.
+
+6.1.2.  Wire Format
+
+   An OPT RR has a fixed part and a variable set of options expressed as
+   {attribute, value} pairs.  The fixed part holds some DNS metadata,
+   and also a small collection of basic extension elements that we
+   expect to be so popular that it would be a waste of wire space to
+   encode them as {attribute, value} pairs.
+
+   The fixed part of an OPT RR is structured as follows:
+
+       +------------+--------------+------------------------------+
+       | Field Name | Field Type   | Description                  |
+       +------------+--------------+------------------------------+
+       | NAME       | domain name  | MUST be 0 (root domain)      |
+       | TYPE       | u_int16_t    | OPT (41)                     |
+       | CLASS      | u_int16_t    | requestor's UDP payload size |
+       | TTL        | u_int32_t    | extended RCODE and flags     |
+       | RDLEN      | u_int16_t    | length of all RDATA          |
+       | RDATA      | octet stream | {attribute,value} pairs      |
+       +------------+--------------+------------------------------+
+
+                               OPT RR Format
+
+
+
+
+
+
+
+
+
+
+
+Damas, et al.                Standards Track                    [Page 7]
+
+RFC 6891                   EDNS(0) Extensions                 April 2013
+
+
+   The variable part of an OPT RR may contain zero or more options in
+   the RDATA.  Each option MUST be treated as a bit field.  Each option
+   is encoded as:
+
+                  +0 (MSB)                            +1 (LSB)
+       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+    0: |                          OPTION-CODE                          |
+       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+    2: |                         OPTION-LENGTH                         |
+       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+    4: |                                                               |
+       /                          OPTION-DATA                          /
+       /                                                               /
+       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+
+   OPTION-CODE
+      Assigned by the Expert Review process as defined by the DNSEXT
+      working group and the IESG.
+
+   OPTION-LENGTH
+      Size (in octets) of OPTION-DATA.
+
+   OPTION-DATA
+      Varies per OPTION-CODE.  MUST be treated as a bit field.
+
+   The order of appearance of option tuples is not defined.  If one
+   option modifies the behaviour of another or multiple options are
+   related to one another in some way, they have the same effect
+   regardless of ordering in the RDATA wire encoding.
+
+   Any OPTION-CODE values not understood by a responder or requestor
+   MUST be ignored.  Specifications of such options might wish to
+   include some kind of signaled acknowledgement.  For example, an
+   option specification might say that if a responder sees and supports
+   option XYZ, it MUST include option XYZ in its response.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Damas, et al.                Standards Track                    [Page 8]
+
+RFC 6891                   EDNS(0) Extensions                 April 2013
+
+
+6.1.3.  OPT Record TTL Field Use
+
+   The extended RCODE and flags, which OPT stores in the RR Time to Live
+   (TTL) field, are structured as follows:
+
+                  +0 (MSB)                            +1 (LSB)
+       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+    0: |         EXTENDED-RCODE        |            VERSION            |
+       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+    2: | DO|                           Z                               |
+       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+
+   EXTENDED-RCODE
+      Forms the upper 8 bits of extended 12-bit RCODE (together with the
+      4 bits defined in [RFC1035].  Note that EXTENDED-RCODE value 0
+      indicates that an unextended RCODE is in use (values 0 through
+      15).
+
+   VERSION
+      Indicates the implementation level of the setter.  Full
+      conformance with this specification is indicated by version '0'.
+      Requestors are encouraged to set this to the lowest implemented
+      level capable of expressing a transaction, to minimise the
+      responder and network load of discovering the greatest common
+      implementation level between requestor and responder.  A
+      requestor's version numbering strategy MAY ideally be a run-time
+      configuration option.
+      If a responder does not implement the VERSION level of the
+      request, then it MUST respond with RCODE=BADVERS.  All responses
+      MUST be limited in format to the VERSION level of the request, but
+      the VERSION of each response SHOULD be the highest implementation
+      level of the responder.  In this way, a requestor will learn the
+      implementation level of a responder as a side effect of every
+      response, including error responses and including RCODE=BADVERS.
+
+6.1.4.  Flags
+
+   DO
+      DNSSEC OK bit as defined by [RFC3225].
+
+   Z
+      Set to zero by senders and ignored by receivers, unless modified
+      in a subsequent specification.
+
+
+
+
+
+
+
+
+Damas, et al.                Standards Track                    [Page 9]
+
+RFC 6891                   EDNS(0) Extensions                 April 2013
+
+
+6.2.  Behaviour
+
+6.2.1.  Cache Behaviour
+
+   The OPT record MUST NOT be cached.
+
+6.2.2.  Fallback
+
+   If a requestor detects that the remote end does not support EDNS(0),
+   it MAY issue queries without an OPT record.  It MAY cache this
+   knowledge for a brief time in order to avoid fallback delays in the
+   future.  However, if DNSSEC or any future option using EDNS is
+   required, no fallback should be performed, as these options are only
+   signaled through EDNS.  If an implementation detects that some
+   servers for the zone support EDNS(0) while others would force the use
+   of TCP to fetch all data, preference MAY be given to servers that
+   support EDNS(0).  Implementers SHOULD analyse this choice and the
+   impact on both endpoints.
+
+6.2.3.  Requestor's Payload Size
+
+   The requestor's UDP payload size (encoded in the RR CLASS field) is
+   the number of octets of the largest UDP payload that can be
+   reassembled and delivered in the requestor's network stack.  Note
+   that path MTU, with or without fragmentation, could be smaller than
+   this.
+
+   Values lower than 512 MUST be treated as equal to 512.
+
+   The requestor SHOULD place a value in this field that it can actually
+   receive.  For example, if a requestor sits behind a firewall that
+   will block fragmented IP packets, a requestor SHOULD NOT choose a
+   value that will cause fragmentation.  Doing so will prevent large
+   responses from being received and can cause fallback to occur.  This
+   knowledge may be auto-detected by the implementation or provided by a
+   human administrator.
+
+   Note that a 512-octet UDP payload requires a 576-octet IP reassembly
+   buffer.  Choosing between 1280 and 1410 bytes for IP (v4 or v6) over
+   Ethernet would be reasonable.
+
+   Where fragmentation is not a concern, use of bigger values SHOULD be
+   considered by implementers.  Implementations SHOULD use their largest
+   configured or implemented values as a starting point in an EDNS
+   transaction in the absence of previous knowledge about the
+   destination server.
+
+
+
+
+
+Damas, et al.                Standards Track                   [Page 10]
+
+RFC 6891                   EDNS(0) Extensions                 April 2013
+
+
+   Choosing a very large value will guarantee fragmentation at the IP
+   layer, and may prevent answers from being received due to loss of a
+   single fragment or to misconfigured firewalls.
+
+   The requestor's maximum payload size can change over time.  It MUST
+   NOT be cached for use beyond the transaction in which it is
+   advertised.
+
+6.2.4.  Responder's Payload Size
+
+   The responder's maximum payload size can change over time but can
+   reasonably be expected to remain constant between two closely spaced
+   sequential transactions, for example, an arbitrary QUERY used as a
+   probe to discover a responder's maximum UDP payload size, followed
+   immediately by an UPDATE that takes advantage of this size.  This is
+   considered preferable to the outright use of TCP for oversized
+   requests, if there is any reason to suspect that the responder
+   implements EDNS, and if a request will not fit in the default
+   512-byte payload size limit.
+
+6.2.5.  Payload Size Selection
+
+   Due to transaction overhead, it is not recommended to advertise an
+   architectural limit as a maximum UDP payload size.  Even on system
+   stacks capable of reassembling 64 KB datagrams, memory usage at low
+   levels in the system will be a concern.  A good compromise may be the
+   use of an EDNS maximum payload size of 4096 octets as a starting
+   point.
+
+   A requestor MAY choose to implement a fallback to smaller advertised
+   sizes to work around firewall or other network limitations.  A
+   requestor SHOULD choose to use a fallback mechanism that begins with
+   a large size, such as 4096.  If that fails, a fallback around the
+   range of 1280-1410 bytes SHOULD be tried, as it has a reasonable
+   chance to fit within a single Ethernet frame.  Failing that, a
+   requestor MAY choose a 512-byte packet, which with large answers may
+   cause a TCP retry.
+
+   Values of less than 512 bytes MUST be treated as equal to 512 bytes.
+
+6.2.6.  Support in Middleboxes
+
+   In a network that carries DNS traffic, there could be active
+   equipment other than that participating directly in the DNS
+   resolution process (stub and caching resolvers, authoritative
+   servers) that affects the transmission of DNS messages (e.g.,
+   firewalls, load balancers, proxies, etc.), referred to here as
+   "middleboxes".
+
+
+
+Damas, et al.                Standards Track                   [Page 11]
+
+RFC 6891                   EDNS(0) Extensions                 April 2013
+
+
+   Conformant middleboxes MUST NOT limit DNS messages over UDP to 512
+   bytes.
+
+   Middleboxes that simply forward requests to a recursive resolver MUST
+   NOT modify and MUST NOT delete the OPT record contents in either
+   direction.
+
+   Middleboxes that have additional functionality, such as answering
+   queries or acting as intelligent forwarders, SHOULD be able to
+   process the OPT record and act based on its contents.  These
+   middleboxes MUST consider the incoming request and any outgoing
+   requests as separate transactions if the characteristics of the
+   messages are different.
+
+   A more in-depth discussion of this type of equipment and other
+   considerations regarding their interaction with DNS traffic is found
+   in [RFC5625].
+
+7.  Transport Considerations
+
+   The presence of an OPT pseudo-RR in a request should be taken as an
+   indication that the requestor fully implements the given version of
+   EDNS and can correctly understand any response that conforms to that
+   feature's specification.
+
+   Lack of presence of an OPT record in a request MUST be taken as an
+   indication that the requestor does not implement any part of this
+   specification and that the responder MUST NOT include an OPT record
+   in its response.
+
+   Extended agents MUST be prepared for handling interactions with
+   unextended clients in the face of new protocol elements and fall back
+   gracefully to unextended DNS when needed.
+
+   Responders that choose not to implement the protocol extensions
+   defined in this document MUST respond with a return code (RCODE) of
+   FORMERR to messages containing an OPT record in the additional
+   section and MUST NOT include an OPT record in the response.
+
+   If there is a problem with processing the OPT record itself, such as
+   an option value that is badly formatted or that includes out-of-range
+   values, a FORMERR MUST be returned.  If this occurs, the response
+   MUST include an OPT record.  This is intended to allow the requestor
+   to distinguish between servers that do not implement EDNS and format
+   errors within EDNS.
+
+
+
+
+
+
+Damas, et al.                Standards Track                   [Page 12]
+
+RFC 6891                   EDNS(0) Extensions                 April 2013
+
+
+   The minimal response MUST be the DNS header, question section, and an
+   OPT record.  This MUST also occur when a truncated response (using
+   the DNS header's TC bit) is returned.
+
+8.  Security Considerations
+
+   Requestor-side specification of the maximum buffer size may open a
+   DNS denial-of-service attack if responders can be made to send
+   messages that are too large for intermediate gateways to forward,
+   thus leading to potential ICMP storms between gateways and
+   responders.
+
+   Announcing very large UDP buffer sizes may result in dropping of DNS
+   messages by middleboxes (see Section 6.2.6).  This could cause
+   retransmissions with no hope of success.  Some devices have been
+   found to reject fragmented UDP packets.
+
+   Announcing UDP buffer sizes that are too small may result in fallback
+   to TCP with a corresponding load impact on DNS servers.  This is
+   especially important with DNSSEC, where answers are much larger.
+
+9.  IANA Considerations
+
+   The IANA has assigned RR type code 41 for OPT.
+
+   [RFC2671] specified a number of IANA subregistries within "DOMAIN
+   NAME SYSTEM PARAMETERS":
+
+   o  DNS EDNS(0) Options
+
+   o  EDNS Version Number
+
+   o  EDNS Header Flags
+
+   Additionally, two entries were generated in existing registries:
+
+   o  EDNS Extended Label Type in the DNS Label Types registry
+
+   o  Bad OPT Version in the DNS RCODES registry
+
+   IANA has updated references to [RFC2671] in these entries and
+   subregistries to this document.
+
+   [RFC2671] created the DNS Label Types registry.  This registry is to
+   remain open.
+
+   The registration procedure for the DNS Label Types registry is
+   Standards Action.
+
+
+
+Damas, et al.                Standards Track                   [Page 13]
+
+RFC 6891                   EDNS(0) Extensions                 April 2013
+
+
+   This document assigns option code 65535 in the DNS EDNS0 Options
+   registry to "Reserved for future expansion".
+
+   The current status of the IANA registry for EDNS Option Codes at the
+   time of publication of this document is
+
+   o  0-4 assigned, per references in the registry
+
+   o  5-65000 Available for assignment, unassigned
+
+   o  65001-65534 Local/Experimental use
+
+   o  65535 Reserved for future expansion
+
+   [RFC2671] expands the RCODE space from 4 bits to 12 bits.  This
+   allows more than the 16 distinct RCODE values allowed in [RFC1035].
+   IETF Review is required to add a new RCODE.
+
+   This document assigns EDNS Extended RCODE 16 to "BADVERS" in the DNS
+   RCODES registry.
+
+   [RFC2671] called for the recording of assignment of extended label
+   types 0bxx111111 as "Reserved for future extended label types"; the
+   IANA registry currently contains "Reserved for future expansion".
+   This request implied, at that time, a request to open a new registry
+   for extended label types, but due to the possibility of ambiguity,
+   new text registrations were instead made within the general DNS Label
+   Types registry, which also registers entries originally defined by
+   [RFC1035].  There is therefore no Extended Label Types registry, with
+   all label types registered in the DNS Label Types registry.
+
+   This document deprecates Binary Labels.  Therefore, the status for
+   the DNS Label Types registration "Binary Labels" is now "Historic".
+
+   IETF Standards Action is required for assignments of new EDNS(0)
+   flags.  Flags SHOULD be used only when necessary for DNS resolution
+   to function.  For many uses, an EDNS Option Code may be preferred.
+
+   IETF Standards Action is required to create new entries in the EDNS
+   Version Number registry.  Within the EDNS Option Code space, Expert
+   Review is required for allocation of an EDNS Option Code.  Per this
+   document, IANA maintains a registry for the EDNS Option Code space.
+
+
+
+
+
+
+
+
+
+Damas, et al.                Standards Track                   [Page 14]
+
+RFC 6891                   EDNS(0) Extensions                 April 2013
+
+
+9.1.  OPT Option Code Allocation Procedure
+
+   OPT Option Codes are assigned by Expert Review.
+
+   Assignment of Option Codes should be liberal, but duplicate
+   functionality is to be avoided.
+
+10.  References
+
+10.1.  Normative References
+
+   [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.
+
+   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
+              RFC 2671, August 1999.
+
+   [RFC3225]  Conrad, D., "Indicating Resolver Support of DNSSEC",
+              RFC 3225, December 2001.
+
+10.2.  Informative References
+
+   [RFC2673]  Crawford, M., "Binary Labels in the Domain Name System",
+              RFC 2673, August 1999.
+
+   [RFC3363]  Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
+              Hain, "Representing Internet Protocol version 6 (IPv6)
+              Addresses in the Domain Name System (DNS)", RFC 3363,
+              August 2002.
+
+   [RFC3364]  Austein, R., "Tradeoffs in Domain Name System (DNS)
+              Support for Internet Protocol version 6 (IPv6)", RFC 3364,
+              August 2002.
+
+   [RFC5625]  Bellis, R., "DNS Proxy Implementation Guidelines",
+              BCP 152, RFC 5625, August 2009.
+
+
+
+
+
+
+
+
+
+
+
+
+Damas, et al.                Standards Track                   [Page 15]
+
+RFC 6891                   EDNS(0) Extensions                 April 2013
+
+
+Appendix A.  Changes since RFCs 2671 and 2673
+
+   Following is a list of high-level changes to RFCs 2671 and 2673.
+
+   o  Support for the OPT record is now mandatory.
+
+   o  Extended label types remain available, but their use is
+      discouraged as a general solution due to observed difficulties in
+      their deployment on the Internet, as illustrated by the work with
+      the "Binary Labels" type.
+
+   o  RFC 2673, which defined the "Binary Labels" type and is currently
+      Experimental, is requested to be moved to Historic.
+
+   o  Made changes in how EDNS buffer sizes are selected, and provided
+      recommendations on how to select them.
+
+Authors' Addresses
+
+   Joao Damas
+   Bond Internet Systems
+   Av Albufera 14
+   S.S. Reyes, Madrid  28701
+   ES
+
+   Phone: +1 650.423.1312
+   EMail: joao@bondis.org
+
+
+   Michael Graff
+
+   EMail: explorer@flame.org
+
+
+   Paul Vixie
+   Internet Systems Consortium
+   950 Charter Street
+   Redwood City, California  94063
+   US
+
+   Phone: +1 650.423.1301
+   EMail: vixie@isc.org
+
+
+
+
+
+
+
+
+
+Damas, et al.                Standards Track                   [Page 16]
+