From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6672.txt | 1235 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1235 insertions(+) create mode 100644 doc/rfc/rfc6672.txt (limited to 'doc/rfc/rfc6672.txt') 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, , which contains a + fully qualified domain name that MUST be sent in uncompressed form + [RFC1035] [RFC3597]. The field MUST be present. The + presentation format of is that of a domain name [RFC1035]. + The presentation format of the RR is as follows: + + DNAME + + The effect of the DNAME RR is the substitution of the record's + 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. + 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. + 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 "". + + 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 for its + in QNAME would overflow the legal size for a , 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] + -- cgit v1.2.3