+Rose & Wijngaards Expires February 11, 2008 [Page 15]
+\f
+Internet-Draft DNAME Redirection August 2007
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2007).
+
+ 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).
+
+
+
+
+
+
+
+Rose & Wijngaards Expires February 11, 2008 [Page 16]
+\f
+
+
+
+DNS Extensions Working Group S. Rose
+Internet-Draft NIST
+Intended status: Standards Track W. Wijngaards
+Expires: February 11, 2008 NLnet Labs
+ August 10, 2007
+
+
+ Update to DNAME Redirection in the DNS
+ draft-ietf-dnsext-rfc2672bis-dname-04
+
+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
+ other groups may also distribute working documents as Internet-
+ Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ 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 February 11, 2008.
+
+Copyright Notice
+
+ Copyright (C) The IETF Trust (2007).
+
+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
+ an update to the original specification in RFC 2672.
+
+
+
+
+
+
+Rose & Wijngaards Expires February 11, 2008 [Page 1]
+\f
+Internet-Draft DNAME Redirection August 2007
+
+
+Requirements Language
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [RFC2119].
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+
+ 2. The DNAME Resource Record . . . . . . . . . . . . . . . . . . 3
+ 2.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2.2. The DNAME Substitution . . . . . . . . . . . . . . . . . . 4
+ 2.3. DNAME Apex not Redirected itself . . . . . . . . . . . . . 5
+ 2.4. Names Next to and Below a DNAME Record . . . . . . . . . . 5
+ 2.5. Compression of the DNAME record. . . . . . . . . . . . . . 6
+
+ 3. Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 3.1. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 3.2. CNAME synthesis . . . . . . . . . . . . . . . . . . . . . 6
+ 3.3. Acceptance and Intermediate Storage . . . . . . . . . . . 7
+ 3.4. Server algorithm . . . . . . . . . . . . . . . . . . . . . 7
+
+ 4. DNAME Discussions in Other Documents . . . . . . . . . . . . . 9
+
+ 5. Other Issues with DNAME . . . . . . . . . . . . . . . . . . . 11
+ 5.1. MX, NS and PTR Records Must Point to Target of DNAME . . . 11
+ 5.2. Dynamic Update and DNAME . . . . . . . . . . . . . . . . . 11
+ 5.3. DNSSEC and DNAME . . . . . . . . . . . . . . . . . . . . . 11
+ 5.3.1. DNAME bit in NSEC/NSEC3 type map . . . . . . . . . . . 11
+ 5.3.2. Other issues with NSEC3 and DNAME . . . . . . . . . . 12
+ 5.3.3. Validators Must Understand DNAME . . . . . . . . . . . 12
+ 5.3.3.1. DNAME in Bitmap Causes Invalid Name Error . . . . 12
+ 5.3.3.2. Valid Name Error Response Involving DNAME in
+ Bitmap . . . . . . . . . . . . . . . . . . . . . . 12
+ 5.3.3.3. Response With Synthesized CNAME . . . . . . . . . 13
+
+ 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
+
+ 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
+
+ 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
+
+ 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
+ 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14
+ 9.2. Informative References . . . . . . . . . . . . . . . . . . 15
+
+
+
+
+
+Rose & Wijngaards Expires February 11, 2008 [Page 2]
+\f
+Internet-Draft DNAME Redirection August 2007
+
+
+1. Introduction
+
+ DNAME is a DNS Resource Record type. DNAME provides redirection from
+ a part of the DNS name tree to another part of the DNS name tree.
+
+ For example, given a query for foo.example.com and a DNAME from
+ example.com to example.net, the query would be redirected to
+ foo.example.net. With the same DNAME a query for foo.bar.example.com
+ would be redirected to foo.bar.example.net.
+
+ The DNAME RR is similar to the CNAME RR in that it provides
+ redirection. The CNAME RR only provides redirection for exactly one
+ name while the DNAME RR provides redirection for all names in a sub-
+ tree of the DNS name tree.
+
+ This document is an update to the original specification of DNAME in
+ RFC 2672 [RFC2672]. DNAME was conceived to help with the problem of
+ maintaining address-to-name mappings in a context of network
+ renumbering. So that with a careful set-up a renumbering event in
+ the network causes no change to the authoritative server that has the
+ address-to-name mappings. Examples in practice are classless reverse
+ address space delegations and punycode alternates for domain spaces.
+
+ Other usage of DNAME lies in redirection of name spaces. For
+ example, a zone administrator may want subtrees of the DNS to contain
+ the same information. DNAME is also used for redirection of ENUM
+ domains to another maintaining party.
+
+ This update to DNAME does not change the wire format or the handling
+ of DNAME Resource Records by existing software. A new UD (Understand
+ Dname) bit in the EDNS flags field can be used to signal that CNAME
+ synthesis is not needed. Discussion is added on problems that may be
+ encountered when using DNAME.
+
+2. The DNAME Resource Record
+
+2.1. Format
+
+ The DNAME RR has mnemonic DNAME and type code 39 (decimal).
+
+ The format of the DNAME record has not changed from the original
+ specification in RFC 2672. DNAME has the following format:
+
+ <owner> <ttl> <class> DNAME <target>
+
+ The format is not class-sensitive. All fields are required. The
+ RDATA field target is a domain name. The RDATA field target name
+ MUST be sent uncompressed [RFC3597].
+
+
+
+Rose & Wijngaards Expires February 11, 2008 [Page 3]
+\f
+Internet-Draft DNAME Redirection August 2007
+
+
+ The DNAME RR causes type NS additional section processing.
+
+2.2. The DNAME Substitution
+
+ DNAMEs cause a name substitution to happen to query names. This is
+ called the DNAME substitution. The suffix owner name of the DNAME is
+ replaced by the target of the DNAME. The owner name of the DNAME is
+ not itself redirected, only domain names below the owner name are
+ redirected. Only whole labels are replaced. A name is considered
+ below the owner name if it has more labels than the owner name, and
+ the labels of the owner name appear as the suffix of the name. See
+ the table of examples for common cases and corner cases.
+
+ In the table below, the QNAME refers to the query name. The owner is
+ the DNAME owner domain name, and the target refers to the target of
+ the DNAME record. The result is the resulting name after performing
+ the DNAME substitution on the query name. "no match" means that the
+ query did not match the DNAME and thus no substitution is performed
+ and a possible error message is returned (if no other result is
+ possible). In the examples below, 'cyc' and 'shortloop' contain
+ loops.
+
+ QNAME owner DNAME target result
+ ---------------- -------------- -------------- -----------------
+ com. example.com. example.net. <no match>
+ example.com. example.com. example.net. <no match>
+ a.example.com. example.com. example.net. a.example.net.
+ a.b.example.com. example.com. example.net. a.b.example.net.
+ ab.example.com. b.example.com. example.net. <no match>
+ foo.example.com. example.com. example.net. foo.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.
+ cyc.example.com. example.com. example.com. cyc.example.com.
+ cyc.example.com. example.com. c.example.com. cyc.c.example.com.
+ shortloop.x.x. x. . shortloop.x.
+ shortloop.x. x. . shortloop.
+
+ Table 1. DNAME Substitution Examples.
+
+ It is possible for DNAMEs to form loops. Just like CNAMEs can form
+ loops. DNAMEs and CNAMEs can chain together to form loops. A single
+ corner case DNAME can form a loop. Resolvers and servers should be
+ cautious in devoting resources to a query, but be aware that fairly
+ long chains of DNAMEs may be valid. Zone content administrators
+ should take care to insure that there are no loops that could occur
+ when using DNAME or DNAME/CNAME redirection.
+
+ The domain name can get too long during substitution. For example,
+
+
+
+Rose & Wijngaards Expires February 11, 2008 [Page 4]
+\f
+Internet-Draft DNAME Redirection August 2007
+
+
+ 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
+ octets in length, the result of the result would be a name over 255
+ octets. If this occurs the server returns an RCODE of YXDOMAIN
+ [RFC2136]. The DNAME record and its signature (if the zone is
+ signed) are included in the answer as proof for the YXDOMAIN (value
+ 6) RCODE.
+
+2.3. DNAME Apex not Redirected itself
+
+ The owner name of a DNAME is not redirected itself. The reason for
+ the original decision was that one can have a DNAME at the zone apex
+ without problem. Then use this DNAME at the zone apex to point
+ queries to the target zone. There still is a need to have the
+ customary SOA and NS resource records at the zone apex. This means
+ that DNAME does not mirror a zone completely, as it does not mirror
+ the zone apex.
+
+ Another reason for excluding the DNAME owner from the DNAME
+ substitution is that one can then query for the DNAME through RFC
+ 1034 [RFC1034] caches.
+
+ This means that a DNAME RR is not allowed at the same domain name as
+ NS records unless there is also a SOA record present. DNAME RRs are
+ not allowed at the parent side of a delegation point but are allowed
+ at a zone apex.
+
+2.4. Names Next to and Below a DNAME Record
+
+ Other resource records MUST NOT exist below the owner of a DNAME RR.
+ To get the contents for names subordinate to that owner, the DNAME
+ redirection must be invoked and the resulting target queried. A
+ server SHOULD refuse to load a zone that has data below a domain name
+ owning a DNAME RR. Also a server SHOULD refuse to load a zone
+ subordinate to the owner of a DNAME record in the ancestor zone.
+
+ 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
+ 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
+ which one to follow. A server SHOULD refuse to load a zone that
+ violates these rules.
+
+ The domain name that owns a DNAME record is allowed to have other
+ resource record types at that domain name, except DNAMEs or CNAMEs.
+
+ These rules allow DNAME records to be queried through DNAME unaware
+ caches.
+
+
+
+Rose & Wijngaards Expires February 11, 2008 [Page 5]
+\f
+Internet-Draft DNAME Redirection August 2007
+
+
+2.5. Compression of the DNAME record.
+
+ The DNAME owner name can be compressed like any other owner name.
+ The DNAME RDATA target name MUST NOT be sent out in compressed form,
+ so that a DNAME RR can be treated as an unknown type.
+
+ Although the previous specification [RFC2672] talked about signaling
+ to allow compression of the target name, no such signaling is
+ explicitly specified.
+
+ RFC2672 stated that the EDNS version had a meaning for understanding
+ of DNAME and DNAME target name compression. This document updates
+ RFC2672, in that there is no EDNS version signaling for DNAME as of
+ yet. However, the flags section of EDNS(0) is updated with a
+ Understand-DNAME flag by this document (See Section 3.2).
+
+3. Processing
+
+3.1. Wildcards
+
+ The use of DNAME in conjunction with wildcards is discouraged
+ [RFC4592]. Thus records of the form "*.example.com DNAME
+ example.net" SHOULD NOT be used.
+
+ The interaction between the expansion of the wildcard and the
+ redirection of the DNAME is non-deterministic. Because the
+ processing is non-deterministic, DNSSEC validating resolvers may not
+ be able to validate a wildcarded DNAME.
+
+ A server MAY give a warning that the behavior is unspecified if such
+ a wildcarded DNAME is loaded.
+
+3.2. CNAME synthesis
+
+ On the server side, the DNAME RR record is always included in the
+ answer section of a query. A CNAME RR record with TTL 0 is
+ synthesized for old resolvers, specifically for the QNAME in the
+ query. DNSSEC [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 DNAME record.
+
+ It does not make sense for the authoritative server to follow the
+ chain of DNAMEs, CNAMEs and wildcards outside of the zone of the
+ query, as modern resolvers will remove out-of-zone information from
+ the answer.
+
+ Resolvers MUST be able to handle a synthesized CNAME TTL of zero or
+
+
+
+Rose & Wijngaards Expires February 11, 2008 [Page 6]
+\f
+Internet-Draft DNAME Redirection August 2007
+
+
+ equal to the TTL of the corresponding DNAME record. The TTL of zero
+ means that the CNAME can be discarded immediately after processing
+ the answer. DNSSEC aware resolvers can set the Understand-DNAME (UD
+ bit) to receive a response with only the DNAME RR and no synthesized
+ CNAMEs.
+
+ The UD bit is part of the EDNS extended RCODE and Flags field. It is
+ used to omit server processing, transmission and resolver processing
+ the unsigned synthesized CNAMEs when DNSSEC validation is performed.
+ Resolvers can set this in a query to request omission of the
+ synthesized CNAMEs. 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 older servers do not copy the UD bit to the answer,
+ and will not omit synthesized CNAMEs.
+
+ Updated EDNS extended RCODE and Flags field.
+
+ +0 (MSB) +1 (LSB)
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ 0: | EXTENDED-RCODE | VERSION |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ 2: |DO|UD| Z |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+ Servers MUST be able to answer a query for a synthesized CNAME. An
+ answer containing the synthesized CNAME cannot contain an error
+ (since a CNAME has been followed), as per RFC 1034 CNAME rules.
+
+3.3. Acceptance and Intermediate Storage
+
+ DNS Caches MUST NOT allow data to be cached below the owner of a
+ DNAME RR, except CNAME records or perhaps NSEC3 records and their
+ signatures. CNAME records below the owner of a DNAME MUST be re-
+ synthesized from the DNAME, or checked against the DNAME record
+ before sending them out. This improves consistency of the DNAME and
+ CNAME records below the owner of the DNAME.
+
+ 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
+ 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.
+
+
+
+
+Rose & Wijngaards Expires February 11, 2008 [Page 7]
+\f
+Internet-Draft DNAME Redirection August 2007
+
+
+ 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
+ requested via the RD bit in the query, go to step 5, otherwise
+ step 2.
+ 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,
+ otherwise step 4.
+ 3. Start matching down, label by label, in the zone. The matching
+ process can terminate several ways:
+ A. If the whole of QNAME is matched, we have found the node.
+
+ If the data at the node is a CNAME, and QTYPE does not match
+ CNAME, copy the CNAME RR into the answer section of the
+ response, change QNAME to the canonical name in the CNAME RR,
+ and go back to step 1.
+
+ Otherwise, copy all RRs which match QTYPE into the answer
+ section and go to step 6.
+ B. If a match would take us out of the authoritative data, we
+ have a referral. This happens when we encounter a node with
+ NS RRs marking cuts along the bottom of a zone.
+
+ Copy the NS RRs for the subzone into the authority section of
+ the reply. Put whatever addresses are available into the
+ additional section, using glue RRs if the addresses are not
+ available from authoritative data or the cache. Go to step
+ 4.
+ C. If at some label, a match is impossible (i.e., the
+ corresponding label does not exist), look to see whether the
+ last label matched has a DNAME record.
+
+ If a DNAME record exists at that point, copy that record into
+ the answer section. If substitution of its <target> for its
+ <owner> in QNAME would overflow the legal size for a <domain-
+ name>, set RCODE to YXDOMAIN [RFC2136] and exit; otherwise
+ perform the substitution and continue. If the EDNS OPT
+ record is present in the query and the UD bit is set, the
+ server MAY copy the UD bit to the answer EDNS OPT record, and
+ omit CNAME synthesis. Else the server MUST synthesize a
+ CNAME record as described above and include it in the answer
+ section. Go back to step 1.
+
+ If there was no DNAME record, look to see if the "*" label
+ exists.
+
+ If the "*" label does not exist, check whether the name we
+ are looking for is the original QNAME in the query or a name
+
+
+
+Rose & Wijngaards Expires February 11, 2008 [Page 8]
+\f
+Internet-Draft DNAME Redirection August 2007
+
+
+ we have followed due to a CNAME or DNAME. If the name is
+ original, set an authoritative name error in the response and
+ exit. Otherwise just exit.
+
+ If the "*" label does exist, match RRs at that node against
+ QTYPE. If any match, copy them into the answer section, but
+ set the owner of the RR to be QNAME, and not the node with
+ the "*" label. If the data at the node with the "*" label is
+ a CNAME, and QTYPE doesn't match CNAME, copy the CNAME RR
+ into the answer section of the response changing the owner
+ name to the QNAME, change QNAME to the canonical name in the
+ CNAME RR, and go back to step 1. Otherwise, Go to step 6.
+
+ 4. Start matching down in the cache. If QNAME is found in the
+ cache, copy all RRs attached to it that match QTYPE into the
+ answer section. If QNAME is not found in the cache but a DNAME
+ record is present at an ancestor of QNAME, copy that DNAME record
+ into the answer section. If there was no delegation from
+ authoritative data, look for the best one from the cache, and put
+ it in the authority section. Go to step 6.
+ 5. Use the local resolver or a copy of its algorithm to answer the
+ query. Store the results, including any intermediate CNAMEs and
+ DNAMEs, in the answer section of the response.
+ 6. Using local data only, attempt to add other RRs which may be
+ useful to the additional section of the query. Exit.
+
+ Note that there will be at most one ancestor with a DNAME as
+ described in step 4 unless some zone's data is in violation of the
+ no-descendants limitation in section 3. An implementation might take
+ advantage of this limitation by stopping the search of step 3c or
+ step 4 when a DNAME record is encountered.
+
+4. DNAME Discussions in Other Documents
+
+ In [RFC2181], in Section 10.3., the discussion on MX and NS records
+ touches on redirection by CNAMEs, but this also holds for DNAMEs.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rose & Wijngaards Expires February 11, 2008 [Page 9]
+\f
+Internet-Draft DNAME Redirection August 2007
+
+
+ Excerpt from 10.3. MX and NS records (in RFC 2181).
+
+ 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
+ an alias. Not only is the specification clear on this
+ point, but using an alias in either of these positions
+ neither works as well as might be hoped, nor well fulfills
+ the ambition that may have led to this approach. This
+ domain name must have as its value one or more address
+ records. Currently those will be A records, however in
+ the future other record types giving addressing
+ information may be acceptable. It can also have other
+ RRs, but never a CNAME RR.
+
+ The DNAME RR is discussed in RFC 3363, section 4, on A6 and DNAME.
+ [RFC3363] does NOT RECOMMENDED the use of DNAME in the IPv6 reverse
+ tree. (Hence, all references to DNAME should have been removed from
+ [RFC4294].) Based on the experience gained in the meantime, RFC 3363
+ should be revised, dropping all constraints on having DNAME RRs in
+ these zones. This would greatly improve the manageability of the
+ IPv6 reverse tree. These changes are made explicit below.
+
+ In [RFC3363], section 4, DNAME is not recommended for the IPv6
+ reverse tree. The opening premise of this section is demonstrably
+ wrong. Everything that follows from that premise is also invalid.
+
+ In [RFC3363], the paragraph
+
+ "The issues for DNAME in the reverse mapping tree appears to be
+ closely tied to the need to use fragmented A6 in the main tree: if
+ one is necessary, so is the other, and if one isn't necessary, the
+ other isn't either. Therefore, in moving RFC 2874 to experimental,
+ the intent of this document is that use of DNAME RRs in the reverse
+ tree be deprecated."
+
+ is to be replaced with the word "DELETED".
+
+ In [RFC4294], the reference to DNAME was left in as a editorial
+ oversight. The paragraph
+
+ "Those nodes are NOT RECOMMENDED to support the experimental A6 and
+ DNAME Resource Records [RFC3363]."
+
+
+
+
+
+
+
+
+
+Rose & Wijngaards Expires February 11, 2008 [Page 10]
+\f
+Internet-Draft DNAME Redirection August 2007
+
+
+ is to be replaced by
+
+ "Those nodes are NOT RECOMMENDED to support the experimental
+ A6 Resource Record [RFC3363]."
+
+5. Other Issues with DNAME
+
+ There are several issues to be aware of about the use of DNAME.
+
+5.1. MX, NS and PTR Records Must Point to Target of DNAME
+
+ The names listed as target names of MX, NS and PTR records must be
+ canonical hostnames. This means no CNAME or DNAME redirection may be
+ present during DNS lookup of the address records for the host. This
+ is discussed in RFC 2181 [RFC2181], section 10.3, and RFC 1912
+ [RFC1912], section 2.4.
+
+ The upshot of this is that although the lookup of a PTR record can
+ involve DNAMEs, the name listed in the PTR record can not fall under
+ a DNAME. The same holds for NS and MX records. For example, when
+ punycode alternates for a zone use DNAME then the NS, MX and PTR
+ records that point to that zone must use names without 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, NS, PTR data.
+ These are valid canonical hostnames.
+
+5.2. Dynamic Update and DNAME
+
+ 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.
+
+5.3. DNSSEC and DNAME
+
+5.3.1. DNAME bit in NSEC/NSEC3 type map
+
+ When a validator checks the NSEC/NSEC3 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.
+
+
+
+
+
+
+
+Rose & Wijngaards Expires February 11, 2008 [Page 11]
+\f
+Internet-Draft DNAME Redirection August 2007
+
+
+5.3.2. Other issues with NSEC3 and DNAME
+
+ NSEC3 records and their signatures are allowed to exist below the
+ owner name of a DNAME RR. This is because of the nature of NSEC3 RRs
+ in DNSSEC, which creates hashed owner names that exist below the apex
+ name of the zone. This is an exception to the rule that there MUST
+ NOT be any other RRs under the owner name of a DNAME RR, if the DNAME
+ RR is owned by the zone apex domain name.
+
+ Queries for NSEC3 owner names are redirected as if there were no such
+ NSEC3 present.
+
+ There is no significant extra hashing cost for NSEC3 signed zones
+ when answering queries with DNAME substitution.
+
+5.3.3. Validators Must Understand DNAME
+
+ Examples of why DNSSEC validators MUST understand DNAME.
+
+5.3.3.1. DNAME in Bitmap Causes Invalid Name Error
+
+ ;; Header: QR AA DO RCODE=3(NXDOMAIN)
+ ;; Question
+ foo.bar.example.com. IN A
+ ;; Answer
+ bar.example.com. NSEC dub.example.com. A DNAME
+ bar.example.com. RRSIG NSEC [valid signature]
+
+ If this is the response, then only by understanding that the DNAME
+ bit means that foo.bar.example.com needed to 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 DNS to create a
+ confusing reply.
+
+ 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.
+
+5.3.3.2. Valid Name Error Response Involving DNAME in Bitmap
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rose & Wijngaards Expires February 11, 2008 [Page 12]
+\f
+Internet-Draft DNAME Redirection August 2007
+
+
+ ;; Header: QR AA DO RCODE=3(NXDOMAIN)
+ ;; Question
+ cee.example.com. IN A
+ ;; Answer
+ bar.example.com. NSEC dub.example.com. A DNAME
+ bar.example.com. RRSIG NSEC [valid signature]
+
+ If the query had been cee.example.com as shown above, then this
+ answer would have been validated, because 'cee' does not get
+ redirected by the DNAME at 'bar'.
+
+5.3.3.3. Response With Synthesized CNAME
+
+ ;; Header: QR AA DO RCODE=0(NOERROR)
+ ;; Question
+ foo.bar.example.com. IN A
+ ;; Answer
+ bar.example.com. DNAME bar.example.net.
+ bar.example.com. RRSIG DNAME [valid signature]
+ foo.bar.example.com. CNAME foo.bar.example.net.
+
+ The answer shown above has the synthesized CNAME included. However,
+ the CNAME has no signature, since the server does not sign online (it
+ is a slow operation and exposes the signing key). So it cannot be
+ trusted. It could be altered by an attacker to be
+ foo.bar.example.com CNAME bla.bla.example. The DNAME record does
+ have its signature included, since it does not change for every query
+ name. The validator must verify the DNAME signature and then
+ recursively resolve further to query for the foo.bar.example.net A
+ record.
+
+6. IANA Considerations
+
+ The main purpose of this draft is to discuss issues related to the
+ use of DNAME RRs in a DNS zone. The original document registered the
+ DNAME Resource Record type code 39 (decimal). IANA should update the
+ DNS resource record registry by adding a pointer to this document for
+ RR type 39.
+
+ This draft requests the second highest bit in the EDNS flags field
+ for the Understand-DNAME (UD) flag.
+
+7. Security Considerations
+
+ DNAME redirects queries elsewhere, which may impact security based on
+ policy and the security status of the zone with the DNAME and the
+ redirection zone's security status.
+
+
+
+
+Rose & Wijngaards Expires February 11, 2008 [Page 13]
+\f
+Internet-Draft DNAME Redirection August 2007
+
+
+ If a validating resolver accepts wildcarded DNAMEs, this creates
+ security issues. Since the processing of a wildcarded DNAME is non-
+ deterministic and the CNAME that was substituted by the server has no
+ signature, the resolver may choose a different result than what the
+ 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.3 examples are given that illustrate this need. These
+ examples are shown with NSEC records, but similar cases exist for
+ NSEC3.
+
+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.
+
+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.
+
+ [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
+ "Dynamic Updates in the Domain Name System (DNS UPDATE)",
+ RFC 2136, April 1997.
+
+ [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
+ Specification", RFC 2181, July 1997.
+
+ [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection",
+ RFC 2672, August 1999.
+
+ [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
+ (RR) Types", RFC 3597, September 2003.
+
+ [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "DNS Security Introduction and Requirements",
+ RFC 4033, March 2005.
+
+ [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "Resource Records for the DNS Security Extensions",
+ RFC 4034, March 2005.
+
+
+
+Rose & Wijngaards Expires February 11, 2008 [Page 14]
+\f
+Internet-Draft DNAME Redirection August 2007
+
+
+ [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "Protocol Modifications for the DNS Security
+ Extensions", RFC 4035, March 2005.
+
+ [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name
+ System", RFC 4592, July 2006.
+
+9.2. Informative References
+
+ [RFC1912] Barr, D., "Common DNS Operational and Configuration
+ Errors", RFC 1912, February 1996.
+
+ [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
+ Hain, "Representing Internet Protocol version 6 (IPv6)
+ Addresses in the Domain Name System (DNS)", RFC 3363,
+ August 2002.
+
+ [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294,
+ April 2006.
+
+Authors' Addresses
+
+ Scott Rose
+ NIST
+ 100 Bureau Dr.
+ Gaithersburg, MD 20899
+ USA
+
+ Phone: +1-301-975-8439
+ Fax: +1-301-975-6238
+ EMail: scottr@nist.gov
+
+
+ Wouter Wijngaards
+ NLnet Labs
+ Kruislaan 419
+ Amsterdam 1098 VA
+ The Netherlands
+
+ Phone: +31-20-888-4551
+ EMail: wouter@nlnetlabs.nl
+
+
+
+
+
+
+
+
+
+
Rose & Wijngaards Expires February 11, 2008 [Page 15]
\f
Internet-Draft DNAME Redirection August 2007
projects / thirdparty / bind9.git / commitdiff
