--- 1/draft-ietf-dnsext-rfc2672bis-dname-16.txt 2009-09-24 21:12:07.000000000 +0200 +++ 2/draft-ietf-dnsext-rfc2672bis-dname-17.txt 2009-09-24 21:12:07.000000000 +0200 @@ -1,21 +1,21 @@ DNS Extensions Working Group S. Rose Internet-Draft NIST Obsoletes: 2672 (if approved) W. Wijngaards Updates: 3363,4294 NLnet Labs -(if approved) June 29, 2009 +(if approved) September 24, 2009 Intended status: Standards Track -Expires: December 31, 2009 +Expires: March 28, 2010 Update to DNAME Redirection in the DNS - draft-ietf-dnsext-rfc2672bis-dname-16 + draft-ietf-dnsext-rfc2672bis-dname-17 Status of This Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material 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 @@ -34,21 +34,21 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at 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 (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights @@ -173,21 +173,21 @@ resource records, and rules for specific corner cases are given in the following subsections. 2.2. The DNAME Substitution 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 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 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 will happen prior to finding the desired domain name. A DNAME substitution is performed by replacing the suffix labels of the name being sought matching the owner name of the DNAME resource 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 replaced. See the table of examples for common cases and corner cases. @@ -288,25 +288,24 @@ EDNS version signaling for DNAME. 3. Processing The DNAME RR causes type NS additional section processing. This refers to action at step 6 of the server algorithm outlined in section 3.2. 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 section. A CNAME RR with TTL equal to the corresponding DNAME RR is - synthesized and included in the answer section for resolvers that did - not indicate understanding of DNAME in queries. The owner name of + synthesized and included in the answer section. The owner name of the CNAME is the QNAME of the query. The DNSSEC specification [RFC4033], [RFC4034], [RFC4035] says that the synthesized CNAME does not have to be signed. The DNAME has an RRSIG and a validating resolver can check the CNAME against the DNAME record and validate the signature over the DNAME RR. 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 means that the CNAME can be discarded immediately after processing the answer. @@ -418,34 +417,33 @@ 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 load the zone or refuse dynamic updates. 3.4. Acceptance and Intermediate Storage 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 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 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, consistency returns after the older data TTL times out. Recursive caching name servers MUST perform CNAME synthesis on behalf of clients. If a recursive caching name server encounters a DNAME RR which contradicts information already in the cache (excluding CNAME records), it SHOULD NOT cache the DNAME RR, but it MAY cache the - CNAME record received along with it or synthesized from the DNAME - record, subject to the rules for CNAME caching. + CNAME record received along with it, subject to the rules for CNAME. 4. DNAME Discussions in Other Documents In [RFC2181], in Section 10.3., the discussion on MX and NS records touches on redirection by CNAMEs, but this also holds for DNAMEs. Excerpt from 10.3. MX and NS records (in RFC 2181). 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