draft-ietf-dnsext-rfc2672bis-dname-17.txt   draft-ietf-dnsext-rfc2672bis-dname-18.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 NLnet Labs Updates: 3363,4294 NLnet Labs
(if approved) September 24, 2009 (if approved) November 12, 2009
Intended status: Standards Track Intended status: Standards Track
Expires: March 28, 2010 Expires: May 16, 2010
Update to DNAME Redirection in the DNS Update to DNAME Redirection in the DNS
draft-ietf-dnsext-rfc2672bis-dname-17 draft-ietf-dnsext-rfc2672bis-dname-18
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 of the original specification in RFC 2672, also aligning
RFC 3363 and RFC 4294 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].
Status of This Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79.
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.
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
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."
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 March 28, 2010. This Internet-Draft will expire on May 16, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
The DNAME record provides redirection for a sub-tree of the domain described in the BSD License.
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 of the original specification in RFC 2672, also aligning
RFC 3363 and RFC 4294 with this revision.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", This document may contain material from IETF Documents or IETF
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this Contributions published or made publicly available before November
document are to be interpreted as described in RFC 2119 [RFC2119]. 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.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. The DNAME Resource Record . . . . . . . . . . . . . . . . . . 4 2. The DNAME Resource Record . . . . . . . . . . . . . . . . . . 4
2.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. The DNAME Substitution . . . . . . . . . . . . . . . . . . 5 2.2. The DNAME Substitution . . . . . . . . . . . . . . . . . . 5
2.3. DNAME Apex not Redirected itself . . . . . . . . . . . . . 6 2.3. DNAME Owner Name not Redirected Itself . . . . . . . . . . 6
2.4. Names Next to and Below a DNAME Record . . . . . . . . . . 7 2.4. Names Next to and Below a DNAME Record . . . . . . . . . . 7
2.5. Compression of the DNAME record. . . . . . . . . . . . . . 7 2.5. Compression of the DNAME record. . . . . . . . . . . . . . 7
3. Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. CNAME synthesis . . . . . . . . . . . . . . . . . . . . . 8 3.1. CNAME synthesis . . . . . . . . . . . . . . . . . . . . . 8
3.2. Server algorithm . . . . . . . . . . . . . . . . . . . . . 8 3.2. Server algorithm . . . . . . . . . . . . . . . . . . . . . 8
3.3. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . 10 3.3. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . 10
3.4. Acceptance and Intermediate Storage . . . . . . . . . . . 10 3.4. Acceptance and Intermediate Storage . . . . . . . . . . . 10
4. DNAME Discussions in Other Documents . . . . . . . . . . . . . 11 4. DNAME Discussions in Other Documents . . . . . . . . . . . . . 11
skipping to change at page 6, line 47 skipping to change at page 6, line 47
when using DNAME or DNAME/CNAME redirection. when using DNAME or DNAME/CNAME redirection.
The domain name can get too long during substitution. For example, The domain name can get too long during substitution. For example,
suppose the target name of the DNAME RR is 250 octets in length 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 (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 octets in length, the result would be a name over 255 octets. If
this occurs the server returns an RCODE of YXDOMAIN [RFC2136]. The this occurs the server returns an RCODE of YXDOMAIN [RFC2136]. The
DNAME record and its signature (if the zone is signed) are included DNAME record and its signature (if the zone is signed) are included
in the answer as proof for the YXDOMAIN (value 6) RCODE. in the answer as proof for the YXDOMAIN (value 6) RCODE.
2.3. DNAME Apex not Redirected itself 2.3. DNAME Owner Name not Redirected Itself
Unlike a CNAME RR, a DNAME RR redirects DNS names subordinate to its 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 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 domain name that owns a DNAME record is allowed to have other
resource record types at that domain name, except DNAMEs, CNAMEs or resource record types at that domain name, except DNAMEs, CNAMEs or
other types that have restrictions on what they can co-exist with. other types that have restrictions on what they can co-exist with.
DNAME RRs are not allowed at the parent side of a delegation point DNAME RRs MUST NOT appear at the same owner name as an NS RR unless
but are allowed at a zone apex. the owner name is the zone apex.
There still is a need to have the customary SOA and NS resource If a DNAME record is present at the zone apex, there is still a need
records at the zone apex. This means that DNAME does not mirror a to have the customary SOA and NS resource records there as well.
zone completely, as it does not mirror the zone apex. 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 RFC 1034 These rules also allow DNAME records to be queried through RFC 1034
[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-
 End of changes. 11 change blocks. 
39 lines changed or deleted 46 lines changed or added

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