draft-ietf-dnsext-rfc2672bis-dname-10.txt   draft-ietf-dnsext-rfc2672bis-dname-11.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 February 21, 2008 Intended status: Standards Track March 25, 2008
Expires: August 24, 2008 Expires: September 26, 2008
Update to DNAME Redirection in the DNS Update to DNAME Redirection in the DNS
draft-ietf-dnsext-rfc2672bis-dname-10 draft-ietf-dnsext-rfc2672bis-dname-11
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 August 24, 2008. This Internet-Draft will expire on September 26, 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 5, line 49 skipping to change at page 5, line 49
delegation point but are allowed at a zone apex. delegation point but are allowed at a zone apex.
2.4. Names Next to and Below a DNAME Record 2.4. Names Next to and Below a DNAME Record
Other resource records MUST NOT exist at a domain name subordinate to Other resource records MUST NOT exist at a domain name subordinate to
the owner of a DNAME RR. To get the contents for names subordinate the owner of a DNAME RR. To get the contents for names subordinate
to that owner, the DNAME redirection must be invoked and the to that owner, the DNAME redirection must be invoked and the
resulting target queried. A server MAY refuse to load a zone that resulting target queried. A server MAY refuse to load a zone that
has data at a domain name subordinate to a domain name owning a DNAME has data at a domain name subordinate to a domain name owning a DNAME
RR. If the server does load the zone, those names below the DNAME RR RR. If the server does load the zone, those names below the DNAME RR
should be occluded. Also a server SHOULD refuse to load a zone will be occluded. Also a server SHOULD refuse to load a zone
subordinate to the owner of a DNAME record in the ancestor zone. See subordinate to the owner of a DNAME record in the ancestor zone. See
Section 5.2 for further discussion related to dynamic update. Section 5.2 for further discussion related to dynamic update.
DNAME is a singleton type, meaning only one DNAME is allowed per DNAME is a singleton type, meaning only one DNAME is allowed per
name. The owner name of a DNAME can only have one DNAME RR, and no name. The owner name of a DNAME can only have one DNAME RR, and no
CNAME RRs can exist at that name. These rules make sure that for a CNAME RRs can exist at that name. These rules make sure that for a
single domain name only one redirection exists, and thus no confusion single domain name only one redirection exists, and thus no confusion
which one to follow. A server SHOULD refuse to load a zone that which one to follow. A server SHOULD refuse to load a zone that
violates these rules. violates these rules.
skipping to change at page 11, line 44 skipping to change at page 11, line 44
DNAME substitution already applied to it as the MX, NS, PTR data. DNAME substitution already applied to it as the MX, NS, PTR data.
These are valid canonical hostnames. These are valid canonical hostnames.
5.2. Dynamic Update and DNAME 5.2. Dynamic Update and DNAME
DNAME records can be added, changed and removed in a zone using DNAME records can be added, changed and removed in a zone using
dynamic update transactions. Adding a DNAME RR to a zone occludes dynamic update transactions. Adding a DNAME RR to a zone occludes
any domain names that may exist under the added DNAME. any domain names that may exist under the added DNAME.
A server MUST ignore a dynamic update message that attempts to add a A server MUST ignore a dynamic update message that attempts to add a
DNAME RR at a name that already has one or more RRs associated with DNAME RR at a name that already has a CNAME RR or another DNAME RR
that name. associated with that name.
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 5 skipping to change at page 14, line 5
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. The authors would also like to acknowledge Paul Vixie, Ed type. The authors would also like to acknowledge Paul Vixie, Ed
Lewis, Mark Andrews, Mike StJohns and Niall O'Reilly for their review Lewis, Mark Andrews, Mike StJohns, Niall O'Reilly and Sam Weiler for
and comments on this document. 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. 6 change blocks. 
9 lines changed or deleted 9 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/