<?xml version="1.0" encoding="UTF-8"?><?rfc linefile="1:draft-kolkman-cautious-delegation.xml"?>
<!-- automatically generated by xml2rfc v1.35dev on 2013-08-01T11:39:21Z -->
<!-- 

# $Id: draft-kolkman-cautious-delegation.xml 11 2013-08-01 11:38:07Z olaf $


# 
-->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- xml2rfc-processed-entity rfc2629 -->
]>
<rfc category="info" docName="draft-kolkman-cautious-delegation-02"
     ipr="trust200902">
  <?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 comments="yes"?>

  <?rfc inline="yes"?>

  <front>
    <title abbrev="Cautious Delegation">A Procedure for Cautious Delegation of
    a DNS Name</title>

    <author fullname="Olaf Kolkman" initials="O.M." 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 day="1" month="Aug" year="2013" />

    <abstract>
      <t>
	NOTE: The authors recognize that the statistical models that would
	inform the process are not well understood and that the
	possibilities to game the system might be unmountable. Unless
	we reach more insights on how to deal with this details this
	work is abandoned.
      </t>

      <t>Sometimes, a DNS name is known to be in use in the wild even though
      it was never properly delegated. This situation appears particularly,
      but not only, true in certain domains near the root of the tree: people
      have independently used those non-existent top-level domains as private
      namespaces. If those names are to be delegated in the public DNS,
      prudence dictates that collisions between the private uses and the
      public use be minimized. We outline a procedure to evaluate the harm of
      delegation.</t>
    </abstract>
  </front>

  <middle>
    <section title="Terminology">
      <!-- Given our audience we may need this.
 WK: I moved this up, as we use some term in the intro / background.-->

      <t><list hangIndent="6" style="hanging">
          <t hangText="NXDOMAIN:">an alternate expression for the "Name Error"
          RCODE as described in [<xref target="RFC1035"></xref> Section
          4.1.1]. The two terms are used interchangeably in this document.
          (definition from <xref target="RFC2308"></xref>)</t>
        </list></t>

      <t>In this document we will be using the terms zone, domain and
      sub-domain. When envisioning the domain namespace as a tree, with nodes
      at the places where the dots separate the labels in a domain name,
      then:</t>

      <t><list hangIndent="6" style="hanging">
          <t hangText="a 'domain'">is an entire branch. e.g. The .org domain
          is the branch of the domain name tree for which all names end in
          .org.</t>

          <t hangText="a 'sub-domain'">is a subordinate namespace of a given
          domain. e.g. all names ending in example.org are in the domain
          example.org which is a sub-domain of .org</t>

          <t hangText="a 'zone'">is a piece of the domain space that is under
          administrative control of one party. e.g. the .org zone has
          delegated the example.org domain to the example.org maintainers.</t>
        </list></t>

      <t></t>
    </section>

    <section title="Background and Introduction">
      <t>DNS names have always co-existed with other namespaces that are
      virtually indistinguishable from the DNS. The DNS was itself deployed
      alongside the host ### table. NetBIOS ### names, though only one label
      long, could always interact with the DNS search path mechanism to
      generate DNS names. Additionally, mDNS <xref target="RFC6762"></xref>
      names 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.</t>

      <t>While <xref target="RFC6761"></xref> reserved certain special names
      for internal or private use, there is evidence <xref
      target="SAC45"></xref> that various sites connected to the Internet have
      used other names for internal purposes. In fact, <xref
      target="RFC6762"></xref> 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:" <list>
          <t>.intranet.</t>

          <t>.internal.</t>

          <t>.private.</t>

          <t>.corp.</t>

          <t>.home.</t>

          <t>.lan.</t>
        </list></t>

      <t>In the event such names are delegated for use in the public DNS,
      there will be inevitable consequences for such sites. Some of those
      consequences have implications for security, with the potential for
      leakage of credentials and HTTP cookies (<xref
      target="RFC6265"></xref>). Responsible administration of the public
      namespace therefore requires great care in permitting public delegation
      of any name where 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 (although not
      uncommon).</t>

      <section title="Search-path interaction.">
        <t>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.</t>

        <t>As an (hypothetical) example, Example Widgets 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 <xref
        target="RFC3379"></xref>) with the search-list set to
        "corp.example.com, example.com".</t>

        <t>When a user enters "intranet.corp", their workstation will try and
        resolve the name. <xref target="RFC1535">RFC1535</xref> 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." and so the users 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.</t>

        <t>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
        search-list processing, and direct the user to the incorrect
        server.</t>

        <t>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.</t>
      </section>
    </section>

    <section anchor="usedet"
             title="Predelegation determination of use of a name">
      <t>It is possible for the operator of a zone authoritative for some
      domain name to tell whether a particular subordinate name has a
      widespread use outside the DNS. In order to do this, the operator of the
      zone monitors queries against the zone to learn the names for which
      there are queries, ignoring those names that actually exist i.e. those
      names the zone owner delegated or created resource records for (in the
      remainder of this document we will not make the distinction between
      entering data with a name or making a delegation; within the context of
      this document the same considerations apply). The operator then
      establishes a baseline "noise" level of queries for non-existent
      subordinate names. Any name that is queried with significantly greater
      frequency is to be treated as in widespread private use, and it should
      not be released for delegation. The rest of this section describes the
      mechanisms for such determination in detail.</t>

      <section anchor="predelmust" title="Predelegation testing is needed">
        <t>In order for this procedure to be useful, it should be undertaken
        before any subordinate names are delegated. Otherwise, it will be
        difficult to tell whether a subordinate name is being queried because
        it is already delegated or because it is in private use.</t>

        <t>At the same time, it is possible that the operator of a zone may
        wish to consider the private use of a descendant name, where some
        intermediate namespace has been delegated. In that case, it is
        necessary to ensure that the descendant name is not actually delegated
        when evaluating queries against that name.</t>
      </section>

      <section anchor="worrisomenames"
               title="Determining the names of concern">
        <!-- this is stupid confusing language right now.  Basically, though,
