doc: Add RFC documents

1 files changed, 1235 insertions, 0 deletions

diff --git a/doc/rfc/rfc6672.txt b/doc/rfc/rfc6672.txt
new file mode 100644
index 0000000..1534cf4
--- /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]
+