draft-ietf-dnsext-rfc2672bis-dname-25.txt   draft-ietf-dnsext-rfc2672bis-dname-26.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 November 14, 2011 Intended status: Standards Track April 19, 2012
Expires: May 17, 2012 Expires: October 21, 2012
DNAME Redirection in the DNS DNAME Redirection in the DNS
draft-ietf-dnsext-rfc2672bis-dname-25 draft-ietf-dnsext-rfc2672bis-dname-26
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 (which this a revision to the original specification in RFC 2672 (which this
document obsoletes) as well as updating RFC 3363 and RFC 4294 to document obsoletes) as well as updating RFC 3363 and RFC 4294 to
align with this revision. align with this revision.
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 May 17, 2012. This Internet-Draft will expire on October 21, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 5, line 37 skipping to change at page 5, line 37
This document is a revision of the original specification of DNAME in This document is a revision of the original specification of DNAME in
RFC 2672 [RFC2672]. DNAME was conceived to help with the problem of RFC 2672 [RFC2672]. DNAME was conceived to help with the problem of
maintaining address-to-name mappings in a context of network maintaining address-to-name mappings in a context of network
renumbering. With a careful set-up, a renumbering event in the renumbering. With a careful set-up, a renumbering event in the
network causes no change to the authoritative server that has the network causes no change to the authoritative server that has the
address-to-name mappings. Examples in practice are classless reverse address-to-name mappings. Examples in practice are classless reverse
address space delegations. address space delegations.
Another usage of DNAME lies in aliasing of name spaces. For example, Another usage of DNAME lies in aliasing of name spaces. For example,
a zone administrator may want sub-trees of the DNS to contain the a zone administrator may want sub-trees of the DNS to contain the
same information. Examples include punycode alternates for domain same information. Examples include punycode [RFC3492] alternates for
spaces. domain spaces.
This revision of the DNAME specification does not change the wire This revision of the DNAME specification does not change the wire
format or the handling of DNAME Resource Records. Discussion is format or the handling of DNAME Resource Records. Discussion is
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. CLASS-insensitive.
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
skipping to change at page 8, line 37 skipping to change at page 8, line 37
[RFC1034] compliant, DNAME-unaware caches. [RFC1034] compliant, DNAME-unaware caches.
2.4. Names Next to and Below a DNAME Record 2.4. Names Next to and Below a DNAME Record
Resource records MUST NOT exist at any sub-domain of the owner of a Resource records MUST NOT exist at any sub-domain of the owner of a
DNAME RR. To get the contents for names subordinate to that owner DNAME RR. To get the contents for names subordinate to that owner
name, the DNAME redirection must be invoked and the resulting target 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 sub- queried. A server MAY refuse to load a zone that has data at a sub-
domain of a domain name owning a DNAME RR. If the server does load domain 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 the zone, those names below the DNAME RR will be occluded as
described in RFC 2136 [RFC2136], section 7.18. Also a server SHOULD described in RFC 2136 [RFC2136], section 7.18. Also a server ought
refuse to load a zone subordinate to the owner of a DNAME record in to refuse to load a zone subordinate to the owner of a DNAME record
the ancestor zone. See Section 5.2 for further discussion related to in the ancestor zone. See Section 5.2 for further discussion related
dynamic update. to dynamic update.
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 ought to 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
and MUST be downcased for DNSSEC validation. 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
skipping to change at page 14, line 38 skipping to change at page 14, line 38
In [RFC3363], the paragraph In [RFC3363], the paragraph
"The issues for DNAME in the reverse mapping tree appears to be "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 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 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, 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 the intent of this document is that use of DNAME RRs in the reverse
tree be deprecated." tree be deprecated."
is to be replaced with the word "DELETED". is updated by this document and the use of DNAME RRs in the reverse
tree is no longer deprecated.
In [RFC4294], the reference to DNAME was left in as an editorial In [RFC4294], the reference to DNAME was left in as an editorial
oversight. The paragraph oversight. The paragraph
"Those nodes are NOT RECOMMENDED to support the experimental A6 and "Those nodes are NOT RECOMMENDED to support the experimental A6 and
DNAME Resource Records [RFC3363]." DNAME Resource Records [RFC3363]."
is to be replaced by is to be replaced by
"Those nodes are NOT RECOMMENDED to support the experimental "Those nodes are NOT RECOMMENDED to support the experimental
skipping to change at page 15, line 21 skipping to change at page 15, line 21
The names listed as target names of MX, NS, PTR and SRV [RFC2782] The names listed as target names of MX, NS, PTR and SRV [RFC2782]
records must be canonical hostnames. This means no CNAME or DNAME records must be canonical hostnames. This means no CNAME or DNAME
redirection may be present during DNS lookup of the address records redirection may be present during DNS lookup of the address records
for the host. This is discussed in RFC 2181 [RFC2181], section 10.3, 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] and RFC 1912 [RFC1912], section 2.4. For SRV see RFC 2782 [RFC2782]
page 4. page 4.
The upshot of this is that although the lookup of a PTR record can The upshot of this is that although the lookup of a PTR record can
involve DNAMEs, the name listed in the PTR record can not fall under involve DNAMEs, the name listed in the PTR record can not fall under
a DNAME. The same holds for NS, SRV and MX records. For example, a DNAME. The same holds for NS, SRV and MX records. For example,
when punycode alternates for a zone use DNAME then the NS, MX, SRV when punycode [RFC3492] alternates for a zone use DNAME then the NS,
and PTR records that point to that zone must use names without MX, SRV and PTR records that point to that zone must use names that
punycode in their RDATA. What must be done then is to have the are not aliases in their RDATA. What must be done then is to have
domain names with DNAME substitution already applied to it as the MX, the domain names with DNAME substitution already applied to it as the
NS, PTR, SRV data. These are valid canonical hostnames. MX, NS, PTR, SRV data. These are valid canonical hostnames.
5.2. Dynamic Update and DNAME 5.2. Dynamic Update and DNAME
DNAME records can be added, changed and removed in a zone using DNAME records can be added, changed and removed in a zone using
dynamic update transactions. Adding a DNAME RR to a zone occludes dynamic update transactions. Adding a DNAME RR to a zone occludes
any domain names that may exist under the added DNAME. any domain names that may exist under the added DNAME.
If a dynamic update message attempts to add a DNAME with a given 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 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 MUST ignore the DNAME. If a DNAME is already associated with that
skipping to change at page 19, line 18 skipping to change at page 19, line 18
$ORIGIN in-addr.example.net. $ORIGIN in-addr.example.net.
188 DNAME in-addr.customer.example.com. 188 DNAME in-addr.customer.example.com.
$ORIGIN in-addr.customer.example. $ORIGIN in-addr.customer.example.
1 PTR www.customer.example.com 1 PTR www.customer.example.com
2 PTR mailhub.customer.example.com. 2 PTR mailhub.customer.example.com.
; etc ... ; etc ...
This would allow the address space 190.189.0.0/16 assigned to the ISP This would allow the address space 190.189.0.0/16 assigned to the ISP
"example.net" to be changed without the necessity of altering the "example.net" to be changed without the necessity of altering the
zone files describing the use of that space by the ISP and its zone data describing the use of that space by the ISP and its
customers. customers.
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
skipping to change at page 21, line 28 skipping to change at page 21, line 28
Errors", RFC 1912, February 1996. Errors", RFC 1912, February 1996.
[RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection",
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.
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode
for Internationalized Domain Names in Applications
(IDNA)", RFC 3492, March 2003.
[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 Appendix A. Changes from RFC 2672
A.1. Changes to Server Behavior A.1. Changes to Server Behavior
Major changes to server behavior from the original DNAME Major changes to server behavior from the original DNAME
specification are summarized below: specification are summarized below:
 End of changes. 12 change blocks. 
20 lines changed or deleted 25 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/