this is supposed to point out that if you're .example, you can make a
decision about foo.example; but if you want to enforce a contract with
the operator of already-delegated foo.example, you can do some
evaluation of bar.foo.example.  Dunno how to make this clear.-->

        <t>[ ED NOTE: This methodology needs to tested. First assessment of
        data indicates that this approach may be far to trivial ]</t>

        <t>There are two modes of operation for determining names of concern.
        The most usual is to examine names for which there is no intermediate
        delegation. This is useful in case the operator of the zone is
        deciding whether to permit delegation or addition of a particular
        name. The second, more unusual mode, is to examine subordinate names
        inside a sub-domain that has already been delegated. This mode is
        useful only as part of a regime of contract enforcement with the
        operator of the (already delegated) sub-domain. [WK Note: Are we sure
        we even want to address/suggest this second "limited delegation"
        option? If we are going to discuss it, referring to it as "limited
        delegation" or similar may help clarify. Personally I think 'tis a
        silly idea, but... There is talk of doing "test" delegations -
        basically launch a TLD / domain with a low TTL. If nothing goes "boom"
        then delegate for longer...]</t>

        <section anchor="predel" title="Mode 1: Prior to any delegation">
          <t>The procedure starts with the name of a zone, which is called the
          "starting domain". In order to determine what subordinate names may
          be problematic, the starting domain zone operator captures all the
          names it receives in queries. The operator discards as irrelevant
          any sub-domain it has already delegated in its namespace. Every
          other queried name will result in a response of Name Error, RCODE=3
          ###STD13 ("NXDOMAIN" ###Negative cache). We call the resulting list
          the "NX names". (See <xref target="params"></xref> for guidance on
          the sample size.)</t>

          <t>The operator then takes the list of NX names, and builds a
          frequency of queries for each potential delegation point (in
          practice all immediately subordinate names). The operator proceeds
          in the fully-qualified domain name ("FQDN") label by label until the
          next label past the operator's namespace (in practice, these are the
          names at which delegation will potentially take place). We call
          these the "target names". The operator counts the number of queries
          for each target name.</t>

          <t>The operator determines the mean and median number of queries
          over the set of target names. Any name that receives more queries
          than ###SIGMA -- needs xref to params### greater than the mean, or
          ###SIGMA2### greater than the median, should be regarded as in
          widespread private use on the Internet and therefore not a candidate
          for delegation.</t>

          <t>It is possible that only a portion of a namespace subordinate to
          a target name is actually in private use. It is possible to measure
          this situation simply by treating the beginning of the namespace in
          question as the starting domain, and then repeating the procedure
          above. This could be useful in order to establish baseline
          restrictions on the operator of a subordinate namespace prior to
          delegation.</t>
        </section>

        <section anchor="postdel" title="Mode 2: After delegation">
          <t>This mode is more likely to be useful if the evaluation at the
          end of the previous section has already been performed. In this
          case, some sub-domain to the operator's zone is to be evaluated for
          possible private use, where that sub domain has already been
          delegated. The zone operator operates the "parent starting zone",
          and is evaluating use inside a starting domain already operated by
          someone else. The very same mechanisms as are outlined in <xref
          target="predel"></xref> are used, but the evaluation must take into
          consideration the effects of negative TTLs ### for the starting
          domain. Because of the combining effects of multiple negative TTLs,
          it is inadvisable to attempt to perform this evaluation beyond the
          boundary of a single delegation.</t>
        </section>
      </section>
    </section>

    <section anchor="params"
             title="Parameters for operation of this procedure">
      <t>This section ought to have some words about sane parameters to use
      for the procedure.?</t>

      <section title="Median or Mean">
        <t>In this section we would like to describe some likely
        distributions. Our assumption is that incoming queries will usually
        follow some dictionary pattern. The 'everybody wants to be Mr. Black'
        [ResevoirDogs] effect is that queries are much more likely for popular
        names than for labels filled with random content. Therefore
        distributions for non-existent names will have relatively little power
        in the long tail. However, the long tail is significant in the sense
        that the names in the long tail are most likely not to exist.</t>

        <t>The exact type of distribution and the statistical parameters that
        signify it is subject for a future version of the draft.</t>
      </section>

      <section title="Discussion of Alternatives">
        <t>The above method is based on looking at names that the querying
        population perceives to exist. Alternatively one could count queries
        for a set of random name like "ao42hft3tofj4irsavc4owajhro.example".
        That type of measurement will set the baseline of _real_ non-existing
        names and set the noise level (likely zero queries within a reasonable
        timescale). However, using truly random names introduced the problem
        that any signal (e.g. a handful of queries used for probing of
        availability) will make the domain name unavailable.</t>
      </section>
    </section>

    <section title="Security considerations">
      <t>Applying this mechanism as the basis for decisions on whether or not
      to delegate domains introduces a motivation for gaming the system. The
      reception of a lot of queries for a particular domain may cause it to
      not be delegated, while the reception of many random queries (changing
      the properties of the query distribution) may cause a domain that is in
      common use to be delegated (by hiding the actual use of names in that
      domain in the noise). Careful analysis of data (for example, by studying
      root for queries, and taking into account historical trending) could, in
      case of suspicion of gaming, help to supplement decisions.</t>
    </section>

    <section title="IANA Considerations">
      <t>This document makes no requests of the IANA.</t>
    </section>
  </middle>

  <back>
    <references title="Informative References">
      <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>

      <?rfc?><?rfc linefile="1:bibxml/reference.RFC.1035"?>

