dnsext D. Barton, Ed. Internet-Draft GridFury, LLC Intended status: Standards Track March 7, 2011 Expires: September 8, 2011 Cloning Domain Name System (DNS) Labels for Fun and Profit draft-barton-clone-dns-labels-fun-profit-00.txt Abstract This document describes a method for making one or more Domain Name System (DNS) labels behave in the DNS "as if" they were actually an entirely different label. E.g., the delegee for the example.org zone could define bar.example.org to be a CLONE of foo.example.org. This method is designed to meet the needs of those managing Internationalized Domain Name (IDN) zones that have been determined to be semantically similar, and therefore should be treated "as if" they were identical. This method can also be used more generally to handle situations where currently either CNAME or DNAME Resource Records are being used. A key design goal for the CLONE method is that except for DNSSEC support all of the semantic benefits are available by updating the authoritative servers for the zone. Therefore unless DNSSEC support for the CLONEd zones is required there is no dependency on end users being behind a CLONE-Aware resolving name server. Foreword [RFC Editor, please remove this Section at publication time. Thanks.] This is my first draft, please be gentle. :) I'm definitely open to the possibility that there are better ways to accomplish the concepts presented herein. I'm sure that there are a non-zero number of errors in the formatting, references, etc. Also Sections 2 and 3 may be under-specified, unclear, or unworkable. So please don't be afraid to offer (constructive) criticism. TODO: Update/add/improve references? Add/improve examples? Revision History: Barton Expires September 8, 2011 [Page 1] Internet-Draft Cloning DNS Labels March 2011 1. -00 Initial version 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 [RFC2119]. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on September 8, 2011. Copyright Notice Copyright (c) 2011 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Barton Expires September 8, 2011 [Page 2] Internet-Draft Cloning DNS Labels March 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. CLONE Overview . . . . . . . . . . . . . . . . . . . . . . 5 2. The Authoritative Name Server . . . . . . . . . . . . . . . . 5 2.1. Parent Zone File . . . . . . . . . . . . . . . . . . . . . 5 2.2. Child Authoritative Server Configuration . . . . . . . . . 6 2.3. Query Response For CLONE Labels . . . . . . . . . . . . . 6 2.4. Query Response For CLONE And CLONES Resource Records . . . 7 3. The CLONE-Aware Resolving Name Server . . . . . . . . . . . . 7 3.1. CARNS DNSSEC Behavior For "Typical" Queries . . . . . . . 7 3.2. CARNS Behavior for DNSSEC Resource Record Queries . . . . 7 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Non-CARNS . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. CARNS - First Query For CLONE . . . . . . . . . . . . . . 8 4.3. CARNS - Second Query For CLONE . . . . . . . . . . . . . . 8 4.4. CLONES Response . . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 Barton Expires September 8, 2011 [Page 3] Internet-Draft Cloning DNS Labels March 2011 1. Introduction The DNS was initially designed and implemented during a period when the American Standard Code for Information Interchange (ASCII) text was the lingua franca, and certain assumptions about the characteristic behavior of ASCII text, and how it is commonly understood in written form, were baked into the protocol. For example, while the following may not be stylistically appealing on the printed page; not only would all of the following be handled the same by the DNS, there would not be any confusion that all of the following representations refer to the same hostname: o example.org o Example.Org o eXaMpLe.oRg o EXAMPLE.ORG Because of the way that Internationalized Domain Names (IDNs) [RFC5890] work it is not possible for the DNS to provide the same level(s) or type(s) of equivalence for different Unicode Code Points that upper and lower case ASCII letters enjoy. Furthermore, there are unique issues with Unicode representations of DNS labels that have no equivalents in ASCII text. More information about the problems that this document attempts to provide a solution for can be found in DNS Resolution of Aliased Names [I-D.ietf-dnsext-aliasing-requirements]. In addition to solving the DNS part of the problem of IDN equivalence, being able to use a more complete solution to the problem of "aliasing" DNS labels than CNAMEs [RFC1035] and DNAMEs [RFC2672] currently provide also has appeal. 1.1. Terminology There is some feeling in the IDN community that a DNS solution for IDN equivalence must treat (and consider) all versions of a label as truly equal. However this document describes a procedure that relies on one version of a label being configured in the familiar way, and the CLONE(s) configured in a way that refers to the traditionally configured label. Therefore this document will adopt the term used in the Joint Engineering Team (JET) Guidelines [RFC3743] and refer to the label configured in the typical way as the "preferred" label. While on the one hand it is easy to see how a solution that treats all versions of the label as truly equal would be desirable, this document intentionally sacrifices the goal of true equality in the Barton Expires September 8, 2011 [Page 4] Internet-Draft Cloning DNS Labels March 2011 interest of providing a solution that can get the maximum possible benefit available to the largest number of end users while requiring only that the authoritative name servers are upgraded. It will ultimately be up to the community to decide whether this is a sacrifice worth making. The terms "authoritative name server" and "resolving name server" are used with their commonly understood meanings. A CLONE-Aware Resolving Name Server will hereinafter be referred to as a CARNS. 1.2. CLONE Overview There are two sides of the CLONE method, the authoritative and resolving name servers. For clients that are not aware of the CLONE RR the authoritative server will simply respond "as if" the query for a CLONE label had actually been for the preferred name. When a CARNS queries the authoritative server it will send an EDNS [RFC2671] option that indicates that it is CLONE-Aware. The authoritative server will then add the CLONE Resource Record (RR) to the ANSWER section, which will include the preferred label. From then on when queries come into the CARNS for the CLONE it can in turn query the authoritative server for the preferred label, and respond to its querier "as if" the query had been for the preferred label. In this way if the preferred label is signed with DNSSEC [RFC4035] a CARNS can perform DNSSEC validation on the response. This method also makes it possible to have CLONEs for more than one label in a given hostname. The CLONES RR is intended to aid application developers by making it easier to know when a given label has one or more other labels that are configured as part of the same "bundle." 2. The Authoritative Name Server 2.1. Parent Zone File At any level of the DNS tree above the root itself a label MAY be specified as a CLONE. For example: clone1 CLONE preferred In this example "preferred" would be the preferred label, "clone1" would be the CLONE. Multiple CLONES MAY be defined for the same preferred label. The RDATA for the CLONE RR MUST be either a valid DNS label, or a valid hostname that is also served by the same authoritative name server. Compliant authoritative server Barton Expires September 8, 2011 [Page 5] Internet-Draft Cloning DNS Labels March 2011 implementations MUST generate a user error when attempting to load a zone that contains a CLONE RR with RDATA that is not served by that authoritative name server. The CLONE label MUST NOT have any other data associated with it. Compliant authoritative server implementations MUST generate a user error when attempting to load a zone that contains both a CLONE and other RDATA for the same label. The CLONES RR is used to list the preferred label and all of its CLONES. It MUST NOT be defined in the zone file. Compliant implementations MUST generate a user error when attempting to load a zone that contains a CLONES RR. 2.2. Child Authoritative Server Configuration If the preferred label is a delegation point, and the delegee wishes to answer for the CLONE label(s), the authoritative name server for the zone with the preferred label MUST be configured for the CLONE(s). An example that uses a BIND-style syntax follows, but this document is not attempting to specify how implementors perform this configuration. zone "clone1.example.org" { clone preferred.example.org; }; Behavior of child authoritative servers which configure real zones for labels that the parent created as CLONEs of a preferred label is undefined. 2.3. Query Response For CLONE Labels When a compliant authoritative name server implementation receives a query for a label or zone that is a CLONE, the server MUST respond "as if" it had received the query for the preferred label. In the example above if the name server receives any query for clone1.example.org other than the CLONE or CLONES RRs it MUST respond "as if" the query had been for preferred.example.org. If the authoritative name server receives the CLONE-Aware EDNS option it MUST add the CLONE RR to the ANSWER section of the query response with the preferred label as the RDATA. If a compliant server does not receive the CLONE-Aware EDNS option it MUST NOT return DNSSEC-related records (such as RRSIG) along with the response, regardless of whether the DO bit was set in the query. Barton Expires September 8, 2011 [Page 6] Internet-Draft Cloning DNS Labels March 2011 2.4. Query Response For CLONE And CLONES Resource Records When a compliant authoritative name server receives a query for the CLONE RR with a label that is a CLONE as the QDATA it MUST return an ANSWER with the preferred label as the RDATA. When a compliant server receives a CLONE query for a label that is not a CLONE it MUST return RCODE 0 (No error). When a compliant server receives a query for the CLONES RR with a label that is a CLONE or a preferred label as the QDATA it MUST return an ANSWER with the preferred label listed first in the RDATA, followed by all of labels that are configured as a CLONE of the preferred label. If the label in the QDATA is neither a preferred label or a CLONE the server MUST return RCODE 0 (No error). 3. The CLONE-Aware Resolving Name Server When sending queries a compliant CARNS MUST send the EDNS option for CLONE-Aware. When a compliant CARNS receives a query response which contains a CLONE RR as described in Section 2.3 it MUST "transform" future queries for hostnames or labels which it knows contain CLONE labels to the preferred version(s). However regardless of whether the CARNS knows that a hostname it is queried for contains a CLONE label or not, the response to its client MUST be for the same QDATA it was queried for. 3.1. CARNS DNSSEC Behavior For "Typical" Queries When a CARNS receives a response to a query that originally contained one or more CLONE labels that is signed with DNSSEC it MAY indicate that the response is authentic by setting the AD bit if all other conditions for setting it are otherwise met (i.e., the DO bit was set in the query originally received by the CARNS, etc.). Local policy SHALL be the determining factor for whether to set the AD bit in the query response for the hostname which contains one or more CLONE labels if it were otherwise appropriate to do so. 3.2. CARNS Behavior for DNSSEC Resource Record Queries When a CARNS receives a direct query for a DNSSEC-related RR for a hostname that contains one or more CLONE labels (e.g., RRSIG, DNSKEY, etc.) it MUST return RCODE 0 (No answer) and include the CLONE RR with the preferred label as RDATA in the ADDITIONAL section of the response Barton Expires September 8, 2011 [Page 7] Internet-Draft Cloning DNS Labels March 2011 4. Examples Assuming a zone example.org with the following records: preferred A 192.0.2.1 clone1 CLONE preferred clone2 CLONE preferred 4.1. Non-CARNS +---+ +-----------+ +---+ | S | clone1.example.org A | | clone1.example.org A | A | | t |--------------------->| Non-CARNS |--------------------->| u | | u | | | | t | | b | 192.0.2.1 | | 192.0.2.1 | h | | |<---------------------| |<---------------------| | +---+ +-----------+ +---+ 4.2. CARNS - First Query For CLONE +---+ +---+ +---+ | | | | clone1.example.org A | | | S | clone1.example.org A | C | CLONE-Aware ENDS Opt | A | | t |--------------------->| A |---------------------------->| u | | u | | R | | t | | b | | N | 192.0.2.1 | h | | | 192.0.2.1 | S | CLONE RR clone1 > preferred | | | |<---------------------| |<----------------------------| | +---+ +---+ +---+ 4.3. CARNS - Second Query For CLONE +---+ +---+ +---+ | | | C | preferred.example.org A | | | S | clone1.example.org A | A | CLONE-Aware ENDS Opt | A | | t |--------------------->| R |---------------------------->| u | | u | | N | | t | | b | 192.0.2.1 | S | 192.0.2.1 | h | | |<---------------------| |<----------------------------| | +---+ +---+ +---+ 4.4. CLONES Response Barton Expires September 8, 2011 [Page 8] Internet-Draft Cloning DNS Labels March 2011 +---+ +---+ | C | | | | A | clone1.example.org CLONES | A | | R |------------------------------------------------------------>| u | | N | | t | | S | preferred.example.org clone1.example.org clone2.example.org | h | | |<------------------------------------------------------------| | +---+ +---+ 5. IANA Considerations This document requests that the IANA assign the Resource Record (RR) Type Codes [RFC1035], [I-D.ietf-dnsext-5395bis] 77 and 88 to the CLONE and CLONES RRs, respectively; and the EDNS0 Option [RFC2671] 11 for CLONE-Aware. 6. Security Considerations There are currently (at least) two widely used solutions to the equivalence problem at the zone level. For both of these solutions the preferred label and all of the variations need to be delegated, usually to the same set of name servers. The obvious, albeit potentially the most difficult method of keeping the zones "the same" is to create multiple zone files that contain records that are identical to the extent possible. This solution allows for the possibility of having DNSKEY records for each zone, thereby allowing each zone to be signed. The other solution that takes advantage of identical delegation is to use the exact same zone file for multiple zones. This method provides the same capability for DNSSEC compatibility as the CLONE method. The preferred label can be signed, but validation would fail for the other labels since the DNSKEY record would not be for that zone. For parents (such as TLD registries) that allow the delegee/ registrant to choose what method of "bundling" semantically similar labels to use, the techniques described in this document do not reduce security in any way. The delegee can either decide as a matter of local policy that the DNSSEC capability of the CLONE technique is sufficient, or they can choose to have the non-preferred versions of the label delegated and maintain separate zone files. In a context where the delegee is forced to accept the CLONE option DNSSEC validation for the non-preferred versions of the label will be limited to resolving name servers that are CLONE-Aware. No negative security implications for the CLONE or CLONES RRs themselves are known. It is envisioned that in certain contexts Barton Expires September 8, 2011 [Page 9] Internet-Draft Cloning DNS Labels March 2011 being able to verify that the non-preferred versions of a label have been listed as CLONEs rather than using some other method of "aliasing" (such as delegation, CNAME, etc.) could be beneficial. 7. References 7.1. Normative References [I-D.ietf-dnsext-5395bis] 3rd, D., "Domain Name System (DNS) IANA Considerations", draft-ietf-dnsext-5395bis-03 (work in progress), January 2011. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999. [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672, August 1999. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005. [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010. 7.2. Informative References [I-D.ietf-dnsext-aliasing-requirements] Woolf, S. and X. Lee, "Problem Statement: DNS Resolution of Aliased Names", draft-ietf-dnsext-aliasing-requirements-00 (work in progress), February 2011. [RFC3743] Konishi, K., Huang, K., Qian, H., and Y. Ko, "Joint Engineering Team (JET) Guidelines for Internationalized Domain Names (IDN) Registration and Administration for Chinese, Japanese, and Korean", RFC 3743, April 2004. Barton Expires September 8, 2011 [Page 10] Internet-Draft Cloning DNS Labels March 2011 Author's Address Douglas Barton (editor) GridFury, LLC 11901 Santa Monica Boulevard, Unit 612 Los Angeles, CA 90025 USA Email: dougb@dougbarton.us Barton Expires September 8, 2011 [Page 11]