DNS Extensions Working Group S. Rose Internet-Draft VeriSign, Inc. Intended status: Standards Track W. Wijngaards Expires: March 29, 2007 NLnet Labs September 25, 2006 Update to DNAME Redirection draft-ietf-dnsext-rfc2672bis-dname-00 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 March 29, 2007. Copyright Notice Copyright (C) The Internet Society (2006). 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. Changes to the DNS protocol since DNAME's introduction has lead to a need to clarify several issues in the DNAME specification. These issues are discussed in this document. Rose & Wijngaards Expires March 29, 2007 [Page 1] Internet-Draft DNAME Redirection September 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. The DNAME Resource Record . . . . . . . . . . . . . . . . . . . 3 3. DNAME according to RFC 2672 . . . . . . . . . . . . . . . . . . 4 3.1. A DNAME in a Zone . . . . . . . . . . . . . . . . . . . . . 4 3.2. DNAME in Responses . . . . . . . . . . . . . . . . . . . . 4 3.3. DNAME Discussions in Other Documents . . . . . . . . . . . 5 4. Issues with DNAME . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. DNAME as Delegation Tool . . . . . . . . . . . . . . . . . 5 4.2. DNAME Apex is not Redirected Itself . . . . . . . . . . . . 5 4.3. DNAME is Always Included in Outgoing Packets. . . . . . . . 6 4.4. MX and NS Records Require that the DNAME in their RDATA is Canonical . . . . . . . . . . . . . . . . . . . . 6 4.5. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.6. Signaling of DNAME Understanding . . . . . . . . . . . . . 6 4.7. A DNAME is not a Zone-cut . . . . . . . . . . . . . . . . . 6 4.8. DNAME and CIDR Blocks in in-addr.arpa . . . . . . . . . . . 6 4.9. Name Compression in RDATA . . . . . . . . . . . . . . . . . 6 4.10. Synthesized CNAME TTL=0 . . . . . . . . . . . . . . . . . . 7 4.11. Wildcarded DNAME . . . . . . . . . . . . . . . . . . . . . 7 4.12. NSEC3 and DNAME . . . . . . . . . . . . . . . . . . . . . . 7 4.13. PTR Records and DNAME . . . . . . . . . . . . . . . . . . . 7 4.14. Small Corner Cases . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 8. Normative References . . . . . . . . . . . . . . . . . . . . . 8 Rose & Wijngaards Expires March 29, 2007 [Page 2] Internet-Draft DNAME Redirection September 2006 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 is redirected to foo.bar.example.net. The DNAME RR is similar to the CNAME RR in that it provides redirection. But where the CNAME RR only provides redirection for exactly one name, the DNAME RR provides redirection for all names in a sub-tree of the DNS name tree. The usage of DNAME lies in redirection of name spaces. An important use is finer control over delegation, where you want several names to be directed to the same name server. In other words, you would like the name spaces below several names to be mapped to the same zone. Examples in practice are classless reverse address space delegations and punycode alternates for domain spaces. All the usage examples envisioned are really for the delegation of multiple different names below a zone to the same sub-zone, even though the DNAME syntax permits more bizarre redirection patterns. [[editors note: In this version of the draft, issues that have been identified are discussed, and some ideas for proposals are put forward. Later versions of this document will contain more formal clarifications or an update to the DNAME specification.]] 2. The DNAME Resource Record The DNAME RR has mnemonic DNAME and type code 39 (decimal). The format of the DNAME record has not changed compared to RFC 2672. DNAME has the following format: DNAME The format is not class-sensitive. All fields are required. The RDATA field target is a domain-name. The compression of the RDATA field target name issue is covered in a later section. The DNAME RR causes type NS additional section processing. DNAME is a singleton type, only one DNAME is allowed per name. No resource records exist below a DNAME. Rose & Wijngaards Expires March 29, 2007 [Page 3] Internet-Draft DNAME Redirection September 2006 CNAME and DNAME are not allowed together for the same name. This is because no records are allowed next to a CNAME. DNAMEs cause substitution to happen to query names. There are limits on the descendants of a name with a DNAME record (none allowed), and limits on record types allowed for the name that has the DNAME, as well as loops that are possible due to DNAMEs. These issues are explained more thoroughly in later sections. 3. DNAME according to RFC 2672 This section presents a clarification of what RFC 2672 says. 3.1. A DNAME in a Zone x. DNAME y. is like having CNAMEs for all records with domain names ending in .x to domain names ending in .y. The DNAME RR only impacts labels below x., such as foo.x., foo.bar.x., but not x. itself. The DNAME RR allows RRs of other types to be at x with the exception of RRType CNAME. The DNAME RR above does not allow a CNAME or other DNAME RRs at x. So a DNAME RRset may only have one RR in it, and CNAMEs and DNAMEs are mutually exclusive. DNAMEs are valid only for their CLASS. For a different CLASS different DNAME records are allowed. x. DNAME y. does not allow anything to exist below x. Thus, foo.x., foo.bar.x are not allowed to have RRs. Their contents are hidden and ignored. To get their contents the DNAME must be invoked and the resulting target queried. 3.2. DNAME in Responses The DNAME RR record is always included in the answer section of a query. The target name of the DNAME (y.) is to be sent uncompressed to old resolvers (so the DNAME can be treated as an unknown type). Compressed if possible. Thus servers must be able to read compressed or uncompressed target names and write uncompressed names for old resolvers. See issue on target RDATA compression. 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 CNAMEs do not have to be signed. The DNAME has an RRSIG and a validating resolver can check the CNAMEs against the DNAME record. RFC2672 claims that EDNS 0 and less signals non-understanding of DNAME and DNAME target name compression. EDNS 1 and up may signal understanding. The EDNS DNSSEC-OK bit signals understanding of Rose & Wijngaards Expires March 29, 2007 [Page 4] Internet-Draft DNAME Redirection September 2006 DNAME. 3.3. DNAME Discussions in Other Documents In [RFC2181] as reference, in Section 10.3., some information is pertinent, on MX and NS records.: 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. RFC 4592 [RFC4592] says that DNAMEs are discouraged at wildcards. DNAMEs and CNAMEs can form loops. DNAME is discussed in RFC 3363, section 4, on A6 and DNAME. DNAME is NOT RECOMMENDED for use in the ip6 reverse tree [RFC3363]. And from [RFC4294], all references to DNAME should have been removed. There needs to be a better clarification of the status of DNAME in RFC 3363 which would be to drop all constraints on having DNAME RRs in these zones. 4. Issues with DNAME There are several issues on DNAME as specified in RFC 2672 [RFC2672]. 4.1. DNAME as Delegation Tool DNAMEs can be used as indirections, the goal of these indirections is to mirror a part of the DNS domain tree in another part of the DNS domain tree. This mirroring should be easy. Alternative wording is that the goal is to have an alias name for a part of the domain tree. Running example is x DNAME y. The extra point here is that the mirroring is done at exactly a delegation point. There is a use for this case. 4.2. DNAME Apex is not Redirected Itself Since the x is not CNAME'd itself, queries for the DNAME apex RRs are answered with data at x not at y. The reason for the original decision was that in this way (without DNAME apex affected) one can Rose & Wijngaards Expires March 29, 2007 [Page 5] Internet-Draft DNAME Redirection September 2006 have a DNAME at the zone apex, next to the SOA, NS records, without problem. And use this to point zones under your operational control to other zones. Hosting two identical zones for example. Another reason for excluding the DNAME apex from the DNAME is that one can then query for the DNAME through RFC 1034 [RFC1034] caches. 4.3. DNAME is Always Included in Outgoing Packets. Old resolvers or firewalls may drop packets with this unknown RR type. 4.4. MX and NS Records Require that the DNAME in their RDATA is Canonical This means immediately resolve, no CNAMEs no DNAMEs. See the reference to RFC 2181, Section 10.3 above. Also in RFC 1912 [RFC1912], Section 2.4. 4.5. DNSSEC For a name error response, the resolver has to check the closest encloser NSEC to make sure it has no DNAME bit set. If a DNAME had been present, that DNAME redirection should have been followed. 4.6. Signaling of DNAME Understanding Some mechanism to signal that CNAMEs need not be synthesized. Also signal that DNAME target compression can be used (if RDATA target name compression is allowed at all). EDNS version seems the most obvious, states the rfc. The gain is compression of the DNAME rname, and smaller response size. 4.7. A DNAME is not a Zone-cut A DNAME is not a zone-cut. You may want to use it as such to mirror a part of the DNS tree, but RFC 2672 DNAME is not usable because the apex is not redirected. 4.8. DNAME and CIDR Blocks in in-addr.arpa Is DNAME the Way to go for CIDR Blocks in in-addr.arpa? Should this be addressed by this document? 4.9. Name Compression in RDATA For old versions of servers only uncompressed is possible. New version can still choose to use compressed or not. Rose & Wijngaards Expires March 29, 2007 [Page 6] Internet-Draft DNAME Redirection September 2006 Clarify on compression proposal: Senders SHOULD NOT compress RDATA, receivers MUST be able to decompress, when the new version has been negotiated with the EDNS bits. 4.10. Synthesized CNAME TTL=0 In the original specification, all synthesized CNAME RRs had a TTL of 0. Due to DNSSEC TTL=0 interpretation had to be changed to mean "keep as long as the query using this RRset is still being processed". What is the status of this CNAME? This could be synthesized CNAMEs should have a TTL equal to the TTL of the DNAME. This allows non-aware clients to cache the CNAMEs and thus lightens the load on authoritative servers. 4.11. Wildcarded DNAME What should happen with a wildcard with RRtype DNAME, i.e. *.example.com DNAME example.net. RFC 4592 [RFC4592] discourages this. Behaviour unspecified (strict interpretation of RFC 2672 says that for queries for which the wildcard is expanded, no DNAME processing occurs, and for queries for the '*' label ('foo.*.example.com') the DNAME is followed.). 4.12. NSEC3 and DNAME NSEC3 uses hashing to obscure names. This hashing can be expensive to compute. A zone that has DNAME and NSEC3 may have to do additional hashing for NSEC3 lookups. More work needs to be done to look into this and see what computational costs are involved. 4.13. PTR Records and DNAME PTR records in the reverse zone must have canonical names as their RDATA, like NS and MX records. The lookup process for PTR records owner names may involve DNAME/CNAME records, but the lookup process for PTR records RDATA names may not. RFC 1912. More problematic than NS and MX in operational sense, since the reverse zone may not be under the control of the zone operator. 4.14. Small Corner Cases There are also some corner cases to discuss and clarify. These are small issues, but additional examples can give more guidance to implementors. [[editors note: The following is to be expanded]] Rose & Wijngaards Expires March 29, 2007 [Page 7] Internet-Draft DNAME Redirection September 2006 1. Example of why DNSSEC validators MUST understand DNAME. 2. Examples of the DNAME name substitution. whole labels only, name can get longer and shorter. The '*' label is handled as a fixed string during substitution. apex is not substituted. name can get too long. 3. Corner case: queries for synthesized CNAME. Not a problem, current algorithm already creates the CNAME again from the DNAME for such a query and follows the chain of DNAME/CNAMEs. Server reminded that it must return no error. 4. Corner case: loops with single DNAME record possible. Loop: x DNAME y.x. Loop: x DNAME x. Loop: x DNAME "." for queries qname=a.x.x 5. Servers must not allow zones to be loaded below a DNAME. This is similar to requesting to not load a zone when a domain name below a DNAME contains resource records, as the RFC requests. 6. Caches must not allow data to be cached below a DNAME. CNAMES below a DNAME must be re-synthesized from the DNAME, or checked against the DNAME if needed. 5. IANA Considerations The main purpose of this draft is to discuss issues related to the use of DNAME RRs in a DNS zone. The results of these discussions may result in a new RR to augment or replace DNAME, which will require IANA action. Any solutions that propose this will be contained in a following document and not this draft. 6. 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. This document only discusses issues regarding the DNAME specification. Any clarification or replacement RR type will have different security considerations. These will be stated in a following document. 7. Acknowledgements The authors of this draft would like to acknowledge Matt Larson for beginning this effort to addres the issues related to the DNAME RR type. 8. Normative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC1912] Barr, D., "Common DNS Operational and Configuration Rose & Wijngaards Expires March 29, 2007 [Page 8] Internet-Draft DNAME Redirection September 2006 Errors", RFC 1912, February 1996. [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. [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. [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. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005. [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, April 2006. [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name System", RFC 4592, July 2006. Authors' Addresses Scott Rose VeriSign, Inc. 21345 Ridgetop Circle Dulles, VA 20166-6503 USA Phone: +1-703-948-3364 Fax: +1-... EMail: srose@verisign.com Rose & Wijngaards Expires March 29, 2007 [Page 9] Internet-Draft DNAME Redirection September 2006 Wouter Wijngaards NLnet Labs Kruislaan 419 Amsterdam 1098 VA The Netherlands Phone: +31-20-888-4551 Fax: +31-20-888-4462 EMail: wouter@nlnetlabs.nl Rose & Wijngaards Expires March 29, 2007 [Page 10] Internet-Draft DNAME Redirection September 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). 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 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 March 29, 2007 [Page 11]