<reference anchor='RFC1035'>

<front>
<title abbrev='Domain Implementation and Specification'>Domain names - implementation and specification</title>
<author initials='P.' surname='Mockapetris' fullname='P. Mockapetris'>
<organization>USC/ISI</organization>
<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country></postal>
<phone>+1 213 822 1511</phone></address></author>
<date year='1987' day='1' month='November' /></front>

<seriesInfo name='STD' value='13' />
<seriesInfo name='RFC' value='1035' />
<format type='TXT' octets='125626' target='http://www.rfc-editor.org/rfc/rfc1035.txt' />
</reference>
<?rfc linefile="405:draft-kolkman-cautious-delegation.xml"?>

      <?rfc?><?rfc linefile="1:bibxml/reference.RFC.1535"?>

<reference anchor='RFC1535'>

<front>
<title abbrev='DNS Software Enhancements'>A Security Problem and Proposed Correction With Widely Deployed DNS Software</title>
<author initials='E.' surname='Gavron' fullname='Ehud Gavron'>
<organization>ACES Research Inc.</organization>
<address>
<postal>
<street>PO Box 14546</street>
<city>Tucson</city>
<region>AZ</region>
<code>85711</code>
<country>US</country></postal>
<phone>+1 602 743 9841</phone>
<email>gavron@aces.com</email></address></author>
<date year='1993' month='October' />
<abstract>
<t>This document discusses a flaw in some of the currently distributed name resolver clients.  The flaw exposes a security weakness related to the search heuristic invoked by these same resolvers when users provide a partial domain name, and which is easy to exploit (although not by the masses).  This document points out the flaw, a case in point, and a solution.</t></abstract></front>

