<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc6265 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6265.xml">
<!ENTITY rfc6761 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6761.xml">
<!ENTITY rfc6762 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6762.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc autobreaks="yes"?>
<rfc category="exp" docName="draft-kolkman-root-test-delegation-02" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en">
  <front>
    <title abbrev="Test Delegations From the Root">Using Test Delegations from the Root Prior to Full Allocation and Delegation</title>
    <author fullname="Geoff Huston" initials="G." surname="Huston">
      <organization>APNIC</organization>
      <address>
        <postal>
          <street>6 Cordelia St</street>
          <city>South Brisbane</city>
          <region>QLD</region>
          <code>4101</code>
          <country>Australia</country>
        </postal>
        <email>gih@apnic.net</email>
      </address>
    </author>
    <author fullname="Olaf Kolkman" initials="O." surname="Kolkman">
      <organization>NLnet Labs</organization>
      <address>
        <postal>
          <street>Science Park 400</street>
          <city>Amsterdam</city>
          <code>1098 XH</code>
          <country>The Netherlands</country>
        </postal>
        <email>olaf@NLnetLabs.nl</email>
      </address>
    </author>
    <author fullname="Andrew Sullivan" initials="A." surname="Sullivan">
      <organization>Dyn, Inc.</organization>
      <address>
        <postal>
          <street>150 Dow St</street>
          <city>Manchester</city>
          <region>NH</region>
          <code>03101</code>
          <country>U.S.A.</country>
        </postal>
        <email>asullivan@dyn.com</email>
      </address>
    </author>
    <author fullname="Warren Kumari" initials="W." surname="Kumari">
      <organization>Google, Inc.</organization>
      <address>
        <postal>
          <street>1600 Amphitheatre Pkwy</street>
          <city>Mountain View</city>
          <region>CA</region>
          <code>94043</code>
          <country>U.S.A.</country>
        </postal>
        <email>warren@kumari.net</email>
      </address>
    </author>
    <date year="2013"/>
    <abstract>
      <t>The delegation of certain strings as generic Top Level Domains (gTLDs) may cause stability and security issues if such strings have been used in private environments prior to their delegation. Test delegations can be used to enable empirical research on the extent of the potential for name collision. This document describes one such approach to an empirical testing framework for name collision, and considers the applicability of this approach to detect other forms of name collision.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="motivation" title="Introduction and Motivation" toc="default">
      <t>[[The authors are aware that this version of the document is not fully consistent. However they would value feedback on whether the idea is worth further study. A mail list to discuss this draft is collisions@lists.dns-oarc.net.]]</t>
      <t>While certain names have been reserved for internal or private use <xref target="RFC6761" pageno="false" format="default"/>, there is evidence <xref target="SAC45" pageno="false" format="default"/> that various sites connected to the Internet have used other names for internal purposes. In fact, the Multicast DNS specification <xref target="RFC6762" pageno="false" format="default"/> 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:<vspace blankLines="0"/> .intranet<vspace blankLines="0"/> .internal.<vspace blankLines="0"/> .private.<vspace blankLines="0"/> .corp.<vspace blankLines="0"/> .home.<vspace blankLines="0"/> .lan.  </t>
      <t>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 may have security implications, with the potential for leakage of credentials and HTTP cookies (<xref target="RFC6265" pageno="false" format="default"/>). Responsible administration of the public namespace therefore requires careful consideration in permitting public delegation of any name when there are grounds to believe 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.</t>
      <t>One form of name collision involves network domains that use selected names as local-use top level domains, as noted in <xref target="RFC6762" pageno="false" format="default"/>. In the case where the same label is delegated in the global DNS as a gTLD, then hosts in the local domain will be unable to resolve domain names in the context of the gTLD. This state of name occlusion is further compounded by a number of scenarios where the resolution of a name is performed across multiple name scope domains. This may happen with a mobile host (in the case, for example, when the host uses a statically defined "home page" on their local browser that is defined within a particular local scope), or even with applications, such as, for example, mail delivery (in the case where multiple MTAs who are listed as mail servers for a domain reside in different name scope domains, some of which have this name collision between the domain and locally defined pseudo-TLDs).</t>
      <t>Name collision opens up the potential for misdirection, where the named remote point being contacted by the application may not necessarily be the intended service point for the transaction. When a host leaves the intranet environment, the host's applications may anticipate that the DNS names associated with a label return an RCODE 3 (NXDOMAIN) response, but may encounter an unanticipated response when the gTLD is deployed with a colliding name. Similarly, a host that has an association with a named service point within the gTLD may encounter unanticipated responses when the host is placed into an intranet environment where the same name exist as a locally-scoped pseudo-TLD.</t>
      <t>There is a subtle form of interaction of names when the same name is placed on a local name search list. Certain name resolver libraries first query the original name, and if the query returns an NXDOMAIN, then they apply the local search list to the original name. When this process occurs in the context of a visible gTLD name colliding with the local name there is the possibility of the name resolving in the context of the gTLD, which then bypasses the application of the local search list.</t>
      <section title="Scire est mensurare" toc="default">
        <t>The local use of undelegated top-level domain names is troublesome because it may produce different user experiences depending on the locally used name, the names placed in a local search list and the location of a given host, and the host's name resolution behaviour.</t>
        <t>Prudent operation of the root zone requires that deployment of new names in the root should not necessarily cause widespread untoward effects for users of the DNS, particularly when those users are relying on name resolution outcomes that have always been part of the name resolution behaviour up unto this point.</t>
        <t>What is useful in this context is a mechanism to test whether a particular delegation from the root zone presents a conflict with widespread local use. This memo presents a methodology for making such a determination.</t>
        <t>The methodology considered here 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.</t>
      </section>
    </section>
    <section title="Terms and Conventions Used in this Memo" toc="default">
      <t>The mechanism outlined here is intended to complement the analysis already performed in "Name Collision in the DNS" <xref target="namecollision" pageno="false" format="default"/>. We therefore use the terms defined in section 1.1 of <xref target="namecollision" pageno="false" format="default"/> whenever appropriate.</t>
      <t>Note that the evaluation methodology outlined here is intended to be complementary input to a risk analysis e.g. as found in <xref target="namecollision" pageno="false" format="default"/>; risk tradeofs are likely to include other factors than the effects measured herewith. </t>
    </section>
    <section title="Principle of Operation" toc="default">
      <t>The goal of the experiment is to assess whether there is significant existing use of a given candidate string ("CandidateTLD").</t>
      <t>We propose the use of a software test that is executed by a large number of end hosts drawn from across the entire Internet. The execution of this test will cause the end host to attempt to retrieve a small set of URLs. This will trigger a set of DNS queries to resolve the domain name part of each URL, and subsequent HTTP queries to retrieve the object in the case that the DNS name is successfully resolved to an IP address. Both the DNS queries and the HTTP requests are answered by dedicated servers that analyse the received responses and match them to the original set of queries that were used by the end host. This will allow us to infer whether the lost is located in an context where there is name collision with the CandidateTLD. In this section we describe the query generation, data-collection, and analysis. </t>
      <t>This methodology is based on earlier work by APNIC <xref target="Method" pageno="false" format="default"/>.</t>
      <section title="Measurements Servers and Zones" toc="default">
        <t>In addition to the use of CandidateTLD, the methodology uses an additional name, delegated from a 'common' existing TLD, ("TestName.ExistingTLD") to the experiment's server. </t>
        <t>The experiment's name server is authoritative for CandidateTLD and TestName.ExistingTLD. The name server will respond to an A and AAAA query for any name within "TestName.CandidateTLD" with the IPV4 or IPv6 address of the experiment's HTTP server. The name server will respond to queries for any other name within CandidateTLD with RCODE 3 (Name Error or NXDOMAIN). The name server will respond to A and AAAA queries in TestName.ExistingTLD with the IPv4 or IPv6 address of the experiment's HTTP server.</t>
        <t>The experiment's HTTP server will respond with a "200 OK" for a request for the object "1x1.png" in TestName.CandidateTLD and in TestName.ExistingTLD. The server will respond with "404 Not Found" for any other object name.</t>
      </section>
      <section title="Query Generation" toc="default">
        <t>The TestName is a synthetic name with no intentional semantic meaning, that is generated in such a way to reduce the likliehood of collision with any existing delegated name. It is suggested that it be generated by using the hex encoding of a randomly selected integer value between 1,000,000,000 and 2,000,000,000. The name must not be already delegated from the root or in the ExistingTLD.</t>
        <t>Each query set constitutes one "measurement". A "measurement" is identified by a measurement identifier (&lt;uniqueid&gt;, syntactically a valid hostname) that is uniquely generated for each instance of a measurement. This ensures that when the domain name is resolved, and when the named object is retrieved there is no occlusion of the interaction with the experiment's services because of local name or web object caches. The set uses the following URLs:</t>
        <t>
          <list>
            <t>
              <list style="hanging">
                <t hangText="A:">http://&lt;unique_id&gt;-a.TestName.CandidateTLD/1x1.png?<vspace blankLines="0"/>&lt;uniqueid&gt;-a</t>
                <t hangText="B:">http://&lt;unique_id&gt;-a.TestName.ExistingTLD/1x1.png?<vspace blankLines="0"/>&lt;uniqueid&gt;-b</t>
                <t hangText="C:">http://results.TestName.ExistingTLD/1x1.png?<vspace blankLines="0"/>&lt;uniqueid&gt;?za=&lt;a_result&gt;&amp;zb=&lt;b_result&gt;</t>
              </list>
            </t>
          </list>
        </t>
        <t>The A URL is intended to test if CandidateTLD is a locally used name. In other words, if local use of CandidateTLD occludes visibility of CandidateTLD as a gTLD. The DNS query for the A Fully Qualified Domain Name (FQDN) will only be received by the authoritative name server for this name if there is no local name resolution function that uses the CandidateTLD name as a locally defined pseudo-top level domain.</t>
        <t>The B URL is intended to function as the control test for the experiment, and the use of ExistingTLD in B is intended to operate as a name that does not collide with a local use context.</t>
        <t>As the experiment uses the absence of a fetch of the A URL to infer the name resolution behaviour of the location where the measurement is being performed, it is necessary to ensure that the measurement code has run to completion. The measurement code starts a timer at the start of its execution. Upon expiration of the timer, or when both the A and B objects have been successfully retrieved, the code will schedule the retrieval of the C URL. The arguments to the C URL include the client-side measurement of the elapsed time to retrieve the A and B URLs.</t>
      </section>
      <section anchor="Sampling" title="Sampling" toc="default">
        <t>One way to perform this measurement is to embed the measurement in web content, using a scripting language. When the web content is loaded the script is activated, and the measurement sequence is performed.</t>
        <t>One way to distribute this content to clients to perform the test is via an online (ad) campaign. If the measurement script is enclosed within the ad itself, then there is no reason for the campaign actually to cause users to click though in order to perform the test. Behavior of this sort is trivially achievable with a number of available online advertising systems.</t>
        <t>It is also necessary to spread the delivery of the ad to a very broad spectrum of clients, uso the as should be presented across all time zones, across all language bases, and across all geographic regions. </t>
      </section>
    </section>
    <section title="Evaluation" toc="default">
      <t>To evaluate the results, we take those measurements that return the C URL. The use of the C URL ensures that we use measurement results where the ExistingTLD name is not being locally occluded. We count the number of experiments of each of the possible combinations of retrieving the A and B URLs. These combinations are:</t>
      <t>
        <list>
          <t>
            <list style="hanging">
              <t hangText="Not A and Not B:">This result contributes to experimental uncertainty. (We know that ExistingTLD is not locally occluded, so the failure to retrieve B is due to other factors that are not being examined in the context of this measurement.)</t>
              <t hangText="A and Not B:">This result indicates that the client is able to resolve names in the CandidateTLD in the context of the global DNS, but the inability to retrieve the B URL contributes to experimental uncertainty. (The same reasoning about the ExistingTLD and local occlusion applies to this case).</t>
              <t hangText="Not A and B:">This result is an indicator that the client's use of CandidateTLD is probably being occluded by some form of local use.</t>
              <t hangText="A and B:">This result indicates that the client is able to resolve names in the CandidateTLD in the context of the global DNS.</t>
            </list>
          </t>
        </list>
      </t>
      <t>If the CandidateTLD is in widespread private use then we would see the count of "Not A and B" be far in excess of the level of experimental uncertainty, then we can conclude that there are locales where the CandidateTLD is being used in local context. Analysis of the source IP addresses of the clients that fetch "Not A and B", and the BGP Origin AS of these addresses and their geolocation may indicate if such local use is clustered in a particular network or group or networks, or clustered in a particular geography or language region.</t>
    </section>
    <section title="Name Resolution Considerations" toc="default">
      <t>Eariler versions of this memo proposed to use this experimental technique to detect name search list considerations. This section describes the name search list collision considerations, and describes some further investigation that has lead to the conclusion that this technique would not necessarily be applicable in that context.</t>
      <t>The basic algorithm used in name resolution when search lists are present appears to be consistent across a number of implementations: various permutations of using the base name and appending individual values from the name search list are used as DNS queries in order to find a name that can be resolved by the local DNS resolver. The search process stops when the DNS query returns other than an NXDOMAIN response.</t>
      <t>However the exact order of generating these candidate names has been observerd to vary across implementations. To describe these observations it is first necessary to introduce some basic terminology.  There are four generic ways that name resolution libraries apply a search list to a "base name" in order to construct a set of FQDN that are used in DNS queries: <list><t><list style="hanging"><t hangText="none">the search list is not applied to the base name.</t><t hangText="pre">the search list is applied to the base name, then the base name alone is used.</t><t hangText="post">the base name alone is used, then the search list is applied to the base name.</t><t hangText="always">the search list is applied to the base name, and the base name alone is not used.</t></list></t></list></t>
      <t>The form of name collision with search lists, as discribed in the introduction section of this memo, occurs in the "post" case, where the unexpected resolution of the base name causes the search list not to be applied to the base name, and the global name context is applied to the base name, rather applying a local name context, as defined by the search list.</t>
      <t>Table 1 provides a summary of the behaviour of various operating systems and their local name resolver library behaviour when resolving base names that contain a single label, and names that contain two labels. As can be seen, only Windows XP and Unix-based libraries perform the "post" form of search name application that would be susceptable for this form of name collision.</t>
      <texttable anchor="table_1" title="Search List Application in Operating System Name Resolution Libraries" suppress-title="false" align="center" style="full">
        <ttcol align="left">System</ttcol>
        <ttcol align="center">Single Label</ttcol>
        <ttcol align="center">Multi-Label</ttcol>
        <c>MAC OSX 10.9</c>
        <c>always</c>
        <c>never</c>
        <c>Windows XP</c>
        <c>always</c>
        <c>post</c>
        <c>Windows Vista</c>
        <c>always</c>
        <c>never</c>
        <c>Windows 7</c>
        <c>always</c>
        <c>never</c>
        <c>Windows 8.1</c>
        <c>always</c>
        <c>never</c>
        <c>FreeBSD 9.1</c>
        <c>pre</c>
        <c>post</c>
        <c>Ubuntu 13.04</c>
        <c>pre</c>
        <c>post</c>
      </texttable>
      <t>The experimental approach described here does not necessarily use the operating system's name resolution libraries. The experimental technique forms a name query within the browser, so it is more relevant to examine the behaviour of the browsers when given single and multi-label names to lookup. Table 2 shows the behaviour of a number of browsers on two operating system platforms. (It should be noted that these results in Table 2 were obtained by using Javascript to feed names to the browser. The interactive data entry procedures in current browsers are a dual purpose URL and search engine term data entry, and the variations on behaviour between browsers in the way in which entered data is interpreted is more due to the differences in the browser's input parser than it is due to any differences in the browser's name resolution library.)</t>
      <texttable anchor="table_2" title="Search List Application in Browser Name Resolution Libraries" suppress-title="false" align="center" style="full">
        <ttcol align="left">System</ttcol>
        <ttcol align="center">Single Label</ttcol>
        <ttcol align="center">Multi-Label</ttcol>
        <c>MacOS OSX 10.9</c>
        <c></c>
        <c></c>
        <c>Chrome (31.0.1650.39)</c>
        <c>always</c>
        <c>post</c>
        <c>Opera (12.16)</c>
        <c>always</c>
        <c>never</c>
        <c>Firefox (25.0)</c>
        <c>always</c>
        <c>never</c>
        <c>Safari (7.0 9537.71)</c>
        <c>always</c>
        <c>never</c>
        <c></c>
        <c></c>
        <c></c>
        <c>Windows 8.1</c>
        <c></c>
        <c></c>
        <c>Chrome (30.0.1599.101)</c>
        <c>always</c>
        <c>never</c>
        <c>Opera (17.0)</c>
        <c>always</c>
        <c>never</c>
        <c>Firefox (25.0)</c>
        <c>always</c>
        <c>never</c>
        <c>Safari (5.1.7 7534.57.2)</c>
        <c>always</c>
        <c>never</c>
        <c>Explorer (11.0.900.16384)</c>
        <c>always</c>
        <c>never</c>
      </texttable>
      <t>Only one browser / Operating System combination tested shows the "post" form of search name use, namely Chrome on the Mac OSX platform. In all other cases a single label name always has the local search list appended, and a multi-label name never applies the local search list.</t>
    </section>
    <section title="Security Considerations" toc="default">
      <t>The delegation of the Proposed TLD (CandidateTLD) comes with some risk of interference with existing deployments. In the case where a local system queries a name, and that query returns a NXDOMAIN response, then local system then queries further name forms where each entry on a local name search list is appended to the original name in turn, searching for a name response that is not NXDOMAIN.  The delegation of CandidateTLD for this experiment may interfere this this behaviour.</t>
      <t>However, two observations mitigate this concern. The first is that this situation of potential collision arises in the case where the local system is querying for the CandidateTLD name as a "dotless" name (as the only delegated subdomain in the CandidateTLD zone is TestName, which is intended to have no semantic meaning in any language). The second observation is that for such "dotless" names, the currently widely deployed name resolver libraries no not initially query the "dotless" domain name then apply the search list is the first query results in an RCODE 3 response. Many name resolver libraries do not query for "dotless" domain names at all, while those libraries that have been observed to perform such queries (Windows XP, Linux, FreeBSD) perform them after using the local search name list, rather then before.</t>
    </section>
  </middle>
  <back>
    <references title="Informative References"><reference anchor="RFC6265"><front><title>HTTP State Management Mechanism</title><author initials="A." surname="Barth" fullname="A. Barth"><organization/></author><date year="2011" month="April"/><abstract><t>This document defines the HTTP Cookie and Set-Cookie header fields.  These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol.  Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet.  This document obsoletes RFC 2965. [STANDARDS-TRACK]</t></abstract></front><seriesInfo name="RFC" value="6265"/><format type="TXT" octets="79724" target="http://www.rfc-editor.org/rfc/rfc6265.txt"/></reference> <reference anchor="RFC6761"><front><title>Special-Use Domain Names</title><author initials="S." surname="Cheshire" fullname="S. Cheshire"><organization/></author><author initials="M." surname="Krochmal" fullname="M. Krochmal"><organization/></author><date year="2013" month="February"/><abstract><t>This document describes what it means to say that a Domain Name (DNS name) is reserved for special use, when reserving such a name is appropriate, and the procedure for doing so.  It establishes an IANA registry for such domain names, and seeds it with entries for some of the already established special domain names.</t></abstract></front><seriesInfo name="RFC" value="6761"/><format type="TXT" octets="28862" target="http://www.rfc-editor.org/rfc/rfc6761.txt"/></reference> <reference anchor="RFC6762"><front><title>Multicast DNS</title><author initials="S." surname="Cheshire" fullname="S. Cheshire"><organization/></author><author initials="M." surname="Krochmal" fullname="M. Krochmal"><organization/></author><date year="2013" month="February"/><abstract><t>As networked devices become smaller, more portable, and more ubiquitous, the ability to operate with less configured infrastructure is increasingly important. In particular, the ability to look up DNS resource record data types (including, but not limited to, host names) in the absence of a conventional managed DNS server is useful.&lt;/t&gt;&lt;t&gt; Multicast DNS (mDNS) provides the ability to perform DNS-like operations on the local link in the absence of any conventional Unicast DNS server. In addition, Multicast DNS designates a portion of the DNS namespace to be free for local use, without the need to pay any annual fee, and without the need to set up delegations or otherwise configure a conventional DNS server to answer for those names.&lt;/t&gt;&lt;t&gt; The primary benefits of Multicast DNS names are that (i) they require little or no administration or configuration to set them up, (ii) they work when no infrastructure is present, and (iii) they work during infrastructure failures.</t></abstract></front><seriesInfo name="RFC" value="6762"/><format type="TXT" octets="184992" target="http://www.rfc-editor.org/rfc/rfc6762.txt"/></reference> <reference anchor="SAC45" target="http://www.icann.org/en/groups/ssac/documents/sac-045-en.pdf"><front><title>Invalid Top Level Domain Queries at the Root Level of the Domain Name System</title><author><organization abbrev="SSAC">ICANN Security and Stability Advisory Committee</organization></author><date day="15" month="11" year="2010"/></front></reference><reference anchor="namecollision"><front><title>Name Collision in the DNS</title><author><organization>Interisle Consulting Group</organization></author><date day="2" month="August" year="2013"/></front><format target="" type="PDF"/></reference><reference anchor="Method"><front><title>APNIC Labs IPv6 Measurement System </title><author><organization>APNIC</organization></author><date day="30" month="May" year="2013"/></front><format type="TXT" target="http://labs.apnic.net/blabs/?p=348"/></reference></references>
    <section title="Acknowledgements" toc="default">
      <t>This draft is a follow-up of, an borrows heavily from, our earlier (abandonded) 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.</t>
      <t>The idea of using different names to trigger events in a DNS server is due to Geoff Huston and George Michaelson.</t>
      <t>The approach described here of using code embedded in ads delivered by online advertisement networks to generate a large volume of URL-based experiments performed by end users' browsers was developed by George Michaelson, Byron Ellacot and Geoff Huston.</t>
    </section>
  </back>
</rfc>
