draft-ietf-dnsext-rfc2672bis-dname-14.txt   draft-ietf-dnsext-rfc2672bis-dname-15.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) July 15, 2008 (if approved) March 6, 2009
Intended status: Standards Track Intended status: Standards Track
Expires: January 16, 2009 Expires: September 7, 2009
Update to DNAME Redirection in the DNS Update to DNAME Redirection in the DNS
draft-ietf-dnsext-rfc2672bis-dname-14 draft-ietf-dnsext-rfc2672bis-dname-15
Status of This Memo Status of This Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79. This document may contain material
have been or will be disclosed, and any of which he or she becomes from IETF Documents or IETF Contributions published or made publicly
aware will be disclosed, in accordance with Section 6 of BCP 79. 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
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 January 16, 2009. This Internet-Draft will expire on September 7, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). 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
and restrictions with respect to this document.
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
a revision of the original specification in RFC 2672, also aligning a revision of the original specification in RFC 2672, also aligning
RFC 3363 and RFC 4294 with this revision. RFC 3363 and RFC 4294 with this revision.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. The DNAME Resource Record . . . . . . . . . . . . . . . . . . 3 2. The DNAME Resource Record . . . . . . . . . . . . . . . . . . 4
2.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. The DNAME Substitution . . . . . . . . . . . . . . . . . . 4 2.2. The DNAME Substitution . . . . . . . . . . . . . . . . . . 5
2.3. DNAME Apex not Redirected itself . . . . . . . . . . . . . 5 2.3. DNAME Apex not Redirected itself . . . . . . . . . . . . . 6
2.4. Names Next to and Below a DNAME Record . . . . . . . . . . 6 2.4. Names Next to and Below a DNAME Record . . . . . . . . . . 7
2.5. Compression of the DNAME record. . . . . . . . . . . . . . 6 2.5. Compression of the DNAME record. . . . . . . . . . . . . . 7
3. Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. CNAME synthesis and UD bit . . . . . . . . . . . . . . . . 7 3.1. CNAME synthesis and UD bit . . . . . . . . . . . . . . . . 8
3.2. Server algorithm . . . . . . . . . . . . . . . . . . . . . 8 3.2. Server algorithm . . . . . . . . . . . . . . . . . . . . . 9
3.3. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . 11
3.4. Acceptance and Intermediate Storage . . . . . . . . . . . 10 3.4. Acceptance and Intermediate Storage . . . . . . . . . . . 11
4. DNAME Discussions in Other Documents . . . . . . . . . . . . . 10 4. DNAME Discussions in Other Documents . . . . . . . . . . . . . 12
5. Other Issues with DNAME . . . . . . . . . . . . . . . . . . . 12 5. Other Issues with DNAME . . . . . . . . . . . . . . . . . . . 13
5.1. Canonical hostnames cannot be below DNAME owners . . . . . 12 5.1. Canonical hostnames cannot be below DNAME owners . . . . . 13
5.2. Dynamic Update and DNAME . . . . . . . . . . . . . . . . . 12 5.2. Dynamic Update and DNAME . . . . . . . . . . . . . . . . . 13
5.3. DNSSEC and DNAME . . . . . . . . . . . . . . . . . . . . . 12 5.3. DNSSEC and DNAME . . . . . . . . . . . . . . . . . . . . . 13
5.3.1. DNAME bit in NSEC type map . . . . . . . . . . . . . . 12 5.3.1. Signed DNAME, Unsigned Synthesized CNAME . . . . . . . 14
5.3.2. Validators Must Understand DNAME . . . . . . . . . . . 12 5.3.2. DNAME Bit in NSEC Type Map . . . . . . . . . . . . . . 14
5.3.2.1. DNAME in Bitmap Causes Invalid Name Error . . . . 13 5.3.3. DNAME Chains as Strong as the Weakest Link . . . . . . 14
5.3.2.2. Valid Name Error Response Involving DNAME in 5.3.4. Validators Must Understand DNAME . . . . . . . . . . . 14
Bitmap . . . . . . . . . . . . . . . . . . . . . . 13 5.3.4.1. DNAME in Bitmap Causes Invalid Name Error . . . . 14
5.3.2.3. Response With Synthesized CNAME . . . . . . . . . 13 5.3.4.2. Valid Name Error Response Involving DNAME in
Bitmap . . . . . . . . . . . . . . . . . . . . . . 15
5.3.4.3. Response With Synthesized CNAME . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
DNAME is a DNS Resource Record type originally defined in RFC 2672 DNAME is a DNS Resource Record type originally defined in RFC 2672
[RFC2672]. DNAME provides redirection from a part of the DNS name [RFC2672]. DNAME provides redirection from a part of the DNS name
tree to another part of the DNS name tree. tree to another part of the DNS name tree.
The DNAME RR and the CNAME RR [RFC1034] cause a lookup to The DNAME RR and the CNAME RR [RFC1034] cause a lookup to
(potentially) return data corresponding to a domain name different (potentially) return data corresponding to a domain name different
from the queried domain name. The difference between the two from the queried domain name. The difference between the two
skipping to change at page 5, line 42 skipping to change at page 6, line 42
loops. DNAMEs and CNAMEs can chain together to form loops. A single loops. DNAMEs and CNAMEs can chain together to form loops. A single
corner case DNAME can form a loop. Resolvers and servers should be corner case DNAME can form a loop. Resolvers and servers should be
cautious in devoting resources to a query, but be aware that fairly cautious in devoting resources to a query, but be aware that fairly
long chains of DNAMEs may be valid. Zone content administrators long chains of DNAMEs may be valid. Zone content administrators
should take care to insure that there are no loops that could occur should take care to insure that there are no loops that could occur
when using DNAME or DNAME/CNAME redirection. when using DNAME or DNAME/CNAME redirection.
The domain name can get too long during substitution. For example, The domain name can get too long during substitution. For example,
suppose the target name of the DNAME RR is 250 octets in length suppose the target name of the DNAME RR is 250 octets in length
(multiple labels), if an incoming QNAME that has a first label over 5 (multiple labels), if an incoming QNAME that has a first label over 5
octets in length, the result of the result would be a name over 255 octets in length, the result would be a name over 255 octets. If
octets. If this occurs the server returns an RCODE of YXDOMAIN this occurs the server returns an RCODE of YXDOMAIN [RFC2136]. The
[RFC2136]. The DNAME record and its signature (if the zone is DNAME record and its signature (if the zone is signed) are included
signed) are included in the answer as proof for the YXDOMAIN (value in the answer as proof for the YXDOMAIN (value 6) RCODE.
6) RCODE.
2.3. DNAME Apex not Redirected itself 2.3. DNAME Apex not Redirected itself
Unlike a CNAME RR, a DNAME RR redirects DNS names subordinate to its Unlike a CNAME RR, a DNAME RR redirects DNS names subordinate to its
owner name; the owner name of a DNAME is not redirected itself. The owner name; the owner name of a DNAME is not redirected itself. The
domain name that owns a DNAME record is allowed to have other domain name that owns a DNAME record is allowed to have other
resource record types at that domain name, except DNAMEs or CNAMEs. resource record types at that domain name, except DNAMEs, CNAMEs or
This means that DNAME RRs are not allowed at the parent side of a other types that have restrictions on what they can co-exist with.
delegation point but are allowed at a zone apex. DNAME RRs are not allowed at the parent side of a delegation point
but are allowed at a zone apex.
The reason for this decision was that one can have a DNAME at the There still is a need to have the customary SOA and NS resource
zone apex. There still is a need to have the customary SOA and NS records at the zone apex. This means that DNAME does not mirror a
resource records at the zone apex. This means that DNAME does not zone completely, as it does not mirror the zone apex.
mirror a zone completely, as it does not mirror the zone apex.
These rules also allow DNAME records to be queried through RFC 1034 These rules also allow DNAME records to be queried through RFC 1034
[RFC1034] compliant, DNAME-unaware caches. [RFC1034] compliant, DNAME-unaware caches.
2.4. Names Next to and Below a DNAME Record 2.4. Names Next to and Below a DNAME Record
Resource records MUST NOT exist at any domain name subordinate to the Resource records MUST NOT exist at any sub-domain of the owner of a
owner of a DNAME RR. To get the contents for names subordinate to DNAME RR. To get the contents for names subordinate to that owner
that owner, the DNAME redirection must be invoked and the resulting name, the DNAME redirection must be invoked and the resulting target
target queried. A server MAY refuse to load a zone that has data at queried. A server MAY refuse to load a zone that has data at a sub-
a domain name subordinate to a domain name owning a DNAME RR. If the domain of a domain name owning a DNAME RR. If the server does load
server does load the zone, those names below the DNAME RR will be the zone, those names below the DNAME RR will be occluded as
occluded, RFC 2136 [RFC2136], section 7.18. Also a server SHOULD described in RFC 2136 [RFC2136], section 7.18. Also a server SHOULD
refuse to load a zone subordinate to the owner of a DNAME record in refuse to load a zone subordinate to the owner of a DNAME record in
the ancestor zone. See Section 5.2 for further discussion related to the ancestor zone. See Section 5.2 for further discussion related to
dynamic update. 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 7, line 9 skipping to change at page 8, line 8
RFC 2672 (obsoleted by this document) stated that the EDNS version RFC 2672 (obsoleted by this document) stated that the EDNS version
had a meaning for understanding of DNAME and DNAME target name had a meaning for understanding of DNAME and DNAME target name
compression. This document revises RFC 2672, in that there is no compression. This document revises RFC 2672, in that there is no
EDNS version signaling for DNAME. However, the flags section of EDNS version signaling for DNAME. However, the flags section of
EDNS(0) is updated with a Understand-DNAME flag by this document (See EDNS(0) is updated with a Understand-DNAME flag by this document (See
Section 3.3). Section 3.3).
3. Processing 3. Processing
The DNAME RR causes type NS additional section 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 and UD bit 3.1. CNAME synthesis and UD bit
When preparing an response, a server upon performing a DNAME When preparing an response, a server performing a DNAME substitution
substitution will in all cases include the DNAME RR used in the will in all cases include the relevant DNAME RR in the answer
answer section. A CNAME RR record with TTL equal to the section. A CNAME RR with TTL equal to the corresponding DNAME RR is
corresponding DNAME RR is synthesized and included in the answer synthesized and included in the answer section for resolvers that did
section for old resolvers. The owner name of the CNAME is the QNAME not indicate understanding of DNAME in queries. The owner name of
of the query. DNSSEC [RFC4033], [RFC4034], [RFC4035] says that the the CNAME is the QNAME of the query. The DNSSEC specification
synthesized CNAME does not have to be signed. The DNAME has an RRSIG [RFC4033], [RFC4034], [RFC4035] says that the synthesized CNAME does
and a validating resolver can check the CNAME against the DNAME not have to be signed. The DNAME has an RRSIG and a validating
record and validate the DNAME record. 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 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. DNAME aware resolvers can set the Understand-DNAME (UD the answer. DNAME aware resolvers can set the Understand-DNAME (UD
bit) to receive a response with only the DNAME RR and no synthesized bit) to indicate that they can handle a response with only a DNAME RR
CNAMEs. and no synthesized CNAMEs.
The UD bit is part of the EDNS [RFC2671] extended RCODE and Flags The UD bit is part of the EDNS [RFC2671] extended RCODE and Flags
field. It is used to omit server processing, transmission and field. It is used to omit server processing, transmission and
resolver processing of unsigned synthesized CNAMEs. Resolvers can resolver processing of unsigned synthesized CNAMEs. Resolvers can
set this in a query to request omission of the synthesized CNAMEs. set this in a query to request omission of the synthesized CNAMEs.
Servers copy the UD bit to the response, and can omit synthesized Servers copy the UD bit to the response, and can omit synthesized
CNAMEs from the answer. Older resolvers do not set the UD bit, and CNAMEs from the answer. Resolvers that do not implement this
older servers do not copy the UD bit to the answer, and will not omit specification, do not set the UD bit, and servers that do not
synthesized CNAMEs. implement this specification do not copy the UD bit to the answer,
and will not omit synthesized CNAMEs.
Updated EDNS extended RCODE and Flags field. Updated EDNS extended RCODE and Flags field.
+0 (MSB) +1 (LSB) +0 (MSB) +1 (LSB)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0: | EXTENDED-RCODE | VERSION | 0: | EXTENDED-RCODE | VERSION |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2: |DO|UD| Z | 2: |DO|UD| Z |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Servers MUST be able to answer a query for a synthesized CNAME. Like Servers MUST be able to answer a query for a synthesized CNAME. Like
other query types this invokes the DNAME, and synthesizes the CNAME other query types this invokes the DNAME, and synthesizes the CNAME
into the answer. into the answer.
3.2. Server algorithm 3.2. Server algorithm
Below the server algorithm, which appeared in RFC 2672 Section 4.1, Below is the server algorithm, which appeared in RFC 2672 Section
is expanded to handle the UD (Understand-DNAME) bit. 4.1, it is expanded to handle the UD (Understand-DNAME) 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
requested via the RD bit in the query, go to step 5, otherwise requested via the RD bit in the query, go to step 5, otherwise
step 2. step 2.
2. Search the available zones for the zone which is the nearest 2. Search the available zones for the zone which is the nearest
ancestor to QNAME. If such a zone is found, go to step 3, ancestor to QNAME. If such a zone is found, go to step 3,
otherwise step 4. otherwise step 4.
skipping to change at page 10, line 13 skipping to change at page 11, line 31
[RFC4592]. Thus records of the form "*.example.com DNAME [RFC4592]. Thus records of the form "*.example.com DNAME
example.net" SHOULD NOT be used. example.net" SHOULD NOT be used.
The interaction between the expansion of the wildcard and the The interaction between the expansion of the wildcard and the
redirection of the DNAME is non-deterministic. Because the redirection of the DNAME is non-deterministic. Because the
processing is non-deterministic, DNSSEC validating resolvers may not processing is non-deterministic, DNSSEC validating resolvers may not
be able to validate a wildcarded DNAME. be able to validate a wildcarded DNAME.
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 or refuse dynamic update. 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 DNAME-ignorant clients. A recursive caching name server that of DNAME-ignorant clients. A recursive caching name server that
understands DNAMEs can send out queries on behalf of clients with the understands DNAMEs can send out queries on behalf of clients with the
UD bit set (See Section 3.1). After receiving the answers the UD bit set (See Section 3.1). After receiving the answers the
recursive caching name server sends replies to DNAME ignorant clients recursive caching name server sends replies to DNAME ignorant clients
that include DNAMEs and synthesized CNAMEs. that include DNAMEs and synthesized CNAMEs.
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.
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
an alias. Not only is the specification clear on this an alias. Not only is the specification clear on this
skipping to change at page 12, line 39 skipping to change at page 13, line 50
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 reject a dynamic update message that attempts to add a A server MUST reject a dynamic update message that attempts to add a
DNAME RR at a name that already has a CNAME RR or another DNAME RR DNAME RR at a name that already has a CNAME RR or another DNAME RR
associated with 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 The following is for implementations that understand both DNSSEC and
DNAME (synthesis).
When a validator checks the NSEC RRs returned on a name error 5.3.1. Signed DNAME, Unsigned Synthesized CNAME
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.
5.3.2. Validators Must Understand DNAME In any response, a signed DNAME RR indicates a non-terminal
redirection of the query. There might or might not be a server
synthesized CNAME in the answer section, if there is, the CNAME will
never be signed. For a DNSSEC validator, verification of the DNAME
RR and then checking that the CNAME was properly synthesized is
sufficient proof.
5.3.2. DNAME Bit in NSEC Type Map
In any negative response, the NSEC or NSEC3 [RFC5155] record type bit
map SHOULD be checked to see that there was no DNAME that could have
been applied. If the DNAME bit in the type bit map is set and the
query name is a subdomain of the closest encloser that is asserted,
then DNAME substitution should have been done, but the substitution
has not been done as specified.
5.3.3. DNAME Chains as Strong as the Weakest Link
A response can contain a chain of DNAME and CNAME redirections. That
chain can end in a positive answer or a negative (no name error or no
data error) reply. Each step in that chain results in resource
records added to the answer or authority section of the response.
Only if all steps are secure can the AD bit be set for the response.
If one of the steps is bogus, the result is bogus.
5.3.4. Validators Must Understand DNAME
Below are examples of why DNSSEC validators MUST understand DNAME. Below are examples of why DNSSEC validators MUST understand DNAME.
In the examples below, SOA records, wildcard denial NSECs and other
material not under discussion has been omitted.
5.3.2.1. DNAME in Bitmap Causes Invalid Name Error 5.3.4.1. DNAME in Bitmap Causes Invalid Name Error
;; Header: QR AA DO RCODE=3(NXDOMAIN) ;; Header: QR AA DO RCODE=3(NXDOMAIN)
;; Question ;; Question
foo.bar.example.com. IN A foo.bar.example.com. IN A
;; Answer ;; Authority
bar.example.com. NSEC dub.example.com. A DNAME bar.example.com. NSEC dub.example.com. A DNAME
bar.example.com. RRSIG NSEC [valid signature] bar.example.com. RRSIG NSEC [valid signature]
If this is the response, then only by understanding that the DNAME If this is the received response, then only by understanding that the
bit means that foo.bar.example.com needed to have been redirected by DNAME bit in the NSEC bitmap means that foo.bar.example.com needed to
the DNAME, the validator can see that it is a BOGUS reply from an have been redirected by the DNAME, the validator can see that it is a
attacker that collated existing records from the DNS to create a BOGUS reply from an attacker that collated existing records from the
confusing reply. DNS to create a confusing reply.
If the DNAME bit had not been set in the NSEC record above then the If the DNAME bit had not been set in the NSEC record above then the
answer would have validated as a correct name error response. answer would have validated as a correct name error response.
5.3.2.2. Valid Name Error Response Involving DNAME in Bitmap 5.3.4.2. Valid Name Error Response Involving DNAME in Bitmap
;; Header: QR AA DO RCODE=3(NXDOMAIN) ;; Header: QR AA DO RCODE=3(NXDOMAIN)
;; Question ;; Question
cee.example.com. IN A cee.example.com. IN A
;; Answer ;; Authority
bar.example.com. NSEC dub.example.com. A DNAME bar.example.com. NSEC dub.example.com. A DNAME
bar.example.com. RRSIG NSEC [valid signature] bar.example.com. RRSIG NSEC [valid signature]
This reply has the same NSEC records as the example above, but with This response has the same NSEC records as the example above, but
this query name (cee.example.com), the answer is validated, because with this query name (cee.example.com), the answer is validated,
'cee' does not get redirected by the DNAME at 'bar'. because 'cee' does not get redirected by the DNAME at 'bar'.
5.3.2.3. Response With Synthesized CNAME 5.3.4.3. Response With Synthesized CNAME
;; Header: QR AA DO RCODE=0(NOERROR) ;; Header: QR AA DO RCODE=0(NOERROR)
;; Question ;; Question
foo.bar.example.com. IN A foo.bar.example.com. IN A
;; Answer ;; Answer
bar.example.com. DNAME bar.example.net. bar.example.com. DNAME bar.example.net.
bar.example.com. RRSIG DNAME [valid signature] bar.example.com. RRSIG DNAME [valid signature]
foo.bar.example.com. CNAME foo.bar.example.net. foo.bar.example.com. CNAME foo.bar.example.net.
The answer shown above has the synthesized CNAME included. However, The response shown above has the synthesized CNAME included.
the CNAME has no signature, since the server does not sign online. However, the CNAME has no signature, since the server does not sign
So it cannot be trusted. It could be altered by an attacker to be online. So this response cannot be trusted. It could be altered by
foo.bar.example.com CNAME bla.bla.example. The DNAME record does an attacker to be foo.bar.example.com CNAME bla.bla.example. The
have its signature included, since it does not change for every query DNAME record does have its signature included, since it does not
name. The validator must verify the DNAME signature and then change. The validator must verify the DNAME signature and then
recursively resolve further to query for the foo.bar.example.net A recursively resolve further to query for the foo.bar.example.net A
record. record.
6. IANA Considerations 6. IANA Considerations
The DNAME Resource Record type code 39 (decimal) originally has been The DNAME Resource Record type code 39 (decimal) originally has been
registered by [RFC2672]. IANA should update the DNS resource record registered by [RFC2672]. IANA should update the DNS resource record
registry to point to this document for RR type 39. registry to point to this document for RR type 39.
This draft requests the second highest bit in the EDNS flags field This draft requests the second highest bit in the EDNS flags field
for the Understand-DNAME (UD) flag as described in Section 3.1. for the Understand-DNAME (UD) flag as described in Section 3.1.
7. Security Considerations 7. Security Considerations
DNAME redirects queries elsewhere, which may impact security based on DNAME redirects queries elsewhere, which may impact security based on
policy and the security status of the zone with the DNAME and the policy and the security status of the zone with the DNAME and the
redirection zone's security status. redirection zone's security status. For validating resolvers, the
lowest security status of the links in the chain of CNAME and DNAME
redirections is applied to the result.
If a validating resolver accepts wildcarded DNAMEs, this creates If a validating resolver accepts wildcarded DNAMEs, this creates
security issues. Since the processing of a wildcarded DNAME is non- security issues. Since the processing of a wildcarded DNAME is non-
deterministic and the CNAME that was substituted by the server has no deterministic and the CNAME that was substituted by the server has no
signature, the resolver may choose a different result than what the signature, the resolver may choose a different result than what the
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 RFC 4034 Section 5.3.4 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, Niall O'Reilly, Sam Weiler, Alfred Lewis, Mark Andrews, Mike StJohns, Niall O'Reilly, Sam Weiler, Alfred
Hoenes and Kevin Darcy for their review and comments on this Hoenes and Kevin Darcy for their review and comments on this
document. document.
skipping to change at page 15, line 37 skipping to change at page 17, line 25
Rose, "Resource Records for the DNS Security Extensions", Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005. RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005. Extensions", RFC 4035, March 2005.
[RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name
System", RFC 4592, July 2006. System", RFC 4592, July 2006.
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
Security (DNSSEC) Hashed Authenticated Denial of
Existence", RFC 5155, March 2008.
9.2. Informative References 9.2. Informative References
[RFC1912] Barr, D., "Common DNS Operational and Configuration [RFC1912] Barr, D., "Common DNS Operational and Configuration
Errors", RFC 1912, February 1996. Errors", RFC 1912, February 1996.
[RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection",
RFC 2672, August 1999. RFC 2672, August 1999.
[RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
Hain, "Representing Internet Protocol version 6 (IPv6) Hain, "Representing Internet Protocol version 6 (IPv6)
skipping to change at page 16, line 19 skipping to change at page 18, line 19
100 Bureau Dr. 100 Bureau Dr.
Gaithersburg, MD 20899 Gaithersburg, MD 20899
USA USA
Phone: +1-301-975-8439 Phone: +1-301-975-8439
Fax: +1-301-975-6238 Fax: +1-301-975-6238
EMail: scottr@nist.gov EMail: scottr@nist.gov
Wouter Wijngaards Wouter Wijngaards
NLnet Labs NLnet Labs
Kruislaan 419 Science Park 140
Amsterdam 1098 VA Amsterdam 1098 XG
The Netherlands The Netherlands
Phone: +31-20-888-4551 Phone: +31-20-888-4551
EMail: wouter@nlnetlabs.nl EMail: wouter@nlnetlabs.nl
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 43 change blocks. 
104 lines changed or deleted 162 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/