--- 1/draft-ietf-dnsext-rfc2672bis-dname-08.txt 2008-02-08 00:12:09.000000000 +0100 +++ 2/draft-ietf-dnsext-rfc2672bis-dname-09.txt 2008-02-08 00:12:09.000000000 +0100 @@ -1,20 +1,20 @@ DNS Extensions Working Group S. Rose Internet-Draft NIST Updates: 2672,3363,4294 W. Wijngaards (if approved) NLnet Labs -Intended status: Standards Track January 14, 2008 -Expires: July 17, 2008 +Intended status: Standards Track February 5, 2008 +Expires: August 8, 2008 Update to DNAME Redirection in the DNS - draft-ietf-dnsext-rfc2672bis-dname-08 + draft-ietf-dnsext-rfc2672bis-dname-09 Status of This Memo By submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -25,21 +25,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 July 17, 2008. + This Internet-Draft will expire on August 8, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). 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 @@ -319,24 +319,24 @@ DNS caches 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 old data times out. The cache 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. - DNS Caches MUST perform CNAME synthesis on behalf of DNAME-ignorant - clients. A DNS Cache that understands DNAMEs can send out queries on + DNS caches MUST perform CNAME synthesis on behalf of DNAME-ignorant + clients. A DNS cache that understands DNAMEs can send out queries on behalf of clients with the UD bit set. After receiving the answers - the DNS Cache sends replies to DNAME ignorant clients that include + the DNS cache sends replies to DNAME ignorant clients that include DNAMEs and synthesized CNAMEs. 3.4. Server algorithm Below the server algorithm, which appeared in RFC 2672 Section 4.1, is expanded to handle the UD bit. 1. Set or clear the value of recursion available in the response depending on whether the name server is willing to provide recursive service. If recursive service is available and @@ -499,23 +499,25 @@ 5.2. Dynamic Update and DNAME Dynamic update for DNAME records works similar to dynamic update for delegating NS records. For example, adding a DNAME obscures names in the zone. DNAME records can be added, changed and removed. Zones containing a DNAME RR MUST NOT accept a dynamic update message that would add a record or delegation with a name existing under a DNAME. - A server MUST return an error message with RCODE=REFUSED [RFC2136] in - response to a dynamic update message that would add a resource record - under a DNAME in the zone. + A server MUST return an error message with RCODE=YXDOMAIN [RFC2136] + in response to a dynamic update message that would add a resource + record under a DNAME in the zone. This is similar to a dynamic + update request to add a resource record under a delegation NS in a + zone. 5.3. DNSSEC and DNAME 5.3.1. DNAME bit in NSEC type map When a validator checks the NSEC RRs returned on a name error response, it SHOULD check that the DNAME bit is not set. If the DNAME bit is set then the DNAME substitution should have been done, but has not. @@ -596,21 +598,23 @@ server meant, and consequently end up at the wrong destination. Use of wildcarded DNAMEs is discouraged in any case [RFC4592]. A validating resolver MUST understand DNAME, according to [RFC4034]. In Section 5.3.2 examples are given that illustrate this need. 8. Acknowledgments The authors of this draft would like to acknowledge Matt Larson for beginning this effort to address the issues related to the DNAME RR - type. + type. The authors would also like to acknowledge Paul Vixie, Ed + Lewis, Mark Andrews, Mike StJohns and Niall O'Reilly for their review + and comments on this document. 9. References 9.1. Normative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.