draft-ietf-dnsext-rfc2672bis-dname-24.txt   draft-ietf-dnsext-rfc2672bis-dname-25.txt 
DNS Extensions Working Group S. Rose DNS Extensions Working Group S. Rose
Internet-Draft NIST Internet-Draft NIST
Obsoletes: 2672 (if approved) W. Wijngaards Obsoletes: 2672 (if approved) W. Wijngaards
Updates: 3363,4294 (if approved) NLnet Labs Updates: 3363,4294 (if approved) NLnet Labs
Intended status: Standards Track July 26, 2011 Intended status: Standards Track November 14, 2011
Expires: January 27, 2012 Expires: May 17, 2012
DNAME Redirection in the DNS DNAME Redirection in the DNS
draft-ietf-dnsext-rfc2672bis-dname-24 draft-ietf-dnsext-rfc2672bis-dname-25
Abstract Abstract
The DNAME record provides redirection for a sub-tree of the domain 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 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 particular suffix are redirected to another part of the DNS. This is
a revision to the original specification in RFC 2672 as well as a revision to the original specification in RFC 2672 (which this
updating RFC 3363 and RFC 4294 to align with this revision. document obsoletes) as well as updating RFC 3363 and RFC 4294 to
align with this revision.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED" "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC 2119 [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC2119].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 7 skipping to change at page 3, line 7
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. The DNAME Resource Record . . . . . . . . . . . . . . . . . . 4 2. The DNAME Resource Record . . . . . . . . . . . . . . . . . . 5
2.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. The DNAME Substitution . . . . . . . . . . . . . . . . . . 5 2.2. The DNAME Substitution . . . . . . . . . . . . . . . . . . 6
2.3. DNAME Owner Name Matching the QNAME . . . . . . . . . . . 7 2.3. DNAME Owner Name Matching the QNAME . . . . . . . . . . . 8
2.4. Names Next to and Below a DNAME Record . . . . . . . . . . 7 2.4. Names Next to and Below a DNAME Record . . . . . . . . . . 8
2.5. Compression of the DNAME record. . . . . . . . . . . . . . 7 2.5. Compression of the DNAME record. . . . . . . . . . . . . . 8
3. Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. CNAME synthesis . . . . . . . . . . . . . . . . . . . . . 8 3.1. CNAME synthesis . . . . . . . . . . . . . . . . . . . . . 9
3.2. Server algorithm . . . . . . . . . . . . . . . . . . . . . 9 3.2. Server algorithm . . . . . . . . . . . . . . . . . . . . . 10
3.3. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . 11 3.3. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . 12
3.4. Acceptance and Intermediate Storage . . . . . . . . . . . 11 3.4. Acceptance and Intermediate Storage . . . . . . . . . . . 12
3.4.1. Resolver Algorithm . . . . . . . . . . . . . . . . . . 11 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. Other Issues with DNAME . . . . . . . . . . . . . . . . . . . 15
5.1. Canonical hostnames cannot be below DNAME owners . . . . . 14 5.1. Canonical hostnames cannot be below DNAME owners . . . . . 15
5.2. Dynamic Update and DNAME . . . . . . . . . . . . . . . . . 14 5.2. Dynamic Update and DNAME . . . . . . . . . . . . . . . . . 15
5.3. DNSSEC and DNAME . . . . . . . . . . . . . . . . . . . . . 14 5.3. DNSSEC and DNAME . . . . . . . . . . . . . . . . . . . . . 15
5.3.1. Signed DNAME, Unsigned Synthesized CNAME . . . . . . . 14 5.3.1. Signed DNAME, Unsigned Synthesized CNAME . . . . . . . 15
5.3.2. DNAME Bit in NSEC Type Map . . . . . . . . . . . . . . 15 5.3.2. DNAME Bit in NSEC Type Map . . . . . . . . . . . . . . 16
5.3.3. DNAME Chains as Strong as the Weakest Link . . . . . . 15 5.3.3. DNAME Chains as Strong as the Weakest Link . . . . . . 16
5.3.4. Validators Must Understand DNAME . . . . . . . . . . . 15 5.3.4. Validators Must Understand DNAME . . . . . . . . . . . 16
5.3.4.1. DNAME in Bitmap Causes Invalid Name Error . . . . 15 5.3.4.1. DNAME in Bitmap Causes Invalid Name Error . . . . 16
5.3.4.2. Valid Name Error Response Involving DNAME in 5.3.4.2. Valid Name Error Response Involving DNAME in
Bitmap . . . . . . . . . . . . . . . . . . . . . . 16 Bitmap . . . . . . . . . . . . . . . . . . . . . . 17
5.3.4.3. Response With Synthesized CNAME . . . . . . . . . 16 5.3.4.3. Response With Synthesized CNAME . . . . . . . . . 17
6. Examples of DNAME Use in a Zone . . . . . . . . . . . . . . . 16 6. Examples of DNAME Use in a Zone . . . . . . . . . . . . . . . 17
6.1. Organizational Renaming . . . . . . . . . . . . . . . . . 16 6.1. Organizational Renaming . . . . . . . . . . . . . . . . . 17
6.2. Classless Delegation of Shorter Prefixes . . . . . . . . . 17 6.2. Classless Delegation of Shorter Prefixes . . . . . . . . . 18
6.3. Network Renumbering Support . . . . . . . . . . . . . . . 17 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. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 10.1. Normative References . . . . . . . . . . . . . . . . . . . 20
10.2. Informative 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 1. Introduction
DNAME is a DNS Resource Record type originally defined in RFC 2672 DNAME is a DNS Resource Record type originally defined in RFC 2672
[RFC2672]. DNAME provides redirection from a part of the DNS name [RFC2672]. DNAME provides redirection from a part of the DNS name
tree to another part of the DNS name tree. tree to another part of the DNS name tree.
The DNAME RR and the CNAME RR [RFC1034] cause a lookup to The DNAME RR and the CNAME RR [RFC1034] cause a lookup to
(potentially) return data corresponding to a domain name different (potentially) return data corresponding to a domain name different
from the queried domain name. The difference between the two from the queried domain name. The difference between the two
skipping to change at page 5, line 6 skipping to change at page 6, line 6
added on problems that may be encountered when using DNAME. added on problems that may be encountered when using DNAME.
2. The DNAME Resource Record 2. The DNAME Resource Record
2.1. Format 2.1. Format
The DNAME RR has mnemonic DNAME and type code 39 (decimal). It is The DNAME RR has mnemonic DNAME and type code 39 (decimal). It is
not class-sensitive. not class-sensitive.
Its RDATA is comprised of a single field, <target>, which contains a Its RDATA is comprised of a single field, <target>, 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 <target> field MUST be present. The [RFC1035], [RFC3597]. The <target> field MUST be present. The
presentation format of <target> is that of a domain name [RFC1035]. presentation format of <target> is that of a domain name [RFC1035].
<owner> <ttl> <class> DNAME <target> <owner> <ttl> <class> DNAME <target>
The effect of the DNAME RR is the substitution of the record's 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 <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 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 the DNAME RR. This substitution has to be applied for every DNAME RR
found in the resolution process, which allows fairly lengthy valid found in the resolution process, which allows fairly lengthy valid
skipping to change at page 7, line 52 skipping to change at page 8, line 52
DNAME is a singleton type, meaning only one DNAME is allowed per 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 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 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 single domain name only one redirection exists, and thus no confusion
which one to follow. A server SHOULD refuse to load a zone that which one to follow. A server SHOULD refuse to load a zone that
violates these rules. violates these rules.
2.5. Compression of the DNAME record. 2.5. Compression of the DNAME record.
The DNAME owner name can be compressed like any other owner name. 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, 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]. and MUST be downcased for DNSSEC validation.
Although the previous DNAME specification [RFC2672] (that is Although the previous DNAME specification [RFC2672] (that is
obsoleted by this specification) talked about signaling to allow obsoleted by this specification) talked about signaling to allow
compression of the target name, such signaling has never been compression of the target name, such signaling has never been
specified and this document also does not specify this signaling specified and this document also does not specify this signaling
behavior. behavior.
RFC 2672 (obsoleted by this document) stated that the EDNS version RFC 2672 (obsoleted by this document) stated that the EDNS version
had a meaning for understanding of DNAME and DNAME target name had a meaning for understanding of DNAME and DNAME target name
compression. This document revises RFC 2672, in that there is no compression. This document revises RFC 2672, in that there is no
skipping to change at page 18, line 30 skipping to change at page 19, line 30
Renumbering IPv4 networks is currently so arduous a task that Renumbering IPv4 networks is currently so arduous a task that
updating the DNS is only a small part of the labor, so this scheme 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 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 task will be quite different and the DNAME mechanism may play a
useful part. useful part.
7. IANA Considerations 7. IANA Considerations
The DNAME Resource Record type code 39 (decimal) originally has been The DNAME Resource Record type code 39 (decimal) originally has been
registered by [RFC2672]. IANA should update the DNS resource record registered by [RFC2672] in the DNS Resource Record (RR) Types
registry to point to this document for RR type 39. 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 8. Security Considerations
DNAME redirects queries elsewhere, which may impact security based on DNAME redirects queries elsewhere, which may impact security based on
policy and the security status of the zone with the DNAME and the policy and the security status of the zone with the DNAME and the
redirection zone's security status. For validating resolvers, the redirection zone's security status. For validating resolvers, the
lowest security status of the links in the chain of CNAME and DNAME lowest security status of the links in the chain of CNAME and DNAME
redirections is applied to the result. redirections is applied to the result.
If a validating resolver accepts wildcarded DNAMEs, this creates If a validating resolver accepts wildcarded DNAMEs, this creates
skipping to change at page 20, line 31 skipping to change at page 21, line 31
RFC 2672, August 1999. RFC 2672, August 1999.
[RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
Hain, "Representing Internet Protocol version 6 (IPv6) Hain, "Representing Internet Protocol version 6 (IPv6)
Addresses in the Domain Name System (DNS)", RFC 3363, Addresses in the Domain Name System (DNS)", RFC 3363,
August 2002. August 2002.
[RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294,
April 2006. 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 Authors' Addresses
Scott Rose Scott Rose
NIST NIST
100 Bureau Dr. 100 Bureau Dr.
Gaithersburg, MD 20899 Gaithersburg, MD 20899
USA USA
Phone: +1-301-975-8439 Phone: +1-301-975-8439
Fax: +1-301-975-6238 Fax: +1-301-975-6238
 End of changes. 20 change blocks. 
48 lines changed or deleted 98 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/