<seriesInfo name='RFC' value='1535' />
<format type='TXT' octets='9722' target='http://www.rfc-editor.org/rfc/rfc1535.txt' />
</reference>
<?rfc linefile="407:draft-kolkman-cautious-delegation.xml"?>

      <?rfc?><?rfc linefile="1:bibxml/reference.RFC.2308"?>

<reference anchor='RFC2308'>

<front>
<title abbrev='DNS NCACHE'>Negative Caching of DNS Queries (DNS NCACHE)</title>
<author initials='M.' surname='Andrews' fullname='Mark Andrews'>
<organization>CSIRO - Mathematical and Information Sciences</organization>
<address>
<postal>
<street>Locked Bag 17</street>
<street>North Ryde NSW 2113</street>
<country>AUSTRALIA</country></postal>
<phone>+61 2 9325 3148</phone>
<email>Mark.Andrews@cmis.csiro.au</email></address></author>
<date year='1998' month='March' />
<area>Applications</area>
<keyword>domain name system</keyword>
<keyword>DNS</keyword>
<abstract>
<t>

   [RFC1034] provided a description of how to cache negative responses.

   It however had a fundamental flaw in that it did not allow a name

   server to hand out those cached responses to other resolvers, thereby

   greatly reducing the effect of the caching.  This document addresses

   issues raise in the light of experience and replaces [RFC1034 Section

   4.3.4].
</t>
<t>



   Negative caching was an optional part of the DNS specification and

   deals with the caching of the non-existence of an RRset [RFC2181] or

   domain name.

</t>
<t>


   Negative caching is useful as it reduces the response time for

   negative answers.  It also reduces the number of messages that have

   to be sent between resolvers and name servers hence overall network

   traffic.  A large proportion of DNS traffic on the Internet could be

   eliminated if all resolvers implemented negative caching.  With this

   in mind negative caching should no longer be seen as an optional part

   of a DNS resolver.
</t></abstract></front>

<seriesInfo name='RFC' value='2308' />
<format type='TXT' octets='41428' target='http://www.rfc-editor.org/rfc/rfc2308.txt' />
<format type='XML' octets='41491' target='http://xml.resource.org/public/rfc/xml/rfc2308.xml' />
</reference>
<?rfc linefile="409:draft-kolkman-cautious-delegation.xml"?>

      <?rfc?><?rfc linefile="1:bibxml/reference.RFC.3379"?>

<reference anchor='RFC3379'>

<front>
<title>Delegated Path Validation and Delegated Path Discovery Protocol Requirements</title>
<author initials='D.' surname='Pinkas' fullname='D. Pinkas'>
<organization /></author>
<author initials='R.' surname='Housley' fullname='R. Housley'>
<organization /></author>
<date year='2002' month='September' /></front>

<seriesInfo name='RFC' value='3379' />
<format type='TXT' octets='32455' target='http://www.rfc-editor.org/rfc/rfc3379.txt' />
</reference>
<?rfc linefile="411:draft-kolkman-cautious-delegation.xml"?>

      <?rfc?><?rfc linefile="1:bibxml/reference.RFC.6265"?>

<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>
<?rfc linefile="413:draft-kolkman-cautious-delegation.xml"?>

      <?rfc?><?rfc linefile="1:bibxml/reference.RFC.6761"?>

<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>
<?rfc linefile="415:draft-kolkman-cautious-delegation.xml"?>

      <?rfc?><?rfc linefile="1:bibxml/reference.RFC.6762"?>

<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>&lt;t> 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>&lt;t> 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>
<?rfc linefile="417:draft-kolkman-cautious-delegation.xml"?>
    </references>

    <section anchor="details" title="Document Editing Details">
      <t>[To Be Removed before publication]</t>

      <t>$Id: draft-kolkman-cautious-delegation.xml 3 2013-05-02 14:27:06Z
      olaf $</t>

      <section title="version 00">
        <t>Documenting the first rough outline based on hallway discussions
        with the specific purpose to document the idea in the public
        domain.</t>

        <t>$Id: draft-kolkman-cautious-delegation.xml 5 2013-06-11 21:49:28Z
        warren $</t>
      </section>

      <section title="version 01">
        <t><list style="symbols">
            <t>Bunch 'o nits.</t>

            <t>Added section on search-path processing.</t>

            <t></t>
          </list></t>
      </section>
    </section>
  </back>
</rfc>
