Network Working Group O. Kolkman Internet-Draft NLnet Labs Intended status: Experimental Protocol A. Sullivan Expires: March 22, 2014 Dyn, Inc. W. Kumari Google, Inc. September 20, 2013 Using Test Delegations from the Root Prior to Full Allocation and Delegation draft-kolkman-root-test-delegation-00 Abstract The delegation of certain strings as TLDs will cause stability and security issues if such strings have been used in private environments prior to their delegation. It is recommended that test delegations be used to enable empirical research on the extent of the possible disruption prior to actual allocation and delegation of any label in the root zone. 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 March 22, 2014. Copyright Notice Copyright (c) 2013 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 Kolkman, Sullivan & KumarExpires March 22, 2014 [Page 1] Internet-Draft Test Delegations From the Root September 2013 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. Table of Contents 1. Introduction and Motivation . . . . . . . . . . . . . . . . . 2 1.1. Search-path interaction. . . . . . . . . . . . . . . . . . 3 1.2. Scire est mensurare . . . . . . . . . . . . . . . . . . . 4 2. Terms and Conventions Used in this Memo . . . . . . . . . . . 4 3. Principle of Operation . . . . . . . . . . . . . . . . . . . . 4 3.1. Measurements Servers and Zones . . . . . . . . . . . . . . 5 3.2. Query Generation . . . . . . . . . . . . . . . . . . . . . 5 3.3. Sampling . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.4. The Name Server . . . . . . . . . . . . . . . . . . . . . 7 4. Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. A Basis for Acceptable Behaviour . . . . . . . . . . . . . . . 9 6. Possible Experiment Extension . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction and Motivation [[The authors are aware that this first version of the document does is not fully consistent. However they would value feedback on whether the idea is worth further pursuance.]] [Editor not: An appropriate mailinglist for discussion of this draft has not yet been identified] DNS names have always co-existed with other namespaces that are virtually indistinguishable from the DNS. The DNS was itself deployed alongside the host [RFC0822] table. NetBIOS [NETBIOS] names, though only one label long, could always interact with the DNS search path mechanism to generate DNS names. Additionally, mDNS [RFC6762] names often look just like DNS names. Because different naming systems are usually linked together in the user interface, from an end user's point of view these name spaces are all one -- even though they function differently on the Internet. While [RFC6761] reserved certain special names for internal or private use, there is evidence [SAC45] that various sites connected to the Internet have used other names for internal purposes. In fact, [RFC6762] advises not to use .local for private use and observes: "the following top-level domains have been used on private internal networks without the problems caused by trying to reuse ".local." for this purpose:" Kolkman, Sullivan & KumarExpires March 22, 2014 [Page 2] Internet-Draft Test Delegations From the Root September 2013 .intranet. .internal. .private. .corp. .home. .lan. In the event such names are delegated for use in the public DNS, there will be inevitable consequences for sites that have used those names. Some of those consequences have implications for security, with the potential for leakage of credentials and HTTP cookies ([RFC6265]). Responsible administration of the public namespace therefore requires great care in permitting public delegation of any name when there is good reason to suppose it is in widespread use as a private namespace, even though such private namespaces are (from the point of view of the DNS) irregular, even if common. 1.1. Search-path interaction. In many cases a string appears to be used as an "undelegated TLD" (being used as the rightmost label in an name), but this is simply an artifact of domain search list processing. For example, suppose the Example Widgets corporation uses a sub- domain (.corp) of their primary domain (example.com) to name their employee workstations, servers, printers and similar. They have an "intranet" server named intranet.corp.example.com. In order to allow their employees to simply type "intranet.corp" to access this server, the users' workstations are configured (probably using [RFC3379]) with the search-list set to "corp.example.com, example.com". When a user enters "intranet.corp", their workstation will try and resolve the name. RFC1535 [RFC1535] specifies that "in any event where a "." exists in a specified name it should be assumed to be a fully qualified domain name (FQDN) and SHOULD be tried as a rooted name first." So, the user's workstation will first try and resolve "intranet.corp.". As there is (currently) no .corp TLD this will result in an NXDOMAIN response. The workstation will then append entries in the search-list until it is able to resolve the (now fully-qualified) name. If the .corp label were to be delegated as a TLD and the sub-domain "intranet" created within .corp, the first lookup ("intranet.corp") would no longer generate an NXDOMAIN response. This would stop the Kolkman, Sullivan & KumarExpires March 22, 2014 [Page 3] Internet-Draft Test Delegations From the Root September 2013 search-list processing, and direct the user somewhere other than where the user intended to go -- the "wrong server", in the eyes of the user, even if right according to the DNS. It is worth noting that a researcher analyzing DNS queries hitting the root servers would see queries before search-list processing expands them. While this may not change whether or not it is safe to delegate these names, having an understanding of the cause is valuable. 1.2. Scire est mensurare The local use of undelegated top-level domain names is troublesome because it produces different experience depending on the search path and location of a given device. That is a normal effect of the search path mechanism or the roaming of users, but with the advent of new generic top-level domains (gTLDs), the problem gets more acute, because many TLDs are intended to be mnemonics that will be intuitive to humans. Since names higher in the DNS tree are likely also to use those same intuitive labels, there is potential for user confusion and information leakage. At the same time, it is not clear that the DNS protocol was designed around a static list of top-level domains (TLDs), and therefore it seems reasonable to plan for the possible addition of new TLDs whose use might conflict with deployed search path settings. Yet prudent operation of the root zone requires that deployment of new names in the root should not cause widespread untoward effects for users of the DNS, particularly when those users are relying on features that have always been part of the protocol. What is needed is a mechanism to test whether a particular delegation from the root zone presents a serious conflict with widespread use. This memo presents a methodology for making such a determination. The methodology depends on temporary delegation of the top-level domains in question, and the use of a domain under an existing TLD in order to capture and compare queries generated by a large number of querying sources under the control of the experiment. 2. Terms and Conventions Used in this Memo The mechanism outlined here is intended to complement the analysis already performed in "Name Collision in the DNS" [namecollision]. We therefore use the terms defined in section 1.1 of [namecollision] whenever appropriate. Note that the evaluation methodology outlined here is intended to be complementary input to a risk analysis e.g. as found in [namecollision]; risk tradeofs are likely to include other factors than the effects measured herewith. 3. Principle of Operation Kolkman, Sullivan & KumarExpires March 22, 2014 [Page 4] Internet-Draft Test Delegations From the Root September 2013 In order to assess whether there is significant use of a given candidate string (CandidateTLD), probes will send out sets of queries from a large number of random locations. The queries are answered by dedicated servers that collect statistics. In this section we describe the query generation, data-collection, and what the dedicated servers should answer to not interfere with Internet traffic. The goal of the experiment is to assess whether there is significant existing use of a single CandidateTLD. 3.1. Measurements Servers and Zones In addition to the candidate string ("CandidateTLD") the methodology uses a specific sting "TestName". During an experiment the Proposed TLD under evaluation ("CandidateTLD") and a control TLD ("TestName") are delegated from the root zone to a special DNS name server, the experiment's server. Further, a second control name (TestName.ExistingTLD) is delegated from a 'common' existing TLD (ExistingTLD) to the experiment's server. The experiment's server has two functions: First, with one exception detailed below in Section 3.4, if any request for any name inside the CandidateTLD or the TestName namespace reaches the name server, the name server MUST respond with RCODE 3 (Name Error or NXDOMAIN) (Note that from a DNS client perspective the ultimate RCODE 3 response is indistinguishable from what is returned without the test delegation in place.) Second, the experiment's server tracks every name in any request it receives, the time at which the request arrived, the RRTYPE and CLASS in the request, and the source network for the request. 3.2. Query Generation Software probes will need to be deployed throughout the Internet (also see Section 3.3) these probes will send, in parallel, sets of queries. Each set comprises one measurement and consists of three queries (or even 4, see Section 6). A measurement is identified by a unique measurement identifier (, syntactically a valid hostname); the set will include the following: the QNAME is -a.TestName. the QNAME is -b.TestName.CandidateTLD Kolkman, Sullivan & KumarExpires March 22, 2014 [Page 5] Internet-Draft Test Delegations From the Root September 2013 the QNAME is -c.TestName.ExistingTLD The TestName MUST be a randomly chosen name that remains constant for the duration of the experiment, MUST be a syntactically valid label, SHOULD be semantic nonsense, an MUST NOT be delegated from the root or in the ExistingTLD already. Depending on the environment in which the probe is located the query that is send by a stub resolver is handled differently. We distinguish 4 possibilities. Local CandidateTLD use without Search List: The probe is located within a network that locally resolves the candidateTLD and there are no searchlists being used that append CandidateTLD. The query with a QNAME of -b.TestName.CandidateTLD will not exit the local network while the queries with a QNAME of -c.TestName.ExistingTLD. and QNAME of -a.TestName. will arrive at the authoritative servers for the respective domains. Local CandidateTLD and CandidateTLD appened Search List: The probe is located within a network that locally resolves the candidateTLD and there are searchlists being used that append CandidateTLD. The query with a QNAME of -b.TestName.CandidateTLD will not exit the local network while the queries with a QNAME of lt;uniqueid>-c.TestName.ExistingTLD. will arrive at the authoritative server for the domain. The query with a QNAME of -a.TestName. is subject to the search algortithm, the query name will effectively be substitude to -a.TestName.CandidateTLD and be resolved localy. The query for -a.TestName. will therefore not be seen at the authoritative server. No use of CandidateTLD and no use of Search List: The probe is located within a network that does not resolve the candidate TLD and no searchlists being used that append CandidateTLD. All queries will arrive at the authoritative servers for the respective domains. No use of CandidateTLD and CandidateTLD appended by Search List: The probe is located within a network that does not resolve the candidate TLD but search list processing appends CandidateTLD. In this case the queries for Lt;uniqueid>-a.TestName. get rewritten to lt;uniqueid>-a.TestName.CandidateTLD and arrive, together with lt;uniqueid>-b.TestName.CandidateTLD at the authoritative server for CandidateTLD, while queries for the QNAME -c.TestName.ExistingTLD arrive at the server authoritative for TestName.ExistingTLD. As a result, by comparing what arrives at the authoritative servers one can establish the prevalence of the various scenarios. Under the Kolkman, Sullivan & KumarExpires March 22, 2014 [Page 6] Internet-Draft Test Delegations From the Root September 2013 assumption of a broad unbiased sample exclusively observing the 3rd option (all queries hitting their respective servers) would be a strong indication that a candidate TLD is not in use. 3.3. Sampling To perform the evaluation, a names of the form .TestName.CandidateTLD and .controlname.ExistingTLD are embedded in content that is placed around the web. As people visit web sites, the content is processed, yielding attempts at resolution of the names. The easiest way to provide the content that causes the relevant DNS lookup is to use an online (ad) campaign. There is no reason for the campaign actually to cause users to click though, so it should be as boring as possible. However, the campaign must result in the independent resolution of both the control and test names. Behavior of this sort is trivially achievable with several available online advertising systems. It is critical that the sampling be as representative of the Internet population as possible. This sort of sample already has the significant problem that it can only measure users of the web. And there may be sampling effects that might prevent measurements from taking place in those environments that need to be reached. For instance, add-blocking or different web surfing behavior in corporate environements. The measurements should be unbiased with respect to temporal behavior like sleep-wake and work-rest cycles. [[The sampling biases probably deserve their own section with much more elaboration and more possible biases]] 3.4. The Name Server This procedure rests on a name server that is configured and instrumented in particular ways. First, the name server must be configurable so that it authoritative for all requests inside the Candidate TLD. Normally, it will always return RCODE 3 (NXDOMAIN) for all queries inside that Candidate TLD, except that the name server must also be configurable so that it is the authoritative name server for the test name. All names underneath the test name, however, also return RCODE 3. A summary of the behavior is in Table 1. Kolkman, Sullivan & KumarExpires March 22, 2014 [Page 7] Internet-Draft Test Delegations From the Root September 2013 +-----------------------------+------------+-----------+------------+ | Domain Name | RRTYPE | RCODE | Actions if | | | queried | returned | any | +-----------------------------+------------+-----------+------------+ | CandidateTLD | anything | 3 | | | | except NS | | | | CandidateTLD | NS | 0 | return | | | | | server in | | | | | answer | | | | | section | | | | | RDATA | | TestName | anything | 3 | | | | except NS | | | | TestName | NS | 0 | return | | | | | server in | | | | | answer | | | | | section | | | | | RDATA | | TestName.CandidateTLD | NS | 0 | return | | | | | server in | | | | | answer | | | | | section | | | | | RDATA | | TestName.CandidateTLD | anything | 3 | | | | except NS | | | | *.TestName.CandidateTLD | ANY | 3 | Queries to | | | | | be | | | | | measured | | *.controlname.ExistingTLD | ANY | 3 | Queries to | | | | | be | | | | | measured | | *.TestName | ANY | 3 | Queries to | | | | | be | | | | | measured | +-----------------------------+------------+-----------+------------+ 4. Evaluation [TODO align with above] To evaluate the results, it is only necessary to compare the number of resolution attempts of the test names against the resolution attempts of the control names. If the test name is not in wide private use, then a lookups for the name unique identifier in each name space will arrive nearly as often and at the same time (modulo the difference in the recursive nameserver following the delegation chain) at the instrumented name server. Kolkman, Sullivan & KumarExpires March 22, 2014 [Page 8] Internet-Draft Test Delegations From the Root September 2013 If the test name is in widespread private use without a search list, or is otherwise resolved locally, then we should expect that lookups inside the test namespace will happen less often than lookups inside the control namespace. If there is no search list in use, then the test QNAMEs of the "b" form will arrive less often than those of "a" form and "c" form. If there is a search list in use, then the "a" form will also not arrive at the authoritative server. If the CandidateTLD is in a search list, we can expect to see duplicated queries of the "b" form on the authoritative server (because the "a" form gets the search list appended). 5. A Basis for Acceptable Behaviour We assume that there will always be some "stray" queries to the DNS: queries for names that have a TLD-label that does not exist in the root-zone, and which were not intended to be sent to the global DNS. Therefore, it is necessary to establish some baseline level of these "noise" queries, and then use that to evaluate whether some proposed new name for the DNS presents a problem. Because of the historic prominence of the .com TLD, it may be supposed that .com is, like the root itself, a special zone in which unusual behaviour might be expected. Therefore, names inside the .com name space are a poor guide for "normal" behaviour, and it should not be used for making these sorts of evaluations. The best guide will likely come from using TLDs that are themselves statistically normal. In addition, overwhelming conservatism suggests that using comparisons with the TLD that is queried least often provides a great margin of safety. As of this writing, a string that is queried less often than that least-queried TLD seems likely not to be in widespread real use, and therefore comparisons with that least- queried TLD are a good conservative choice when evaluating. 6. Possible Experiment Extension A bias to the measurement is introduced if in certain environments lists of existing TLDs are used in access lists of, for instance, firewalls. In that case queries for the QNAME -b.TestName.CandidateTLD might be blocked. To calibrate that behavior an additional non-existent TLD could be delegated for the duration of the experiment: the QNAME is -d.TestName.RandomTLD Whereby RandomTLD is a short TLD with the same properties as the candidate TLD. e.g. if the CandidateTLD is U-Label then the RandomTLD is a U-Label from the same script. Kolkman, Sullivan & KumarExpires March 22, 2014 [Page 9] Internet-Draft Test Delegations From the Root September 2013 If the measurement servers receive queries where the QNAME is neither -d.TestName.RandomTLD nor -b.TestName.CandidateTLD then it is likely that all non- delegated domains are blocked. An alternative way of interpreting this is that the queries where the QNAME is -d.TestName.RandomTLD that arrive at the measurement servers provide a baseline for the transparency of the querying environment for non-delegated TLDs. 7. Security Considerations The delegation of the Proposed TLD (CandidateTLD) and control TLD (TestName) comes with some risk of interference with existing deployments. The risks for name collision for the TestName is under the control of the experimenter and can be minimized by taking random strings without semantic value. The risk of name collision with the CandidateTLD is minimized reduced by having the experiment's server returning RCODE=3. Under the assumption of regular DNS implementations that response is indistinguishable from a direct root-response for applications that receive such answer from a stub resolver. The authors have no reason to believe that there are DNS implementations that would hand the applications a different response if a delegation is part of the resolution process. The authors would advise against signing the various delegated domains, as the introduction of DNSSEC is likely to bias the experiment. At the root domain and ExistingTLDs, regular signing practices, including the inclusion of an NSEC or NSEC3 RR proving the non-existence of a DS record should continue. The experiment can be biased by 3rd parties through sending queries that have properties like the ones specified herein. The experimentor SHOULD carefully control and record the values used in the experiment and discard non-expected and non-unique queries that arrive at the nameserver. 8. References [NETBIOS] IBM Corporation, "LAN Technical Reference: 802.2 and NetBIOS APIs ", Doc. number SC30-3587-01, April 1996. [RFC0822] Crocker, D.H., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982. [RFC1535] Gavron, E., "A Security Problem and Proposed Correction With Widely Deployed DNS Software", RFC 1535, October 1993. [RFC3379] Pinkas, D. and R. Housley, "Delegated Path Validation and Delegated Path Discovery Protocol Requirements", RFC 3379, September 2002. Kolkman, Sullivan & KumarExpires March 22, 2014 [Page 10] Internet-Draft Test Delegations From the Root September 2013 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, April 2011. [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", RFC 6761, February 2013. [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, February 2013. [SAC45] ICANN Security and Stability Advisory Committee, "Invalid Top Level Domain Queries at the Root Level of the Domain Name System", 11 2010, . [namecollision] Interisle Consulting Group, "Name Collision in the DNS", August 2013. Appendix A. Acknowledgements This draft is a follow-up of, an borrows heavily from, our earlier (abbandonded) work on "A Procedure for Cautious Delegation of a DNS Names". Discussion of that document in various hallways lead to inspiration for this document and we want to thank those that gave us feed-back. The idea of using different names to trigger events in a DNS server is due to Geoff Huston. Authors' Addresses Olaf Kolkman NLnet Labs Science Park 400 Amsterdam, 1098 XH The Netherlands Email: olaf@NLnetLabs.nl Andrew Sullivan Dyn, Inc. 150 Dow St Manchester, NH 03101 U.S.A. Email: asullivan@dyn.com Kolkman, Sullivan & KumarExpires March 22, 2014 [Page 11] Internet-Draft Test Delegations From the Root September 2013 Warren Kumari Google, Inc. 1600 Amphitheatre Pkwy Mountain View, CA 94043 U.S.A. Email: warren@kumari.net Kolkman, Sullivan & KumarExpires March 22, 2014 [Page 12]