draft-ietf-dnsext-rfc2672bis-dname-06.txt   draft-ietf-dnsext-rfc2672bis-dname-07.txt 
DNS Extensions Working Group S. Rose DNS Extensions Working Group S. Rose
Internet-Draft NIST Internet-Draft NIST
Intended status: Standards Track W. Wijngaards Updates: 2672,3363,4294 W. Wijngaards
Expires: May 17, 2008 NLnet Labs (if approved) NLnet Labs
November 14, 2007 Intended status: Standards Track December 13, 2007
Expires: June 15, 2008
Update to DNAME Redirection in the DNS Update to DNAME Redirection in the DNS
draft-ietf-dnsext-rfc2672bis-dname-06 draft-ietf-dnsext-rfc2672bis-dname-07
Status of This Memo Status of This Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 36
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 17, 2008. This Internet-Draft will expire on June 15, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
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
an update to the original specification in RFC 2672. an update to the original specification in RFC 2672, also aligning
RFC 3363 and RFC 4294 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", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
skipping to change at page 3, line 33 skipping to change at page 3, line 33
This document is an update to the original specification of DNAME in This document is an update to 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 and punycode alternates for domain spaces. address space delegations and punycode alternates for domain spaces.
Another usage of DNAME lies in redirection of name spaces. For Another usage of DNAME lies in redirection of name spaces. For
example, a zone administrator may want sub-trees of the DNS to example, a zone administrator may want sub-trees of the DNS to
contain the same information. DNAME is also used for redirection of contain the same information. DNAME is also used for the redirection
ENUM domains to another maintaining party. of ENUM domains to another maintaining party.
This update to DNAME does not change the wire format or the handling This update to DNAME does not change the wire format or the handling
of DNAME Resource Records by existing software. A new UD (Understand of DNAME Resource Records by existing software. A new UD (Understand
Dname) bit in the EDNS flags field can be used to signal that CNAME Dname) bit in the EDNS flags field can be used to signal that CNAME
synthesis is not needed. Discussion is added on problems that may be synthesis is not needed. Discussion is added on problems that may be
encountered when using DNAME. encountered when using DNAME.
2. The DNAME Resource Record 2. The DNAME Resource Record
2.1. Format 2.1. Format
skipping to change at page 10, line 31 skipping to change at page 10, line 31
point, but using an alias in either of these positions point, but using an alias in either of these positions
neither works as well as might be hoped, nor well fulfills neither works as well as might be hoped, nor well fulfills
the ambition that may have led to this approach. This the ambition that may have led to this approach. This
domain name must have as its value one or more address domain name must have as its value one or more address
records. Currently those will be A records, however in records. Currently those will be A records, however in
the future other record types giving addressing the future other record types giving addressing
information may be acceptable. It can also have other information may be acceptable. It can also have other
RRs, but never a CNAME RR. RRs, but never a CNAME RR.
The DNAME RR is discussed in RFC 3363, section 4, on A6 and DNAME. The DNAME RR is discussed in RFC 3363, section 4, on A6 and DNAME.
[RFC3363] does NOT RECOMMENDED the use of DNAME in the IPv6 reverse The opening premise of this section is demonstrably wrong, and so the
tree. (Hence, all references to DNAME should have been removed from conclusion based on that premise is wrong. In particular, [RFC3363]
[RFC4294].) Based on the experience gained in the meantime, RFC 3363 deprecates the use of DNAME in the IPv6 reverse tree, which is then
should be revised, dropping all constraints on having DNAME RRs in carried forward as a recommendation in [RFC4294]. Based on the
these zones. This would greatly improve the manageability of the experience gained in the meantime, [RFC3363] should be revised,
IPv6 reverse tree. These changes are made explicit below. dropping all constraints on having DNAME RRs in these zones. This
would greatly improve the manageability of the IPv6 reverse tree.
In [RFC3363], section 4, DNAME is not recommended for the IPv6 These changes are made explicit below.
reverse tree. The opening premise of this section is demonstrably
wrong. Everything that follows from that premise is also invalid.
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 to be replaced with the word "DELETED".
In [RFC4294], the reference to DNAME was left in as a 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
A6 Resource Record [RFC3363]." A6 Resource Record [RFC3363]."
 End of changes. 7 change blocks. 
19 lines changed or deleted 19 lines changed or added

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