draft-ietf-dnsext-rfc2672bis-dname-08.txt   draft-ietf-dnsext-rfc2672bis-dname-09.txt 
DNS Extensions Working Group S. Rose DNS Extensions Working Group S. Rose
Internet-Draft NIST Internet-Draft NIST
Updates: 2672,3363,4294 W. Wijngaards Updates: 2672,3363,4294 W. Wijngaards
(if approved) NLnet Labs (if approved) NLnet Labs
Intended status: Standards Track January 14, 2008 Intended status: Standards Track February 5, 2008
Expires: July 17, 2008 Expires: August 8, 2008
Update to DNAME Redirection in the DNS Update to DNAME Redirection in the DNS
draft-ietf-dnsext-rfc2672bis-dname-08 draft-ietf-dnsext-rfc2672bis-dname-09
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 36 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 July 17, 2008. This Internet-Draft will expire on August 8, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
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
skipping to change at page 8, line 6 skipping to change at page 8, line 6
DNS caches can encounter data at names below the owner name of a 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 DNAME RR, due to a change at the authoritative server where data from
before and after the change resides in the cache. This conflict before and after the change resides in the cache. This conflict
situation is a transitional phase, that ends when the old data times 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 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 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 longer domain name. In any approach, consistency returns after the
older data TTL times out. older data TTL times out.
DNS Caches MUST perform CNAME synthesis on behalf of DNAME-ignorant DNS caches MUST perform CNAME synthesis on behalf of DNAME-ignorant
clients. A DNS Cache that understands DNAMEs can send out queries on clients. A DNS cache that understands DNAMEs can send out queries on
behalf of clients with the UD bit set. After receiving the answers 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. DNAMEs and synthesized CNAMEs.
3.4. Server algorithm 3.4. Server algorithm
Below the server algorithm, which appeared in RFC 2672 Section 4.1, Below the server algorithm, which appeared in RFC 2672 Section 4.1,
is expanded to handle the UD bit. is expanded to handle the UD bit.
1. Set or clear the value of recursion available in the response 1. Set or clear the value of recursion available in the response
depending on whether the name server is willing to provide depending on whether the name server is willing to provide
recursive service. If recursive service is available and recursive service. If recursive service is available and
skipping to change at page 11, line 47 skipping to change at page 11, line 47
5.2. Dynamic Update and DNAME 5.2. Dynamic Update and DNAME
Dynamic update for DNAME records works similar to dynamic update for Dynamic update for DNAME records works similar to dynamic update for
delegating NS records. For example, adding a DNAME obscures names in delegating NS records. For example, adding a DNAME obscures names in
the zone. DNAME records can be added, changed and removed. the zone. DNAME records can be added, changed and removed.
Zones containing a DNAME RR MUST NOT accept a dynamic update message 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 that would add a record or delegation with a name existing under a
DNAME. DNAME.
A server MUST return an error message with RCODE=REFUSED [RFC2136] in A server MUST return an error message with RCODE=YXDOMAIN [RFC2136]
response to a dynamic update message that would add a resource record in response to a dynamic update message that would add a resource
under a DNAME in the zone. 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. DNSSEC and DNAME
5.3.1. DNAME bit in NSEC type map 5.3.1. DNAME bit in NSEC type map
When a validator checks the NSEC RRs returned on a name error 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 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, DNAME bit is set then the DNAME substitution should have been done,
but has not. but has not.
skipping to change at page 14, line 4 skipping to change at page 14, line 4
server meant, and consequently end up at the wrong destination. Use server meant, and consequently end up at the wrong destination. Use
of wildcarded DNAMEs is discouraged in any case [RFC4592]. of wildcarded DNAMEs is discouraged in any case [RFC4592].
A validating resolver MUST understand DNAME, according to [RFC4034]. A validating resolver MUST understand DNAME, according to [RFC4034].
In Section 5.3.2 examples are given that illustrate this need. In Section 5.3.2 examples are given that illustrate this need.
8. Acknowledgments 8. Acknowledgments
The authors of this draft would like to acknowledge Matt Larson for The authors of this draft would like to acknowledge Matt Larson for
beginning this effort to address the issues related to the DNAME RR 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. References
9.1. Normative References 9.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
 End of changes. 7 change blocks. 
11 lines changed or deleted 15 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/