draft-ietf-dnsext-rfc2672bis-dname-18.txt   draft-ietf-dnsext-rfc2672bis-dname-19.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) November 12, 2009 (if approved) April 20, 2010
Intended status: Standards Track Intended status: Standards Track
Expires: May 16, 2010 Expires: October 22, 2010
Update to DNAME Redirection in the DNS Update to DNAME Redirection in the DNS
draft-ietf-dnsext-rfc2672bis-dname-18 draft-ietf-dnsext-rfc2672bis-dname-19
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
skipping to change at page 1, line 49 skipping to change at page 1, line 49
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 May 16, 2010. This Internet-Draft will expire on October 22, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 12 skipping to change at page 3, line 12
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. The DNAME Resource Record . . . . . . . . . . . . . . . . . . 4 2. The DNAME Resource Record . . . . . . . . . . . . . . . . . . 4
2.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. The DNAME Substitution . . . . . . . . . . . . . . . . . . 5 2.2. The DNAME Substitution . . . . . . . . . . . . . . . . . . 5
2.3. DNAME Owner Name not Redirected Itself . . . . . . . . . . 6 2.3. DNAME Owner Name Matching the QNAME . . . . . . . . . . . 7
2.4. Names Next to and Below a DNAME Record . . . . . . . . . . 7 2.4. Names Next to and Below a DNAME Record . . . . . . . . . . 7
2.5. Compression of the DNAME record. . . . . . . . . . . . . . 7 2.5. Compression of the DNAME record. . . . . . . . . . . . . . 7
3. Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. CNAME synthesis . . . . . . . . . . . . . . . . . . . . . 8 3.1. CNAME synthesis . . . . . . . . . . . . . . . . . . . . . 8
3.2. Server algorithm . . . . . . . . . . . . . . . . . . . . . 8 3.2. Server algorithm . . . . . . . . . . . . . . . . . . . . . 9
3.3. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . 10 3.3. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . 11
3.4. Acceptance and Intermediate Storage . . . . . . . . . . . 10 3.4. Acceptance and Intermediate Storage . . . . . . . . . . . 11
4. DNAME Discussions in Other Documents . . . . . . . . . . . . . 11 4. DNAME Discussions in Other Documents . . . . . . . . . . . . . 11
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 . . . . . . . . . . . . . . . . . . . . . 13 5.3. DNSSEC and DNAME . . . . . . . . . . . . . . . . . . . . . 13
5.3.1. Signed DNAME, Unsigned Synthesized CNAME . . . . . . . 13 5.3.1. Signed DNAME, Unsigned Synthesized CNAME . . . . . . . 13
5.3.2. DNAME Bit in NSEC Type Map . . . . . . . . . . . . . . 13 5.3.2. DNAME Bit in NSEC Type Map . . . . . . . . . . . . . . 14
5.3.3. DNAME Chains as Strong as the Weakest Link . . . . . . 13 5.3.3. DNAME Chains as Strong as the Weakest Link . . . . . . 14
5.3.4. Validators Must Understand DNAME . . . . . . . . . . . 13 5.3.4. Validators Must Understand DNAME . . . . . . . . . . . 14
5.3.4.1. DNAME in Bitmap Causes Invalid Name Error . . . . 13 5.3.4.1. DNAME in Bitmap Causes Invalid Name Error . . . . 14
5.3.4.2. Valid Name Error Response Involving DNAME in 5.3.4.2. Valid Name Error Response Involving DNAME in
Bitmap . . . . . . . . . . . . . . . . . . . . . . 14 Bitmap . . . . . . . . . . . . . . . . . . . . . . 15
5.3.4.3. Response With Synthesized CNAME . . . . . . . . . 14 5.3.4.3. Response With Synthesized CNAME . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . . 16 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
resource records is that the CNAME RR directs the lookup of data at resource records is that the CNAME RR directs the lookup of data at
its owner to another single name, a DNAME RR directs lookups for data its owner to another single name, a DNAME RR directs lookups for data
at descendents of its owner's name to corresponding names under a at descendants of its owner's name to corresponding names under a
different (single) node of the tree. different (single) node of the tree.
Take for example, looking through a zone (see RFC 1034 [RFC1034], Take for example, looking through a zone (see RFC 1034 [RFC1034],
section 4.3.2, step 3) for the domain name "foo.example.com" and a section 4.3.2, step 3) for the domain name "foo.example.com" and a
DNAME resource record is found at "example.com" indicating that all DNAME resource record is found at "example.com" indicating that all
queries under "example.com" be directed to "example.net". The lookup queries under "example.com" be directed to "example.net". The lookup
process will return to step 1 with the new query name of process will return to step 1 with the new query name of
"foo.example.net". Had the query name been "www.foo.example.com" the "foo.example.net". Had the query name been "www.foo.example.com" the
new query name would be "www.foo.example.net". new query name would be "www.foo.example.net".
skipping to change at page 5, line 14 skipping to change at page 5, line 14
Its RDATA is comprised of a single field, <target>, which contains a Its RDATA is comprised of a single field, <target>, which contains a
fully qualified domain name that must be sent in uncompressed form fully qualified domain name that must be sent in uncompressed form
[RFC1035], [RFC3597]. The <target> field MUST be present. The [RFC1035], [RFC3597]. The <target> field MUST be present. The
presentation format of <target> is that of a domain name [RFC1035]. presentation format of <target> is that of a domain name [RFC1035].
<owner> <ttl> <class> DNAME <target> <owner> <ttl> <class> DNAME <target>
The effect of the DNAME RR is the substitution of the record's The effect of the DNAME RR is the substitution of the record's
<target> for its owner name, as a suffix of a domain name. This <target> for its owner name, as a suffix of a domain name. This
substitution has to be applied for every DNAME RR found in the substitution is to be applied for all names below the owner name of
resolution process, which allows fairly lengthy valid chains of DNAME the DNAME RR. This substitution has to be applied for every DNAME RR
RRs. found in the resolution process, which allows fairly lengthy valid
chains of DNAME RRs.
Details of the substitution process, methods to avoid conflicting Details of the substitution process, methods to avoid conflicting
resource records, and rules for specific corner cases are given in resource records, and rules for specific corner cases are given in
the following subsections. the following subsections.
2.2. The DNAME Substitution 2.2. The DNAME Substitution
When following RFC 1034 [RFC1034], section 4.3.2's algorithm's third 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 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. is found to own a DNAME resource record a DNAME substitution occurs.
skipping to change at page 6, line 17 skipping to change at page 6, line 17
the DNAME record. The result is the resulting name after performing the DNAME record. The result is the resulting name after performing
the DNAME substitution on the query name. "no match" means that the the DNAME substitution on the query name. "no match" means that the
query did not match the DNAME and thus no substitution is performed query did not match the DNAME and thus no substitution is performed
and a possible error message is returned (if no other result is and a possible error message is returned (if no other result is
possible). Thus every line contains one example substitution. In possible). Thus every line contains one example substitution. In
the examples below, 'cyc' and 'shortloop' contain loops. the examples below, 'cyc' and 'shortloop' contain loops.
QNAME owner DNAME target result QNAME owner DNAME target result
---------------- -------------- -------------- ----------------- ---------------- -------------- -------------- -----------------
com. example.com. example.net. <no match> com. example.com. example.net. <no match>
example.com. example.com. example.net. <no match> example.com. example.com. example.net. [0]
a.example.com. example.com. example.net. a.example.net. a.example.com. example.com. example.net. a.example.net.
a.b.example.com. example.com. example.net. a.b.example.net. a.b.example.com. example.com. example.net. a.b.example.net.
ab.example.com. b.example.com. example.net. <no match> ab.example.com. b.example.com. example.net. <no match>
foo.example.com. example.com. example.net. foo.example.net. foo.example.com. example.com. example.net. foo.example.net.
a.x.example.com. x.example.com. example.net. a.example.net. a.x.example.com. x.example.com. example.net. a.example.net.
a.example.com. example.com. y.example.net. a.y.example.net. a.example.com. example.com. y.example.net. a.y.example.net.
cyc.example.com. example.com. example.com. cyc.example.com. cyc.example.com. example.com. example.com. cyc.example.com.
cyc.example.com. example.com. c.example.com. cyc.c.example.com. cyc.example.com. example.com. c.example.com. cyc.c.example.com.
shortloop.x.x. x. . shortloop.x. shortloop.x.x. x. . shortloop.x.
shortloop.x. x. . shortloop. shortloop.x. x. . shortloop.
[0] The result depends on the QTYPE. If the QTYPE = DNAME, then
the result is "example.com." else "<no match>"
Table 1. DNAME Substitution Examples. Table 1. DNAME Substitution Examples.
It is possible for DNAMEs to form loops, just as CNAMEs can form It is possible for DNAMEs to form loops, just as CNAMEs can form
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 would be a name over 255 octets. If octets in length, the result would be a name over 255 octets. If
this occurs the server returns an RCODE of YXDOMAIN [RFC2136]. The this occurs the server returns an RCODE of YXDOMAIN [RFC2136]. The
DNAME record and its signature (if the zone is signed) are included DNAME record and its signature (if the zone is signed) are included
in the answer as proof for the YXDOMAIN (value 6) RCODE. in the answer as proof for the YXDOMAIN (value 6) RCODE.
2.3. DNAME Owner Name not Redirected Itself 2.3. DNAME Owner Name Matching the QNAME
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, CNAMEs or resource record types at that domain name, except DNAMEs, CNAMEs or
other types that have restrictions on what they can co-exist with. other types that have restrictions on what they can co-exist with.
When there is a match of the QTYPE to a type (or types) also owned by
the owner name the response is sourced from the owner name. E.g., a
QTYPE of ANY would return the (available) types at the owner name,
not the target name.
DNAME RRs MUST NOT appear at the same owner name as an NS RR unless DNAME RRs MUST NOT appear at the same owner name as an NS RR unless
the owner name is the zone apex. the owner name is the zone apex as this would constitute data below a
zone cut.
If a DNAME record is present at the zone apex, there is still a need If a DNAME record is present at the zone apex, there is still a need
to have the customary SOA and NS resource records there as well. to have the customary SOA and NS resource records there as well.
Such a DNAME cannot be used to mirror a zone completely, as it does Such a DNAME cannot be used to mirror a zone completely, as it does
not mirror the zone apex. 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
skipping to change at page 8, line 15 skipping to change at page 8, line 27
3. Processing 3. Processing
The DNAME RR causes type NS additional section processing. This The DNAME RR causes type NS additional section processing. This
refers to action at step 6 of the server algorithm outlined in refers to action at step 6 of the server algorithm outlined in
section 3.2. section 3.2.
3.1. CNAME synthesis 3.1. CNAME synthesis
When preparing a 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 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 section. Relevant includes the following cases:
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 1. The DNAME is being employed as a substitution instruction.
equal to the TTL of the corresponding DNAME record. A TTL of zero
means that the CNAME can be discarded immediately after processing 2. The DNAME itself matches the QTYPE and the owner name matches
the answer. QNAME.
When the owner name name matches the QNAME and the QTYPE matches
another type owned there, the DNAME is not included in the answer.
A CNAME RR with TTL equal to the corresponding DNAME RR is
synthesized and included in the answer section when the DNAME is
employed as a substitution instruction. 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.
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. If the server in question is a cache, the
synthesized CNAME's TTL SHOULD be equal to the decremented TTL of the
cached DNAME.
Resolvers MUST be able to handle a synthesized CNAME TTL of zero or
equal to the TTL of the corresponding DNAME record (as some older
authoritative server implementations set the TTL of synthesized
CNAMEs to zero). A TTL of zero means that the CNAME can be discarded
immediately after processing the answer.
3.2. Server algorithm 3.2. Server algorithm
Below is the server algorithm, which appeared in RFC 2672 Section Below is the server algorithm, which appeared in RFC 2672 Section
4.1. 4.1.
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
skipping to change at page 13, line 6 skipping to change at page 13, line 33
punycode in their RDATA. What must be done then is to have the punycode in their RDATA. What must be done then is to have the
domain names with DNAME substitution already applied to it as the MX, domain names with DNAME substitution already applied to it as the MX,
NS, PTR, SRV data. These are valid canonical hostnames. NS, PTR, SRV data. 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 reject 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 a CNAME RR or another DNAME RR non-DNAME/CNAME RR at a name that already has a DNAME RR associated
associated with that name. with that name. Otherwise, replace the DNAME RR with the DNAME (or
CNAME) update RR. This is similar behavior to dynamic updates to an
owner name of a CNAME RR [RFC2136].
5.3. DNSSEC and DNAME 5.3. DNSSEC and DNAME
The following subsections specify the behavior of implementations The following subsections specify the behavior of implementations
that understand both DNSSEC and DNAME (synthesis). that understand both DNSSEC and DNAME (synthesis).
5.3.1. Signed DNAME, Unsigned Synthesized CNAME 5.3.1. Signed DNAME, Unsigned Synthesized CNAME
In any response, a signed DNAME RR indicates a non-terminal In any response, a signed DNAME RR indicates a non-terminal
redirection of the query. There might or might not be a server redirection of the query. There might or might not be a server
synthesized CNAME in the answer section; if there is, the CNAME will synthesized CNAME in the answer section; if there is, the CNAME will
never be signed. For a DNSSEC validator, verification of the DNAME never be signed. For a DNSSEC validator, verification of the DNAME
RR and then checking that the CNAME was properly synthesized is RR and then checking that the CNAME was properly synthesized is
sufficient proof. sufficient proof.
5.3.2. DNAME Bit in NSEC Type Map 5.3.2. DNAME Bit in NSEC Type Map
In any negative response, the NSEC or NSEC3 [RFC5155] record type bit 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 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 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, query name is a sub-domain of the closest encloser that is asserted,
then DNAME substitution should have been done, but the substitution then DNAME substitution should have been done, but the substitution
has not been done as specified. has not been done as specified.
5.3.3. DNAME Chains as Strong as the Weakest Link 5.3.3. DNAME Chains as Strong as the Weakest Link
A response can contain a chain of DNAME and CNAME redirections. That 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 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 data error) reply. Each step in that chain results in resource
records added to the answer or authority section of the response. 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. 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. If one of the steps is bogus, the result is bogus.
5.3.4. Validators Must Understand DNAME 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 In the examples below, SOA records, wildcard denial NSECs and other
material not under discussion has been omitted. material not under discussion has been omitted or shortened.
5.3.4.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 RCODE=3(NXDOMAIN)
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; Question ;; Question
foo.bar.example.com. IN A foo.bar.example.com. IN A
;; Authority ;; 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 received response, then only by understanding that the If this is the received response, then only by understanding that the
DNAME bit in the NSEC bitmap means that foo.bar.example.com needed to DNAME bit in the NSEC bitmap means that foo.bar.example.com needed to
have been redirected by the DNAME, the validator can see that it is a have been redirected by the DNAME, the validator can see that it is a
BOGUS reply from an attacker that collated existing records from the BOGUS reply from an attacker that collated existing records from the
DNS to create a 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.4.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 RCODE=3(NXDOMAIN)
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; Question ;; Question
cee.example.com. IN A cee.example.com. IN A
;; Authority ;; 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 response has the same NSEC records as the example above, but This response has the same NSEC records as the example above, but
with this query name (cee.example.com), the answer is validated, with this query name (cee.example.com), the answer is validated,
because 'cee' does not get redirected by the DNAME at 'bar'. because 'cee' does not get redirected by the DNAME at 'bar'.
5.3.4.3. Response With Synthesized CNAME 5.3.4.3. Response With Synthesized CNAME
;; Header: QR AA DO RCODE=0(NOERROR) ;; Header: QR AA RCODE=0(NOERROR)
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; 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 response shown above has the synthesized CNAME included. The response shown above has the synthesized CNAME included.
However, the CNAME has no signature, since the server does not sign However, the CNAME has no signature, since the server does not sign
online. So this response cannot be trusted. It could be altered by online. So this response cannot be trusted. It could be altered by
skipping to change at page 17, line 15 skipping to change at page 18, line 15
Authors' Addresses Authors' Addresses
Scott Rose Scott Rose
NIST NIST
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@gmail.com
Wouter Wijngaards Wouter Wijngaards
NLnet Labs NLnet Labs
Science Park 140 Science Park 140
Amsterdam 1098 XG 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
 End of changes. 29 change blocks. 
50 lines changed or deleted 86 lines changed or added

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