draft-ietf-dnsext-rfc2672bis-dname-16.txt   draft-ietf-dnsext-rfc2672bis-dname-17.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) June 29, 2009 (if approved) September 24, 2009
Intended status: Standards Track Intended status: Standards Track
Expires: December 31, 2009 Expires: March 28, 2010
Update to DNAME Redirection in the DNS Update to DNAME Redirection in the DNS
draft-ietf-dnsext-rfc2672bis-dname-16 draft-ietf-dnsext-rfc2672bis-dname-17
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. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 December 31, 2009. This Internet-Draft will expire on March 28, 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 5, line 29 skipping to change at page 5, line 29
resource records, and rules for specific corner cases are given in resource records, and rules for specific corner cases are given in
the following subsections. the following subsections.
2.2. The DNAME Substitution 2.2. The DNAME Substitution
When following RFC 1034 [RFC1034], section 4.3.2's algorithm's third When following RFC 1034 [RFC1034], section 4.3.2's algorithm's third
step, "start matching down, label by label, in the zone" and a node step, "start matching down, label by label, in the zone" and a node
is found to own a DNAME resource record a DNAME substitution occurs. is found to own a DNAME resource record a DNAME substitution occurs.
The name being sought may be the original query name or a name that The name being sought may be the original query name or a name that
is the result of a CNAME resource record being followed or a is the result of a CNAME resource record being followed or a
previously encountered DNAME. As is the case of finding a CNAME previously encountered DNAME. As in the case when finding a CNAME
resource record or NS resource record set, the processing of a DNAME resource record or NS resource record set, the processing of a DNAME
will happen prior to finding the desired domain name. will happen prior to finding the desired domain name.
A DNAME substitution is performed by replacing the suffix labels of A DNAME substitution is performed by replacing the suffix labels of
the name being sought matching the owner name of the DNAME resource the name being sought matching the owner name of the DNAME resource
record with the string of labels in the RDATA field. The matching record with the string of labels in the RDATA field. The matching
labels end with the root label in all cases. Only whole labels are labels end with the root label in all cases. Only whole labels are
replaced. See the table of examples for common cases and corner replaced. See the table of examples for common cases and corner
cases. cases.
skipping to change at page 8, line 13 skipping to change at page 8, line 13
EDNS version signaling for DNAME. EDNS version signaling for DNAME.
3. Processing 3. Processing
The DNAME RR causes type NS additional section processing. This The DNAME RR causes type NS additional section processing. This
refers to action at step 6 of the server algorithm outlined in refers to action at step 6 of the server algorithm outlined in
section 3.2. section 3.2.
3.1. CNAME synthesis 3.1. CNAME synthesis
When preparing an response, a server performing a DNAME substitution When preparing a response, a server performing a DNAME substitution
will in all cases include the relevant DNAME RR in the answer will in all cases include the relevant DNAME RR in the answer
section. A CNAME RR with TTL equal to the corresponding DNAME RR is section. A CNAME RR with TTL equal to the corresponding DNAME RR is
synthesized and included in the answer section for resolvers that did synthesized and included in the answer section. The owner name of
not indicate understanding of DNAME in queries. The owner name of
the CNAME is the QNAME of the query. The DNSSEC specification the CNAME is the QNAME of the query. The DNSSEC specification
[RFC4033], [RFC4034], [RFC4035] says that the synthesized CNAME does [RFC4033], [RFC4034], [RFC4035] says that the synthesized CNAME does
not have to be signed. The DNAME has an RRSIG and a validating not have to be signed. The DNAME has an RRSIG and a validating
resolver can check the CNAME against the DNAME record and validate resolver can check the CNAME against the DNAME record and validate
the signature over the DNAME RR. the signature over the DNAME RR.
Resolvers MUST be able to handle a synthesized CNAME TTL of zero or Resolvers MUST be able to handle a synthesized CNAME TTL of zero or
equal to the TTL of the corresponding DNAME record. A TTL of zero equal to the TTL of the corresponding DNAME record. A TTL of zero
means that the CNAME can be discarded immediately after processing means that the CNAME can be discarded immediately after processing
the answer. the answer.
skipping to change at page 11, line 5 skipping to change at page 11, line 5
A server MAY give a warning that the behavior is unspecified if such A server MAY give a warning that the behavior is unspecified if such
a wildcarded DNAME is loaded. The server MAY refuse it, refuse to a wildcarded DNAME is loaded. The server MAY refuse it, refuse to
load the zone or refuse dynamic updates. load the zone or refuse dynamic updates.
3.4. Acceptance and Intermediate Storage 3.4. Acceptance and Intermediate Storage
Recursive caching name servers can encounter data at names below the Recursive caching name servers can encounter data at names below the
owner name of a DNAME RR, due to a change at the authoritative server owner name of a DNAME RR, due to a change at the authoritative server
where data from before and after the change resides in the cache. where data from before and after the change resides in the cache.
This conflict situation is a transitional phase, that ends when the This conflict situation is a transitional phase that ends when the
old data times out. The caching name server can opt to store both old data times out. The caching name server can opt to store both
old and new data and treat each as if the other did not exist, or old and new data and treat each as if the other did not exist, or
drop the old data, or drop the longer domain name. In any approach, drop the old data, or drop the longer domain name. In any approach,
consistency returns after the older data TTL times out. consistency returns after the older data TTL times out.
Recursive caching name servers MUST perform CNAME synthesis on behalf Recursive caching name servers MUST perform CNAME synthesis on behalf
of clients. of clients.
If a recursive caching name server encounters a DNAME RR which If a recursive caching name server encounters a DNAME RR which
contradicts information already in the cache (excluding CNAME contradicts information already in the cache (excluding CNAME
records), it SHOULD NOT cache the DNAME RR, but it MAY cache the records), it SHOULD NOT cache the DNAME RR, but it MAY cache the
CNAME record received along with it or synthesized from the DNAME CNAME record received along with it, subject to the rules for CNAME.
record, subject to the rules for CNAME caching.
4. DNAME Discussions in Other Documents 4. DNAME Discussions in Other Documents
In [RFC2181], in Section 10.3., the discussion on MX and NS records In [RFC2181], in Section 10.3., the discussion on MX and NS records
touches on redirection by CNAMEs, but this also holds for DNAMEs. touches on redirection by CNAMEs, but this also holds for DNAMEs.
Excerpt from 10.3. MX and NS records (in RFC 2181). Excerpt from 10.3. MX and NS records (in RFC 2181).
The domain name used as the value of a NS resource record, The domain name used as the value of a NS resource record,
or part of the value of a MX resource record must not be or part of the value of a MX resource record must not be
 End of changes. 9 change blocks. 
11 lines changed or deleted 9 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/