draft-wkumari-dnsop-internal.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" ".//reference.RFC.2119.xml">
]>
<!-- WK: Set category, IPR, docName -->
<rfc category="info" docName="draft-wkumari-dnsop-internal-00"
     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" ?>

  <front>
    <!-- WK: Set long title. -->

    <title abbrev=".internal">The .internal TLD.</title>

    <author fullname="Warren Kumari" initials="W." surname="Kumari">
      <organization>Google</organization>

      <address>
        <postal>
          <street>1600 Amphitheatre Parkway</street>

          <city>Mountain View, CA</city>

          <code>94043</code>

          <country>US</country>
        </postal>

        <email>warren@kumari.net</email>
      </address>
    </author>

    <date day="2" month="July" year="2017"/>

    <workgroup>DNSOP</workgroup>

    <abstract>
      <t>It has become clear that many users would like to use the DNS
      resolution system for names which do not have meaning in the global
      context but do have meaning in a context internal to their network. This
      document reserves the string ".internal" for this purpose.</t>

      <t>[ Ed note: Text inside square brackets ([]) is additional background
      information, answers to frequently asked questions, general musings,
      etc. They will be removed before publication. RFC Editor: Please remove
      these before publication. ]</t>

      <t>[ This document is being collaborated on in Github at:
      https://github.com/wkumari/draft-wkumari-dnsop-internal. The most recent
      version of the document, open issues, etc should all be available here.
      The authors (gratefully) accept pull requests ]</t>

      <t>[ Ed note: This document is intended to drive discussion. It is clear
      that there has been a desire for an "RFC 1918-style" TLD for a long
      time; in its absence, people have just started using whatever seemed
      convenient. This document requests that the allocation of .internal for
      this use. There is no existing process for this - some of the purpose of
      this document is to explore the process implications. ]</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>Over the years, a number of strings have been used as pseudo-TLDs for
      namespaces that are disjoint (or separate) from the "global DNS"
      namespace. Common examples of these include .home and .corp. See <xref
      target="I-D.chapin-additional-reserved-tlds"/>, <xref
      target="RFC8244"/> for more background information on
      this issue. The <xref target="RFC8244"/> document
      discusses the issues in depth, and should be considered required reading
      for understanding this document.</t>

      <t>The <xref target="I-D.ietf-dnsop-alt-tld"/> document reserves a
      string to be used as a pseudo-TLD for non-DNS resolution contexts.
      However, it is clear that there is a significant use case for a similar
      string to be used for namespaces which are resolved using the DNS
      protocol, but which do not have a meaning in the global DNS context.</t>

      <t>There is no way to prevent users from simply picking a string (such
      as .home) and starting to use it for internal use. Unfortunately,
      although these strings are supposed to only be used internally, there is
      ample evidence that they often leak into the global DNS, sometimes
      causing technical issues for the user of the no-longer internal
      name.</t>

      <t>This document requests allocation of a string to be used as a
      pseudo-TLD for namespaces that are not part of the global DNS, but are
      meant to be resolved with the DNS protocol. A reasonable analogy is that
      this is to names as <xref target="RFC1918"/> is to IP addresses. Such a
      reservation should alleviate pollution, such as junk queries at the
      root, and potential collisions with other users of the namespace.</t>

      <t>Note that there was a discussion of the .homenet delegation in the
      HOMENET WG, and the resulting decision was to *not* request that the
      name be delegated as a TLD for the IETF's use. This document has
      significant similarities to the .homenet case, but also significant
      differences. These include (in no particular order) the fact that the
      use case is significant broader, and that there is no urgency to the
      request and does not delay or create uncertainty for any protocol
      work.</t>

      <section title="Requirements notation">
        <t>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 <xref
        target="RFC2119"/>.</t>
      </section>
    </section>

    <section title="Use cases">
      <t>The ".internal" TLD can be used for any purpose where a non-global
      DNS name is needed.</t>

      <t>This includes creating a namespace "behind" a Customer Premises
      Equipment (CPE). For example, the Belkin company used ".belkin" for
      this. British Telecom used ".home", and shipped devices named
      "bthomehub.home" <xref target="BT_HOME_HUB"/>). Additionally, internal
      resolution systems like Microsoft Active Directory have documentation
      that suggests (or previously suggested) that administrators use ".corp"
      for these cases.</t>

      <t>The .internal TLD is intended to address some of the issues
      documented in the Special-Use Domain Names Problem Statement <xref
      target="RFC8244"/> specifically (from the list in
      Section 3):</t>

      <t><list style="hanging">
          <t hangText="5.3:">Intended use is covered by gTLD process, but the
          third party doesn't want to pay a fee.</t>

          <t hangText="5.4:">Intended use is covered by some IETF process, but
          the third party doesn't want to follow the process.</t>

          <t hangText="5.6:">Unaware that a name intended to be used only
          locally may nevertheless leak</t>

          <t hangText="5.7:">Unaware that a name used locally with informal
          allocation may subsequently be allocated formally, creating
          operational problems.</t>

          <t hangText="18">There exists no safe, non-process-violating
          mechanism for ad-hoc assignment of Special-Use Domain Names.</t>
        </list></t>

      <t>Other use cases for .internal could include its use in
      testing, prototyping, and benchmarking, but there is already a
      .test which is in the "Special Use Names" registry, and which is
      perfectly suitable for that (<xref target="RFC6761"/>, section
      6.2). Researchers have often needed to set up a fake root and
      namespace in order to test something, specially a piece of
      network equipment which it not connected to the Internet.</t>
    </section>

    <section title="Why not use &lt;existing name&gt;?">
      <t>The IANA "Special Use Names" registry <xref target="IANA.SUN"/>
      already contains some names which, it could be argued, already meet this
      need. Unfortunately, many of these names (such as ".example") are either
      reserved for a specific use case, or are semantically unsuitable (for
      example, a CPE manufacturer would likely not find "Open a browser and
      connect to 'router.invalid'" acceptable).</t>

      <t>This section discusses why existing strings in the Special-Use Domain
      Names registry (<xref target="IANA.SUN"/>) are not appropriate.</t>

      <section title="Why not use .alt?">
        <t>The proposed .alt presudo-TLD is specifically only for use as a
        pseudo-TLD for non-DNS resolution contexts. At one point .alt was
        being considered both for DNS and non-DNS resolution contexts, but,
        after much discussion it was decided that the DNSSEC implications (and
        desired behavior) meant that .alt should be reserved specifically for
        non-DNS resolution.</t>
      </section>

      <section anchor="arpa" title="Why not use something.arpa?">
        <t>This is indeed an interesting idea. I suspect that it fails the
        semantically desirable / understandable case, but is definitely worth
        further discussion. It may also cause issues when server operators
        override part of the .arpa domain in order to instantiate
        something.arpa.</t>
      </section>

      <section title="Why not use .local?">
        <t>.local is already in wide use and has special handling implemented
        for handing .local names. See <xref target="RFC6762"/> Section 22.1
        Subsection 3, 4, 5.</t>
      </section>

      <section title="Why not use .example?">
        <t>.example, .example.[com|net|org] may indeed be appropriate.
        Unfortunately, the hard part of all of this is not the selection and
        adding of a name to the "Special Use Names" registry, but rather
        deciding if this should be done and, if so, the process to interact
        with ICANN in order to achieve the delegation.</t>
      </section>
    </section>

    <section title="DNSSEC Considerations">
      <t>The .internal TLD would be an unsigned TLD, as there is no (clean)
      way to sign it.</t>

      <t>This particular topic received much discussion during the "Should
      .alt be used for DNS, or only non-DNS resolution" discussions, and was
      the cause of much confusion and misunderstandings. Much of this revolved
      around why it is important to have an insecure DNSSEC delegation for a
      name which is added to the Locally-Served DNS Zones <xref
      target="IANA.LocallyServed">(</xref> ) registry, or any other case where
      a name is instantiated. It is briefly covered here, but interested
      readers should review the DNSOP mailing list archive for more
      details.</t>

      <t>Take the following figure:<figure>
          <artwork><![CDATA[
                +-----------+         +----------+
 .-------.      |           |         |   Stub   |
(  Root   <-----| Resolver  <---------| Resolver |
 `-------'      +-----------+         +----------+
     A                B                     C]]></artwork>
        </figure></t>

      <t>The user has just purchased a new CPE, which creates an internal
      namespace called .internal, and responds to lookups for router.interal
      with its (internal) management IP address (another example would be a
      corporate user at an organization which has created a private internal
      namespace disconnected from the public, global DNS). The CPE hands out
      addresses using DHCP, and lists itself as the DNS server.</t>

      <t>The user follows the instructions included in the box, and enters
      "http://router.internal" into a web browser. This causes a DNS lookup to
      be sent from the user's stub to the recursive resolver. The recursive
      resolver correctly identifies that this is query is for itself, and so
      responds with an answer saying "router.internal is 192.168.0.1".</t>

      <t/>

      <section title="Scenario 1 - No DNSSEC, .internal not delegated">
        <t>In this scenario, the .internal name has not been added to the root
        zone, and the user's stub resolver *does not* perform DNSSEC
        validation. The stub receives the response, performs no validation,
        and so trust the answer and connects. The user is happy. This is the
        current behavior for non-DNSSEC validating stubs.</t>
      </section>

      <section title="Scenario 2 - DNSSEC, .internal not delegated">
        <t>In this scenario, the .internal name has not been added to the root
        zone, and the user's stub resolver *does* perform DNSSEC validation.
        (Note that it is believed that validating stubs are currently rare.)
        The stub receives the response, and begins DNSSEC validation. As the
        .internal TLD has not been added to the root zone, DNSSEC
        Authenticated Denial of Existence proves that the .internal TLD does
        not exist (currently there is an NSEC record proving that nothing
        exists between .intel and .international). This resulting outcome is a
        DNSSEC "bogus" answer, the user is unable to connect, and becomes
        frustrated. This is the current behavior for DNSSEC validating
        stubs.</t>
      </section>

      <section title="Scenario 3 - DNSSEC, .internal delegated">
        <t>In this scenario, the .internal name has been added to the DNS root
        zone, with an insecure delegation to AS112 (by "insecure delegation"
        we mean that that there is no DS record for .internal in the root
        zone; the .internal domain is unsigned). The stub receives the
        response, and performs DNSSEC validation. As .internal has been
        delegated, there is an (insecure) entry in the root zone, proving that
        the .internal TLD exists. As it is an insecure delegation, the
        validating stub is perfectly happy to accept the "router.internal is
        192.168.0.1" response, the user connects to their router, and everyone
        is happy.</t>
      </section>
    </section>

    <section title="IANA Considerations">
      <t>This document requests that the .internal TLD be assigned to the IANA
      (similar to the way that .example is) and a DNSSEC insecure delegation
      (that is, a delegation with no DS records) be inserted into the
      root-zone, delegated to blackhole-[12].iana.org.</t>

      <t>[Editor's note: This is not something which the IANA currently has
      the authority to do. This fact was extensively discussed during the
      .homenet discussions. This text in the IANA considerations should be
      considered a placeholder for "what someone needs to do if this gets IETF
      consensus". If there is consensus that the reservation of .internal
      makes sense, there will need to be some process design before
      implementation. Such a process might be similar to "the IESG asks the
      IAB to request ICANN to consider the reservation / delegation of this
      string". ICANN does not currently have a process for handling requests
      like these, and so will also likely need to design a process for this.
      It is possible that either process might not be designed and this will
      fail. It is also possible that the IETF makes a request and ICANN does
      not make the delegation. ]</t>

      <section title="Domain Name Reservation Considerations">
        <t>[ Ed: This section is to satisfy the requirement in Section 5 of
        RFC6761. This document is intended to spark a discussion, there is
        currently no process for the IETF / IAB to request that ICANN delegate
        a TLD for special use, and simply adding .internal to the "Special-Use
        Domain Name" registry (<xref target="IANA.SUN"/>) does not accomplish
        this. I have decided to fill in the RFC6761 "questions" simply to
        clarify the expected behavior. This entire section needs to be removed
        before publication. ]</t>

        <t>The string ".internal." is special in the following ways:<list
            style="numbers">
            <t>Users may know that strings that end in .internal behave
            differently to normal DNS names. They may expect that names of the
            form &lt;something&gt;.internal refer to resources internal to
            their network / enterprise / similar.</t>

            <t>Writers of application software not required to perform any
            special handing for .internal names. They are resolved normally,
            using the DNS.</t>

            <t>Writers of name resolution APIs and libraries are not expected
            to perform special handling.</t>

            <t>Caching DNS servers MAY recognize these names as special. By
            default they should answer them locally (using "Locally Served
            Zones"), but may be configured to forward them to authoritative
            servers.</t>

            <t>Authoritative DNS servers SHOULD NOT recognize these names as
            special and should not perform any special handling with them,
            unless they wish to instantiate an internal namespace, in which
            case they can choose to simply create any names within .internal
            that they want. Names are "local" to the network, and only have
            meaning within that network.</t>

            <t>DNS server operators SHOULD be aware that queries for names
            ending in .internal are not part of the global, IANA DNS, and were
            leaked into the global DNS. This information may be useful for
            support or debugging purposes.</t>

            <t>DNS Registries/Registrars MUST NOT grant requests to register
            ".internal" names in the normal way to any person or entity. These
            ".internal" names are defined by protocol specification to be
            nonexistent, and they fall outside the set of names available for
            allocation by registries/registrars.</t>
          </list></t>
      </section>
    </section>

    <section anchor="security" title="Security Considerations">
      <t>This section will certainly be filled in later as the discussion
      progresses.</t>
    </section>

    <section anchor="i18n" title="Internationalisation Considerations">
      <t>The string "internal" has been choosen because it is
      meaningful in english (otherwise, a name like
      <xref target="arpa">ed972c0b30458c56615082c45cb6f91e.arpa</xref>
      would have worked as well). Its intent will be clear to
      english-reading people. In theory, it would have been good to
      reserve a similar name for the 8,126 languages currenty in the
      language subtag registry. But it is clearly unrealistic, so in,
      practice, this name will be meaningful only for some part of the
      Internet users.</t>
    </section>

    <section title="Acknowledgements">
      <t>The authors wish to thank Steve Crocker, Wes Hardaker, David
      Lawrence, Suzanne Woolf, and many others on the DNSOP mailing list.</t>

      <t>The author would like to especially think Paul Hoffman for creating a
      Pull Request. </t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include='reference.RFC.2119'?>

      <?rfc include='reference.RFC.8244'?>
    </references>

    <references title="Informative References">
      <?rfc include='reference.I-D.draft-chapin-additional-reserved-tlds-02.xml'?>

      <?rfc include='reference.I-D.draft-ietf-dnsop-alt-tld-08.xml'?>

      <?rfc include='reference.RFC.1918'?>

      <?rfc include='reference.RFC.6761'?>
      
      <?rfc include='reference.RFC.6762'?>

      <reference anchor="BT_HOME_HUB"
                 target="http://bt.custhelp.com/app/answers/detail/a_id/44798/kw/bthomehub.home/c/346,7474,7477">
        <front>
          <title abbrev="Connecting to BT Hub">I have problems connecting 5GHz
          and dual band devices wirelessly to the BT Hub</title>

          <author>
            <organization>IANA</organization>
          </author>

          <date/>
        </front>
      </reference>

      <reference anchor="IANA.LocallyServed"
                 target="https://www.iana.org/assignments/locally-served-dns-zones/locally-served-dns-zones.xhtml">
        <front>
          <title abbrev="Locally Served">Locally Served DNS Zones</title>

          <author>
            <organization>IANA</organization>
          </author>

          <date/>
        </front>
      </reference>

      <reference anchor="IANA.SUN"
                 target="https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml">
        <front>
          <title abbrev="Special-Use Domain Names">Special-Use Domain
          Names</title>

          <author>
            <organization>IANA</organization>
          </author>

          <date/>
        </front>
      </reference>
    </references>

    <section title="Changes / Author Notes.">
      <t>[RFC Editor: Please remove this section before publication ]</t>

      <t>-00</t>

      <t><list style="symbols">
          <t>This document was originally started in late 2014 / early 2015,
          but languished until being revived in June 2017.</t>
        </list></t>
    </section>
  </back>
</rfc>