--- 1/draft-ietf-dnsext-rfc2672bis-dname-24.txt 2011-11-14 16:14:08.626754161 +0100 +++ 2/draft-ietf-dnsext-rfc2672bis-dname-25.txt 2011-11-14 16:14:08.662804921 +0100 @@ -1,51 +1,53 @@ DNS Extensions Working Group S. Rose Internet-Draft NIST Obsoletes: 2672 (if approved) W. Wijngaards Updates: 3363,4294 (if approved) NLnet Labs -Intended status: Standards Track July 26, 2011 -Expires: January 27, 2012 +Intended status: Standards Track November 14, 2011 +Expires: May 17, 2012 DNAME Redirection in the DNS - draft-ietf-dnsext-rfc2672bis-dname-24 + draft-ietf-dnsext-rfc2672bis-dname-25 Abstract The DNAME record provides redirection for a sub-tree of the domain name tree in the DNS system. That is, all names that end with a particular suffix are redirected to another part of the DNS. This is - a revision to the original specification in RFC 2672 as well as - updating RFC 3363 and RFC 4294 to align with this revision. + a revision to the original specification in RFC 2672 (which this + document obsoletes) as well as updating RFC 3363 and RFC 4294 to + align with this revision. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [RFC2119]. + "SHOULD", "SHOULD NOT", "RECOMMENDED" "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in RFC + 2119 [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on January 27, 2012. + This Internet-Draft will expire on May 17, 2012. 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 @@ -62,65 +64,69 @@ modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 2. The DNAME Resource Record . . . . . . . . . . . . . . . . . . 4 - 2.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 2.2. The DNAME Substitution . . . . . . . . . . . . . . . . . . 5 - 2.3. DNAME Owner Name Matching the QNAME . . . . . . . . . . . 7 - 2.4. Names Next to and Below a DNAME Record . . . . . . . . . . 7 - 2.5. Compression of the DNAME record. . . . . . . . . . . . . . 7 + 2. The DNAME Resource Record . . . . . . . . . . . . . . . . . . 5 + 2.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 2.2. The DNAME Substitution . . . . . . . . . . . . . . . . . . 6 + 2.3. DNAME Owner Name Matching the QNAME . . . . . . . . . . . 8 + 2.4. Names Next to and Below a DNAME Record . . . . . . . . . . 8 + 2.5. Compression of the DNAME record. . . . . . . . . . . . . . 8 - 3. Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 3.1. CNAME synthesis . . . . . . . . . . . . . . . . . . . . . 8 - 3.2. Server algorithm . . . . . . . . . . . . . . . . . . . . . 9 - 3.3. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . 11 - 3.4. Acceptance and Intermediate Storage . . . . . . . . . . . 11 - 3.4.1. Resolver Algorithm . . . . . . . . . . . . . . . . . . 11 + 3. Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 3.1. CNAME synthesis . . . . . . . . . . . . . . . . . . . . . 9 + 3.2. Server algorithm . . . . . . . . . . . . . . . . . . . . . 10 + 3.3. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . 12 + 3.4. Acceptance and Intermediate Storage . . . . . . . . . . . 12 + 3.4.1. Resolver Algorithm . . . . . . . . . . . . . . . . . . 12 - 4. DNAME Discussions in Other Documents . . . . . . . . . . . . . 12 + 4. DNAME Discussions in Other Documents . . . . . . . . . . . . . 13 - 5. Other Issues with DNAME . . . . . . . . . . . . . . . . . . . 14 - 5.1. Canonical hostnames cannot be below DNAME owners . . . . . 14 - 5.2. Dynamic Update and DNAME . . . . . . . . . . . . . . . . . 14 - 5.3. DNSSEC and DNAME . . . . . . . . . . . . . . . . . . . . . 14 - 5.3.1. Signed DNAME, Unsigned Synthesized CNAME . . . . . . . 14 - 5.3.2. DNAME Bit in NSEC Type Map . . . . . . . . . . . . . . 15 - 5.3.3. DNAME Chains as Strong as the Weakest Link . . . . . . 15 - 5.3.4. Validators Must Understand DNAME . . . . . . . . . . . 15 - 5.3.4.1. DNAME in Bitmap Causes Invalid Name Error . . . . 15 + 5. Other Issues with DNAME . . . . . . . . . . . . . . . . . . . 15 + 5.1. Canonical hostnames cannot be below DNAME owners . . . . . 15 + 5.2. Dynamic Update and DNAME . . . . . . . . . . . . . . . . . 15 + 5.3. DNSSEC and DNAME . . . . . . . . . . . . . . . . . . . . . 15 + 5.3.1. Signed DNAME, Unsigned Synthesized CNAME . . . . . . . 15 + 5.3.2. DNAME Bit in NSEC Type Map . . . . . . . . . . . . . . 16 + 5.3.3. DNAME Chains as Strong as the Weakest Link . . . . . . 16 + 5.3.4. Validators Must Understand DNAME . . . . . . . . . . . 16 + 5.3.4.1. DNAME in Bitmap Causes Invalid Name Error . . . . 16 5.3.4.2. Valid Name Error Response Involving DNAME in - Bitmap . . . . . . . . . . . . . . . . . . . . . . 16 - 5.3.4.3. Response With Synthesized CNAME . . . . . . . . . 16 + Bitmap . . . . . . . . . . . . . . . . . . . . . . 17 + 5.3.4.3. Response With Synthesized CNAME . . . . . . . . . 17 - 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 + 6. Examples of DNAME Use in a Zone . . . . . . . . . . . . . . . 17 + 6.1. Organizational Renaming . . . . . . . . . . . . . . . . . 17 + 6.2. Classless Delegation of Shorter Prefixes . . . . . . . . . 18 + 6.3. Network Renumbering Support . . . . . . . . . . . . . . . 18 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 - 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 + 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 - 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 - 10.2. Informative References . . . . . . . . . . . . . . . . . . 20 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 10.1. Normative References . . . . . . . . . . . . . . . . . . . 20 + 10.2. Informative References . . . . . . . . . . . . . . . . . . 21 + + Appendix A. Changes from RFC 2672 . . . . . . . . . . . . . . . . 21 + A.1. Changes to Server Behavior . . . . . . . . . . . . . . . . 21 + A.2. Changes to Client Behavior . . . . . . . . . . . . . . . . 22 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 @@ -155,21 +161,21 @@ added on problems that may be encountered when using DNAME. 2. The DNAME Resource Record 2.1. Format The DNAME RR has mnemonic DNAME and type code 39 (decimal). It is not class-sensitive. Its RDATA is comprised of a single field, , which contains a - fully qualified domain name that must be sent in uncompressed form + 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]. 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 @@ -282,22 +288,22 @@ 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, and thus no confusion which one to follow. A server SHOULD 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, - so that a DNAME RR can be treated as an unknown type [RFC3597]. + The DNAME RDATA target name MUST NOT be sent out in compressed form + and MUST be downcased for DNSSEC validation. 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 and this document also does not specify this signaling behavior. RFC 2672 (obsoleted by this document) stated that the EDNS version had a meaning for understanding of DNAME and DNAME target name compression. This document revises RFC 2672, in that there is no @@ -761,22 +767,24 @@ 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 has been - registered by [RFC2672]. IANA should update the DNS resource record - registry to point to this document for RR type 39. + registered by [RFC2672] in the DNS Resource Record (RR) Types + registry table at http://www.iana.org/assignments/dns-parameters. + IANA should update 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 @@ -857,20 +865,62 @@ 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. [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, April 2006. +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. + + 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 RR's is now set to the TTL of the + DNAME, not zero (Section 3.1). + + o Caching recursive 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 is 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 RR's and MAY cache + synthesized CNAME RR's it receives 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. + Authors' Addresses Scott Rose NIST 100 Bureau Dr. Gaithersburg, MD 20899 USA Phone: +1-301-975-8439 Fax: +1-301-975-6238