GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc8244

Internet Engineering Task Force (IETF) T. Lemon Request for Comments: 8244 Nominum, Inc. Category: Informational R. Droms ISSN: 2070-1721

                                                             W. Kumari
                                                                Google
                                                          October 2017
             Special-Use Domain Names Problem Statement

Abstract

 The policy defined in RFC 6761 for IANA registrations in the
 "Special-Use Domain Names" registry has been shown, through
 experience, to present challenges that were not anticipated when RFC
 6761 was written.  This memo presents a list, intended to be
 comprehensive, of the problems that have since been identified.  In
 addition, it reviews the history of domain names and summarizes
 current IETF publications and some publications from other
 organizations relating to Special-Use Domain Names.
 This document should be considered required reading for IETF
 participants who wish to express an informed opinion on the topic of
 Special-Use Domain Names.

Status of This Memo

 This document is not an Internet Standards Track specification; it is
 published for informational purposes.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Not all documents
 approved by the IESG are a candidate for any level of Internet
 Standard; see Section 2 of RFC 7841.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 https://www.rfc-editor.org/info/rfc8244.

Lemon, et al. Informational [Page 1] RFC 8244 Special-Use Domain Names Problem October 2017

Copyright Notice

 Copyright (c) 2017 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
 (https://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Table of Contents

 1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
 2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
 3.  Problems Associated with Special-Use Domain Names . . . . . .   4
 4.  Existing Practice regarding Special-Use Domain Names  . . . .  10
   4.1.  Primary Special-Use Domain Name Documents . . . . . . . .  10
     4.1.1.  IAB Technical Comment on the Unique DNS Root  . . . .  10
     4.1.2.  Special-Use Domain Names  . . . . . . . . . . . . . .  12
     4.1.3.  MoU Concerning the Technical Work of IANA . . . . . .  13
     4.1.4.  Liaison Statement on Technical Use of Domain Names  .  14
     4.1.5.  IAB Statement on the Registration of Special Use
             Names in the ARPA Domain  . . . . . . . . . . . . . .  15
   4.2.  Secondary Documents Relating to the Special-Use Domain
         Name Question . . . . . . . . . . . . . . . . . . . . . .  15
     4.2.1.  Multicast DNS . . . . . . . . . . . . . . . . . . . .  15
     4.2.2.  The '.onion' Special-Use Top-Level Domain Name  . . .  16
     4.2.3.  Locally Served DNS Zones  . . . . . . . . . . . . . .  16
     4.2.4.  Name Collision in the DNS . . . . . . . . . . . . . .  17
     4.2.5.  SSAC Advisory on the Stability of the Domain
             Namespace . . . . . . . . . . . . . . . . . . . . . .  17
     4.2.6.  Discovery of the IPv6 Prefix Used for IPv6 Address
             Synthesis . . . . . . . . . . . . . . . . . . . . . .  17
     4.2.7.  Additional Reserved Top-Level Domains . . . . . . . .  18
 5.  History . . . . . . . . . . . . . . . . . . . . . . . . . . .  18
 6.  Security Considerations . . . . . . . . . . . . . . . . . . .  20
 7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  20
 8.  Informative References  . . . . . . . . . . . . . . . . . . .  20
 Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  24
 Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  25

Lemon, et al. Informational [Page 2] RFC 8244 Special-Use Domain Names Problem October 2017

1. Introduction

 One of the key services required to use the Internet is name
 resolution.  Name resolution is the process of translating a symbolic
 name into some object or set of objects to which the name refers,
 most typically one or more IP addresses.  These names are often
 referred to as "domain names".  When reading this document, care must
 be taken not to assume that the term domain name implies the use of
 the Domain Name System [RFC1034] for resolving these names.  An
 excellent presentation on this topic can be found in Domain Names
 [DOMAIN-NAMES].
 "Special-Use Domain Names" [RFC6761] created the "Special-Use Domain
 Names" IANA registry [SDO-IANA-SUDR], defined policies for adding to
 the registry, and made some suggestions about how those policies
 might be implemented.  Since the publication of RFC 6761, the IETF
 has been asked to designate several new Special-Use Domain Names in
 this registry.  During the evaluation process for these Special-Use
 Domain Names, the IETF encountered several different sorts of issues.
 Because of this, the IETF has decided to investigate the problem and
 decide if and how the process defined in RFC 6761 can be improved, or
 whether it should be deprecated.  The IETF DNSOP Working Group
 charter was extended to include conducting a review of the process
 for adding names to the registry that is defined in RFC 6761.  This
 document is a product of that review.
 Based on current ICANN and IETF practice, including RFC 6761, there
 are several different types of names in the root of the Domain
 Namespace:
 o  Names reserved by the IETF for technical purposes
 o  Names assigned by ICANN to the public DNS root; some names
    reserved by the IETF for technical purposes may appear in the
    global DNS root for reasons pertaining to the operation of the DNS
 o  ICANN Reserved Names; names that may not be applied for as TLDs
    (see "Reserved Names" and "Treatment of Country or Territory
    Names" (Sections 2.2.1.2.1 and 2.2.1.4.1, respectively) of
    [SDO-ICANN-DAG]).
 o  Names used by other organizations without following established
    processes
 o  Names that are unused and are available for assignment to one of
    the previous categories

Lemon, et al. Informational [Page 3] RFC 8244 Special-Use Domain Names Problem October 2017

 This document presents a list, derived from a variety of sources,
 including discussion in the IETF DNSOP Working Group, of the problems
 associated with the assignment of Special-Use Domain Names.  The list
 is intended to be an unfiltered compilation of issues.  In support of
 its analysis of the particular set of issues described here, the
 document also includes descriptions of existing practice as it
 relates to the use of domain names, a brief history of domain names,
 and some observations by various IETF participants who have
 experience with various aspects of the current situation.

2. Terminology

 This document uses the terminology from RFC 7719 [RFC7719].  Other
 terms used in this document are defined here:
 Domain Name:  This document uses the term "domain name" as defined in
    Section 2 of RFC 7719 [RFC7719].
 Domain Namespace:  The set of all possible domain names.
 Special-Use Domain Name:  A domain name listed in the "Special-Use
    Domain Names" registry [SDO-IANA-SUDR].
 For the sake of brevity, this document uses some abbreviations, which
 are expanded here:
 IANA:   Internet Assigned Numbers Authority
 ICANN:  Internet Corporation for Assigned Names and Numbers
 TLD:    Top-Level Domain, as defined in Section 2 of RFC 7719
         [RFC7719]
 gTLD:   Generic Top-Level Domain (see Section 2 of RFC 2352
         [RFC2352])

3. Problems Associated with Special-Use Domain Names

 This section presents a list of problems that have been identified
 with respect to the assignment of Special-Use Domain Names.
 Solutions to these problems, including their costs or trade-offs, are
 out of scope for this document and will be covered in a separate
 document.  New problems that might be created in the process of
 solving problems described in this document are also out of scope:
 these problems are expected to be addressed in the process of
 evaluating potential solutions.

Lemon, et al. Informational [Page 4] RFC 8244 Special-Use Domain Names Problem October 2017

 Special-Use Domain Names exist to solve a variety of problems.  This
 document has two goals: enumerate all of the problems that have been
 identified to which Special-Use Domain Names are a solution and
 enumerate all of the problems that have been raised in the process of
 trying to use RFC 6761 as it was intended.  As some of those problems
 may fall into both categories, this document makes no attempt to
 categorize the problems.
 There is a broad diversity of opinion about this set of problems.
 Not every participant agrees that each of the problems enumerated in
 this document is actually a problem.  This document takes no position
 on the relative validity of the various problems that have been
 enumerated, nor on the organization responsible for addressing each
 individual problem, if it is to be addressed.  This document only
 enumerates the problems, provides the reader with context for
 thinking about them, and provides a context for future discussion of
 solutions, regardless of whether such solutions may work for IETF,
 ICANN, IANA, or some other group.
 The list of problems is not presented in order of importance; numbers
 are assigned so that each problem can easily be referenced by number,
 not to indicate priority.  The list of problems is as follows:
 1.   Although the IETF and ICANN have a liaison relationship through
      which special-use allocations can be discussed, there exists no
      formal process for coordinating these allocations (see
      Section 4.1.3).  The lack of coordination complicates the
      management of the root of the Domain Namespace and could lead to
      conflicts in name assignments [SDO-ICANN-SAC090].
 2.   There is no explicit scoping as to what can constitute a
      "technical use" [RFC2860] and what cannot; there is also no
      consensus within the IETF as to what this term means.
 3.   Not all developers of protocols on the Internet agree that
      authority over the entire Domain Namespace should reside solely
      with the IETF and ICANN.
 4.   Although the IETF and ICANN nominally have authority over this
      namespace, neither organization can enforce that authority over
      any third party who wants to just start using a subset of the
      namespace.  Such parties may observe that the IETF has never
      asserted control or authority over what protocols are "allowed"
      on the Internet, and that the principle of "permissionless
      innovation" suggests there should be a way for people to include
      new uses of domain names in new protocols and applications.

Lemon, et al. Informational [Page 5] RFC 8244 Special-Use Domain Names Problem October 2017

 5.   Organizations do in fact sometimes use subsets of the Domain
      Namespace without following established processes.  Reasons a
      third party might do this include:
      1.  Lack of knowledge that a process exists for assigning such
          names.
      2.  Intended use is covered by the gTLD process [SDO-ICANN-DAG],
          but no gTLD process is ongoing.
      3.  Intended use is covered by the gTLD process, but the third
          party doesn't want to pay a fee.
      4.  Intended use is covered by some IETF process, but the third
          party doesn't want to follow the process.
      5.  Intended use is covered by an ICANN or IETF process, but the
          third party expects that the outcome will be refusal or non-
          action.
      6.  Lack of knowledge that a name intended to be used only
          locally may nevertheless leak.
      7.  Lack of knowledge that a name used locally with informal
          allocation may subsequently be allocated formally, creating
          operational problems.
 6.   There is demand for more than one name resolution protocol for
      domain names.  Domain names contain no metadata to indicate
      which protocol to use to resolve them.  Domain name resolution
      APIs do not provide a way to specify which protocol to use.
 7.   When a Special-Use Domain Name is added to the "Special-Use
      Domain Names" registry, not all software that processes such
      names will understand the special use of that name.  In many
      cases, name resolution software will use the Domain Name System
      for resolution of names not known to have a special use.
      Consequently, any such use will result in queries for Special-
      Use Domain Names being sent to Domain Name System authoritative
      servers.  These queries may constitute an operational problem
      for operators of root zone authoritative name servers.  These
      queries may also inadvertently reveal private information
      through the contents of the query, which is a privacy
      consideration.

Lemon, et al. Informational [Page 6] RFC 8244 Special-Use Domain Names Problem October 2017

 8.   Some protocol developers have assumed that they could not
      succeed in getting a name assigned through the IETF using the
      process defined in RFC 6761.  This is because when the IETF has
      attempted to follow the process defined in RFC 6761, it has been
      slow and uncertain.  For example, the process of assigning the
      first new name ('.local') using the process defined in RFC 6761
      took more than ten years from beginning to end: longer by a
      factor of ten than any other part of the protocol development
      process (largely because this ten years included time to develop
      the process as well as use it).  Other uses of the process have
      proceeded more smoothly, but there is a reasonably justified
      perception that using this process is likely to be slow and
      difficult, with an uncertain outcome.
 9.   There is strong resistance within the IETF to assigning domain
      names to resolution systems outside of the DNS, for a variety of
      reasons:
      1.  It requires a mechanism for identifying which set of
          resolution processes is required in order to resolve a
          particular name.
      2.  Assertion of authority: there is a sense that the Domain
          Namespace is "owned" by the IETF or by ICANN, so, if a name
          is claimed without following their processes, the person or
          entity that claimed that name should suffer some consequence
          that would, presumably, deter future circumvention of the
          official processes.
      3.  More than one name resolution protocol is bad, in the sense
          that a single protocol is less complicated to implement and
          deploy.
      4.  The semantics of alternative resolution protocols may differ
          from the DNS protocol; DNS has the concept of RRtypes,
          whereas other protocols may not support RRtypes or may
          support some entirely different data structuring mechanism.
      5.  If there is an IETF process through which a TLD can be
          assigned at zero cost other than time, this process will be
          used as an alternative to the more costly process of getting
          the name registered through ICANN.
      6.  A name might be assigned for a particular purpose when a
          more general use of the name would be more beneficial.

Lemon, et al. Informational [Page 7] RFC 8244 Special-Use Domain Names Problem October 2017

      7.  If the IETF assigns a name that some third party or parties
          believe belongs to them in some way, the IETF could become
          embroiled in an expensive dispute with those parties.
 10.  If there were no process for assigning names for technical use
      through the IETF, there is a concern that protocols that require
      such names would not be able to get them.
 11.  In some cases where the IETF has made assignments through the
      process defined in RFC 6761, technical mistakes have been made
      due to misunderstandings as to the actual process that RFC 6761
      specifies (e.g., treating the list of suggested considerations
      for assigning a name as a set of requirements, all of which must
      be met).  In other cases, the IETF has made de facto assignments
      of Special-Use Domain Names without following the process in RFC
      6761 (see [RFC7050] and [RFC7788]).
 12.  There are several Top-Level Domain Names that are in use without
      due process for a variety of purposes.  The status of these
      names need to be clarified and recorded to avoid future disputes
      about their use [SDO-ICANN-COLL].
 13.  In principle, the process defined in RFC 6761 could be used to
      document the existence of domain names that are not safe to
      assign and provide information on how those names are used in
      practice.  However, attempts to use RFC 6761 to accomplish this
      documentation have not been successful (for example, see
      "Additional Reserved Top Level Domains" [RESERVED-TLDS] and
      Section 4.2.7 of this document).  One side effect of the lack of
      documentation is that any mitigation effect on the root name
      servers or on privacy considerations has been missed.
 14.  A domain name can be identified as either a DNS name by placing
      it in the DNS zone(s) or a Special-Use Domain Name by adding it
      to the IANA registry.  Some names are in both places; for
      example, some locally served zone names are in DNS zones and
      documented in the "Special-Use Domain Names" registry.  At
      present, the only way a domain name can be added to the
      "Special-Use Domain Name" registry is for the IETF to take
      responsibility for the name and designate it for "technical
      use".  There are other potential uses for domain names that
      should be recorded in the registry, but for which the IETF
      should not take responsibility.
 15.  In some cases, the IETF may see the need to document that a name
      is in use without claiming that the use of the name is the
      IETF's particular use of the name.  No mechanism exists in the
      current registry to mark names in this way.

Lemon, et al. Informational [Page 8] RFC 8244 Special-Use Domain Names Problem October 2017

 16.  During any of the review stages of a document, there is no
      formal process in which a check is made to ensure that the
      document does not unintentionally violate the IETF process for
      adding Special-Use Domain Names to the registry, as was the
      case, for example, in RFC 7788 [RFC7788].
 17.  Use of the registry is inconsistent -- some Special-Use Domain
      Name RFCs specifically add registry entries, some don't; some
      specify how and whether special-use name delegations should be
      done, some don't.
 18.  There exists no safe, non-process-violating mechanism for ad hoc
      assignment of Special-Use Domain Names.
 19.  It is generally assumed that protocols that need a Special-Use
      Domain Name need a mnemonic, single-label, human-readable
      Special-Use Domain Name for use in user interfaces such as
      command lines or URL entry fields.  While this assumption is
      correct in some cases, it is likely not correct in all cases,
      for example, in applications where the domain name is never
      visible to a user.
 20.  RFC 6761 uses the term "domain name" to describe the thing for
      which special uses are registered.  This creates a great deal of
      confusion because some readers take "domain name" to imply the
      use of the DNS protocol.
 21.  The use of DNSSEC with Special-Use Domain Names is an open
      issue.  There is no consensus or guidance about how to use
      DNSSEC with various classes of Special-Use Domain Names.
      Considerations in the use of DNSSEC with Special-Use Domain
      Names include:
      1.  What class of Special-Use Domain Name is under
          consideration: non-DNS, locally served zone, or other?
      2.  Does the Special-Use Domain Name require a delegation in the
          root zone; if so, should that delegation be signed or not?
          If there is no delegation, then this will be treated by
          validating resolvers as a secure denial of existence for
          that zone.  This would not be appropriate for a name being
          resolved using the DNS protocol.
      3.  A process would be required through which the IETF can cause
          a delegation in the root zone to be instantiated.
      4.  What are the recommended practices for using DNS with the
          specific Special-Use Domain Name?

Lemon, et al. Informational [Page 9] RFC 8244 Special-Use Domain Names Problem October 2017

 The above list represents the current understanding of the authors as
 to the complete set of problems that have been identified during
 discussion by the working group on this topic.  The remainder of this
 document provides additional context that will be needed for
 reasoning related to these problems.

4. Existing Practice regarding Special-Use Domain Names

 There are three primary (see Section 4.1) and numerous secondary
 (Section 4.2) documents to consider when thinking about the Special-
 Use Domain Names process.
 How names are resolved is ambiguous, in the sense that some names are
 Special-Use Domain Names that require special handling and some names
 can be resolved using the DNS protocol with no special handling.
 The assignment of Internet Names is not under the sole control of any
 one organization.  The IETF has authority in some cases, but only
 with respect to "technical uses".  At present, ICANN is the
 designated administrator of the root zone; but generally not of zones
 other than the root zone.  Neither of these authorities can, in any
 practical sense, exclude the practice of ad hoc use of names.
 Unauthorized use of domain names can be accomplished by any entity
 that has control over one or more name servers or resolvers, in the
 context of any hosts and services that entity operates.  It can also
 be accomplished by authors of software who decide that a Special-Use
 Domain Name is the right way to indicate the use of an alternate
 resolution mechanism.

4.1. Primary Special-Use Domain Name Documents

 The primary documents are considered primary because they directly
 address the IETF's past thoughts on this topic in a general way, and
 also because they describe what the IETF does in practice.

4.1.1. IAB Technical Comment on the Unique DNS Root

 [RFC2826] is not an IETF consensus document, and it appears to have
 been written to address a different problem than the Special-Use
 Domain Name problem.  However, it speaks directly to several of the
 key issues that must be considered, and, coming as it does from the
 IAB, it is rightly treated as having significant authority despite
 not being an IETF consensus document.
 This document should be considered required reading for IETF
 participants who wish to express an informed opinion on the topic of
 Special-Use Domain Names.  The main points that appear relevant to
 the Special-Use Domain Names problem are:

Lemon, et al. Informational [Page 10] RFC 8244 Special-Use Domain Names Problem October 2017

 o  The Internet requires a globally unique namespace: a namespace in
    which any given name refers to the same information (has the same
    meaning) no matter who requests that information and no matter
    from which specific name server they request it.
 o  Private networks may operate private namespaces, with names that
    have meanings only locally (within the private network), but they
    still require that names in the public namespace be globally
    unique.
 o  The Domain Name System [RFC1035] is not the only protocol that may
    be used for resolving domain names.
 o  Users cannot be assumed to know how to distinguish between
    symbolic references that have local meaning and references that
    have global meaning.  Therefore, users may share references that
    incorporate domain names with no global meaning (for example, a
    URL of 'http://mysite.example.corp', where 'example.corp' is a
    domain used privately and informally as described in
    [SDO-ICANN-COLL]).
 o  While such a reference in the user's context refers to the object
    the user wishes to share, when the reference is used in a
    different context, it could refer either to some different object
    in the recipient's context or to no object at all.  The effect of
    this reference escaping the context in which it is valid is that
    the user's intended communication will not be able to be
    understood by the recipients of the communication.
    This same problem can also occur when a single user copies a name
    from one context in which it has one meaning into a different
    context in which it has a different meaning -- for example,
    copying a '.onion' domain name out of a Tor Browser [TOR], where
    it has meaning, and pasting this name into an SSH client that
    doesn't support connecting over the Tor network.
 We can summarize the advice in this document as follows:
 o  Domain names with unambiguous global meaning are preferable to
    domain names with local meaning that will be ambiguous.
    Nevertheless, both globally meaningful and locally special names
    are in use and must be supported.
 o  At the time of the writing of this document, the IAB was of the
    opinion that there might well be more than one name resolution
    protocol used to resolve domain names.

Lemon, et al. Informational [Page 11] RFC 8244 Special-Use Domain Names Problem October 2017

4.1.2. Special-Use Domain Names

 The second important document is "Special-Use Domain Names"
 [RFC6761].  RFC 6761 represents the current IETF consensus on
 designating and recording Special-Use Domain Names.  The IETF has
 experienced problems with the designation process described in RFC
 6761; these concerns motivate this document.  Familiarity with RFC
 6761 is a prerequisite for having an informed opinion on the topic of
 Special-Use Domain Names.
 RFC 6761 defines two aspects of Special-Use Domain Names: designating
 a domain name to have a special purpose and registering that special
 use in the "Special-Use Domain Names" registry.  The designation
 process is defined in a single sentence (RFC 6761, Section 4):
    If it is determined that special handling of a name is required in
    order to implement some desired new functionality, then an IETF
    "Standards Action" or "IESG Approval" specification [RFC5226] MUST
    be published describing the new functionality.
 This sentence requires that any designation of a Special-Use Domain
 Name is subject to the same open review and consensus process as used
 to produce and publish all other IETF specifications.
 The registration process is a purely mechanical process, in which the
 existence of the newly designated Special-Use Domain Name is
 recorded, with a pointer to a section in the relevant specification
 document that defines the ways in which special handling is to be
 applied to the name.
 RFC 6761 provides the process whereby "Multicast DNS" [RFC6762]
 designated '.local' as a Special-Use Domain Name and included it in
 the "Special-Use Domain Names" registry.  RFC 6761 also enumerates a
 set of names that were previously used or defined to have special
 uses prior to its publication.  Since there had been no registry for
 these names prior to the publication of RFC 6761, the documents
 defining these names could not have added them to the registry.
 Several important points to think about with respect to RFC 6761 are:
 o  A Special-Use Domain Name may be a name that should be resolved
    using the DNS protocol with no special handling.  An example of
    this is 'in-addr.arpa' (which is an example of a Special-Use
    Domain Name that is not a TLD).

Lemon, et al. Informational [Page 12] RFC 8244 Special-Use Domain Names Problem October 2017

 o  A Special-Use Domain Name may be a name that is resolved using the
    DNS protocol and that requires no special handling in the stub
    resolver but that requires special handling in the recursive
    resolver.  An example of this would be '10.in-addr.arpa.'.
 o  A Special-Use Domain Name may be a name that requires special
    handling in the stub resolver.  An example would be a Special-Use
    Top-Level Domain Name like '.local', which acts as a signal to
    indicate that the local stub resolver should use a non-DNS
    protocol for name resolution.
 o  The current IETF consensus (from a process perspective, not
    necessarily from the perspective of what would be consensus if the
    IETF were to attempt to produce a new consensus document) is that
    all of these purposes for Special-Use Domain Names are valid.
 In this case, the term "stub resolver" does not mean "DNS protocol
 stub resolver".  The stub resolver is the entity within a particular
 software stack that takes a question about a domain name and answers
 it.  One way a stub resolver can answer such a question is using the
 DNS protocol; however, it is in the stub resolver (as we are using
 the term here) that the decision as to whether to use a protocol (and
 if so, which protocol) or a local database of some sort is made.
 RFC 6761 does not limit Special-Use Domain Names to TLDs.  However,
 at present, all Special-Use Domain Names registered in the "Special-
 Use Domain Names" registry [SDO-IANA-SUDR] either are intended to be
 resolved using the DNS protocol, are TLDs, or are both.  That is, at
 present there exist no Special-Use Domain Names that require special
 handling by stub resolvers and which are not at the top level of the
 naming hierarchy.
 One point to take from this is that there is already a requirement in
 RFC 6762 that when a stub resolver encounters the special label,
 'local' as the rightmost label of a domain name, it can only use the
 Multicast DNS (mDNS) protocol to resolve that domain name.

4.1.3. MoU Concerning the Technical Work of IANA

 There exists a Memorandum of Understanding (MoU) [RFC2860] between
 the IETF and ICANN that discusses how names and numbers will be
 managed through IANA.  This document is important to the discussion
 of Special-Use Domain Names because, while it delegates authority for
 managing the DNS Namespace generally to ICANN, it reserves to the
 IETF the authority that is then formalized in RFC 6761.  RFC 2860
 specifically states:

Lemon, et al. Informational [Page 13] RFC 8244 Special-Use Domain Names Problem October 2017

    Note that (a) assignments of domain names for technical uses (such
    as domain names for inverse DNS lookup), (b) assignments of
    specialised address blocks (such as multicast or anycast blocks),
    and (c) experimental assignments are not considered to be policy
    issues, and shall remain subject to the provisions of this
    Section 4.
 The above text is an addendum to the following:
    Two particular assigned spaces present policy issues in addition
    to the technical considerations specified by the IETF: the
    assignment of domain names, and the assignment of IP address
    blocks.  These policy issues are outside the scope of this MOU.
 The assignment of names in the DNS root zone, and the management of
 the Domain Namespace, is by default a function that is performed by
 ICANN.  However, the MoU specifically exempts domain names assigned
 for technical use and uses the example of domains used for inverse
 DNS lookup.  Both 'in-addr.arpa' and 'ip6.arpa' are in the "Special-
 Use Domain Names" registry.
 Implicit in the MoU is the fact that the IETF and ICANN retain,
 between them, sole authority for assigning any names from the Domain
 Namespace.  Both the IETF and ICANN have internal processes for
 making such assignments.
 The point here is not to say what the implications of this statement
 in the MoU are, but rather to call the reader's attention to the
 existence of this statement.

4.1.4. Liaison Statement on Technical Use of Domain Names

 When the IETF received processing requests to add names to the
 "Special-Use Domain Names" registry, as documented in [RESERVED-TLDS]
 and [P2P-DOMAIN-NAMES], the IETF chartered a review of the process
 defined in RFC 6761 for adding names to the registry (as explained
 earlier).  The IETF sent a liaison statement [SDO-IAB-ICANN-LS] to
 ICANN to notify them of the review, affirm that the discussion would
 be "open and transparent to participation by interested parties", and
 explicitly invite members of the ICANN community to participate.

Lemon, et al. Informational [Page 14] RFC 8244 Special-Use Domain Names Problem October 2017

4.1.5. IAB Statement on the Registration of Special Use Names in the

      ARPA Domain
 As part of the process of resolving the controversy mentioned in
 Section 4.2.7, the IAB issued a statement saying, in part:
 There is currently no process defined with ICANN for special use
 names to be delegated in the root zone; it has seemed likely to take
 significant effort to create one.  The IAB has noted that .arpa can
 be used "for technical infrastructure established by IETF standards"
 [SDO-IAB-SUDN-REG].
 Given the lack of an established process with ICANN, IETF documents
 cannot reserve names in the root of the DNS namespace if those names
 are to be delegated (that is, used by the DNS protocol).  It would be
 possible to work with ICANN to develop a process for such
 delegations, but the success of that joint work, and the amount of
 time it would take, would still be uncertain.

4.2. Secondary Documents Relating to the Special-Use Domain Name

    Question
 In addition to these documents, there are several others with which
 participants in this discussion should be familiar.

4.2.1. Multicast DNS

 Multicast DNS [RFC6762] defines the Multicast DNS protocol, which
 uses the '.local' Special-Use Top-Level Domain Name.  Section 3
 describes the semantics of "multicast DNS names".  It is of
 considerable historical importance to note that the -00 version of
 the document that eventually became RFC 6762, an individual
 submission, was published in July of 2001.  The version posted at
 that time contains substantially the same text in Section 3 as RFC
 6762 did when published and was discussed in the DNSEXT Working Group
 at IETF 51 in August of 2001 [IETF-PRO-51].  The July 2001 draft
 designated '.local.arpa' as the Special-Use Domain Name.  This idea
 was strongly opposed by DNSEXT Working Group participants, and as a
 result, the author eventually switched to using '.local'.
 The history of RFC 6762 is documented in substantial detail in
 Appendix H of RFC 6762; some notable milestones include the initial
 proposal to replace AppleTalk's Name Binding Protocol (NBP) in July
 1997, the chartering of the Zeroconf Working Group in September 1999,
 and the assignment of a multicast address for link-local name
 discovery in April of 2000.  A companion requirements document,
 eventually published as [RFC6760], was first published in September
 of 2001.

Lemon, et al. Informational [Page 15] RFC 8244 Special-Use Domain Names Problem October 2017

 The point of mentioning these dates is so that discussions involving
 the time when the '.local' domain was first deployed, and the context
 in which it was deployed, may be properly informed.

4.2.2. The '.onion' Special-Use Top-Level Domain Name

 The '.onion' Special-Use Top-Level Domain Name [RFC7686] is important
 because it is the most recent IETF action on the topic of Special-Use
 Domain Names; although it does not set a new policy, the mere fact of
 its publication is worth thinking about.
 Two important points to consider about this document are that:
 o  The IETF gained consensus to publish it.
 o  Devising a resolution to the situation was constrained by at least
    two factors.  First, there was no process for allocating Special-
    Use Domain Names at the time that the '.onion' project started
    using the name; at the time, and since the scope of use of the
    name was expected to be very constrained, the developers chose to
    allocate it unilaterally rather than asking the IETF or some other
    Standards Development Organization (SDO) to create a new process.
    Second, for some time, the CA/Browser Forum [SDO-CABF] had been
    issuing certificates for what they referred to as "internal
    names".  Internal names are names allocated unilaterally for use
    in site-specific contexts.  Issuing certificates for such names
    came to be considered problematic, since no formal process for
    testing the validity of such names existed.  Consequently, the CA/
    Browser Forum decided to phase out the use of such names in
    certificates [SDO-CABF-INT] and set a deadline after which no new
    certificates for such names would be issued [SDO-CABF-DEADLINE].
    Because the '.onion' domain was allocated unilaterally, this would
    mean that certificates for subdomains of '.onion' could no longer
    be issued.
    The IETF's designation of '.onion' as a Special-Use Top-Level
    Domain Name was needed to facilitate the development of a
    certificate issuance process specific to '.onion' domain names
    [SDO-CABF-BALLOT144].

4.2.3. Locally Served DNS Zones

 "Locally Served DNS Zones" [RFC6303] describes a particular use case
 for zones that exist by definition and that are resolved using the
 DNS protocol, but that cannot have a global meaning because the host
 IP addresses they reference are not unique.  This applies to a
 variety of addresses, including private IPv4 addresses [RFC1918],

Lemon, et al. Informational [Page 16] RFC 8244 Special-Use Domain Names Problem October 2017

 "Unique Local IPv6 Unicast Addresses" [RFC4193] (in which this
 practice was first described), and "IANA-Reserved IPv4 Prefix for
 Shared Address Space" [RFC6598].
 This use case is distinct from the use case for Special-Use Domain
 Names like '.local' and '.onion' in that the names are resolved using
 the DNS protocol (but they do require extensions or exceptions to the
 usual DNS resolution to enforce resolution in a local context rather
 than the global DNS context).  It shares the problem that such names
 can be assumed neither to be unique across all contexts nor
 functional for all Internet-connected hosts.

4.2.4. Name Collision in the DNS

 "Name Collision in the DNS" [SDO-ICANN-COLL] is a study that was
 commissioned by ICANN in an attempt to characterize the potential
 risk to the Internet of adding global DNS delegations for names that
 were not previously delegated in the DNS and were not reserved under
 any RFC, but were also known to be (in the case of '.home') or
 surmised to be (in the case of '.corp') in significant use for
 Special-Use-type reasons (local scope DNS or other resolution
 protocols altogether).

4.2.5. SSAC Advisory on the Stability of the Domain Namespace

 The ICANN Security and Stability Advisory Committee (SSAC)
 [SDO-ICANN-SSAC] specification "SSAC Advisory on the Stability of the
 Domain Namespace" [SDO-ICANN-SAC090] reports on some issues
 surrounding the conflicting uses, interested parties, and processes
 related to the Domain Namespace.  The specification recommends the
 development of collaborative processes among the various interested
 parties to coordinate their activities related to the Domain
 Namespace.

4.2.6. Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis

 "Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis"
 [RFC7050] is an example of a document that successfully used the
 process in RFC 6761 to designate '.ipv4only.arpa' as a Special-Use
 Domain Name; in this case, the process worked smoothly and without
 controversy.
 Unfortunately, while the IETF process worked smoothly, in the sense
 that there was little controversy or delay in approving the new use,
 it did not work correctly: the name 'ipv4only.arpa' was never added
 to the "Special-Use Domain Names" registry.  This appears to have
 happened because the document did not explicitly request the addition
 of an entry for 'ipv4only.arpa' in the "Special-Use Domain Names"

Lemon, et al. Informational [Page 17] RFC 8244 Special-Use Domain Names Problem October 2017

 registry.  This is an illustration of one of the problems that we
 have with the process in RFC 6761: it is apparently fairly easy to
 miss the step of adding the name to the registry.

4.2.7. Additional Reserved Top-Level Domains

 "Additional Reserved Top Level Domains" [RESERVED-TLDS] is an example
 of a document that attempted to reserve several TLDs identified by
 ICANN as particularly at risk for collision as Special-Use Domain
 Names with no documented use.  This attempt failed.
 Although the aforementioned document failed to gain consensus to be
 published, the need it was intended to fill still exists.
 Unfortunately, although a fair amount is known about the use of these
 names, no RFC exists that describes how they are used and why it
 would be a problem to delegate them.  Additionally, to the extent
 that the uses being made of these names are valid, no document exists
 indicating when it might make sense to use them and when it would not
 make sense to use them.
 RFC 7788 [RFC7788] defines the Top-Level Domain Name '.home' for use
 as the default name for name resolution relative to a home network
 context.  Although, as defined in RFC 7788, '.home' is a Special-Use
 Domain Name, RFC 7788 did not follow the process specified in RFC
 6761: it did not request that '.home' be added to the "Special-Use
 Domain Names" registry.  This was recognized as a mistake and
 resulted in the posting of an errata report [Err4677].  Additionally,
 '.home' is an example of an attempt to reuse a domain name that has
 already been put into use for other purposes without following
 established processes [SDO-ICANN-COLL], which further complicates the
 situation.  At the time RFC 8244 was written, the IETF was developing
 a solution to this problem.

5. History

 A newcomer to the problem of resolving domain names may be under the
 impression that the DNS sprang fully formed directly from Paul
 Mockapetris' head (as was the birth of Athena in Greek Mythology).
 This is not the case.  At the time the IAB technical document was
 written [RFC2826], memories would have been fresh of the evolutionary
 process that led to DNS' dominance as a protocol for domain name
 resolution.
 In fact, in the early days of the Internet, hostnames were resolved
 using a text file, HOSTS.TXT, which was maintained by a central
 authority, the Network Information Center, and distributed to all
 hosts on the Internet using the File Transfer Protocol (FTP)

Lemon, et al. Informational [Page 18] RFC 8244 Special-Use Domain Names Problem October 2017

 [RFC959].  The inefficiency of this process is cited as a reason for
 the development of the DNS [RFC882] [RFC883] in 1983.
 However, the transition from HOSTS.TXT to the DNS was not smooth.
 For example, Sun Microsystems' Network Information System (NIS)
 [CORP-SUN-NIS], at the time known as Yellow Pages, was an active
 competitor to the DNS, although it failed to provide a complete
 solution to the global naming problem.
 Another example was NetBIOS Name Service, also known as WINS
 [RFC1002].  This protocol was used mostly by Microsoft Windows
 machines, but also by open-source BSD and Linux operating systems to
 do name resolution using Microsoft's own name resolution protocol.
 Most modern operating systems can still use the '/etc/hosts' file for
 name resolution.  Many still have a name service switch that can be
 configured on the host to resolve some domains using the NIS or WINS.
 Most have the capability to resolve names using mDNS by recognizing
 the special meaning of the '.local' Special-Use Top-Level Domain
 Name.
 The Sun Microsystems model of having private domains within a
 corporate site, while supporting the global Domain Name System for
 off-site, persisted even after the NIS protocol fell into disuse.
 Microsoft used to recommend that site administrators use a "private"
 TLD for internal use, and this practice was very much a part of the
 zeitgeist at the time (see Section 5.1 of [SDO-ICANN-COLL] and
 Appendix G of [RFC6762]).  This attitude is at the root of the
 widespread practice of simply picking an apparently unused TLD and
 using it for experimental purposes, which persists even at the time
 of writing of this memo.
 This history is being presented because discussions about Special-Use
 Domain Names in the IETF often come down to the question of why users
 of new name resolution protocols choose to use domain names rather
 than using some other naming concept that doesn't overlap with the
 namespace that, in modern times is, by default, resolved using the
 DNS.
 The answer is that as a consequence of this long history of resolving
 domain names using a wide variety of name resolution systems, domain
 names are required in a large variety of contexts in user interfaces
 and applications programming interfaces.  Any name that appears in
 such a context is a domain name.  So, developers of new name
 resolution systems that must work in existing contexts actually have
 no choice: they must use a Special-Use Domain Name to segregate a
 portion of the namespace for use with their system.

Lemon, et al. Informational [Page 19] RFC 8244 Special-Use Domain Names Problem October 2017

6. Security Considerations

 This document mentions various security and privacy considerations in
 the text.  However, this document creates no new security or privacy
 concerns.

7. IANA Considerations

 This document does not require any IANA actions.

8. Informative References

 [CORP-SUN-NIS]
            Wikipedia, "Network Information Service", August 2017,
            <https://en.wikipedia.org/wiki/
            Network_Information_Service>.
 [DOMAIN-NAMES]
            Lewis, E., "Domain Names, A Case for Clarifying", Work in
            Progress, draft-lewis-domain-names-09, August 2017.
 [Err4677]  RFC Errata, "Erratum ID 4677", RFC 7788,
            <https://www.rfc-editor.org/errata/eid4677>.
 [IETF-PRO-51]
            IETF, "Proceedings of the 51st IETF Meeting", August 2001,
            <http://www.ietf.org/proceedings/51/51-45.htm#TopOfPage>.
 [P2P-DOMAIN-NAMES]
            Grothoff, C., Wachs, M., Wolf, H., Ed., Appelbaum, J., and
            L. Ryge, "Special-Use Domain Names of Peer-to-Peer
            Systems", Work in Progress, draft-grothoff-iesg-special-
            use-p2p-names-04, January 2015.
 [PROBLEM-SPECIAL-NAMES]
            Huston, G., Koch, P., Durand, A., and W. Kumari, "Problem
            Statement for the Reservation of Special-Use Domain Names
            using RFC6761", Work in Progress, draft-adpkja-dnsop-
            special-names-problem-06, September 2016.
 [RESERVED-TLDS]
            Chapin, L. and M. McFadden, "Additional Reserved Top Level
            Domains", Work in Progress, draft-chapin-additional-
            reserved-tlds-02, March 2015.

Lemon, et al. Informational [Page 20] RFC 8244 Special-Use Domain Names Problem October 2017

 [RFC882]   Mockapetris, P., "Domain names: Concepts and facilities",
            RFC 882, DOI 10.17487/RFC0882, November 1983,
            <https://www.rfc-editor.org/info/rfc882>.
 [RFC883]   Mockapetris, P., "Domain names: Implementation
            specification", RFC 883, DOI 10.17487/RFC0883, November
            1983, <https://www.rfc-editor.org/info/rfc883>.
 [RFC959]   Postel, J. and J. Reynolds, "File Transfer Protocol",
            STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985,
            <https://www.rfc-editor.org/info/rfc959>.
 [RFC1002]  NetBIOS Working Group in the Defense Advanced Research
            Projects Agency, Internet Activities Board, and End-to-End
            Services Task Force, "Protocol standard for a NetBIOS
            service on a TCP/UDP transport: Detailed specifications",
            STD 19, RFC 1002, DOI 10.17487/RFC1002, March 1987,
            <https://www.rfc-editor.org/info/rfc1002>.
 [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
            STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
            <https://www.rfc-editor.org/info/rfc1034>.
 [RFC1035]  Mockapetris, P., "Domain names - implementation and
            specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
            November 1987, <https://www.rfc-editor.org/info/rfc1035>.
 [RFC1918]  Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
            and E. Lear, "Address Allocation for Private Internets",
            BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
            <https://www.rfc-editor.org/info/rfc1918>.
 [RFC2352]  Vaughan, O., "A Convention For Using Legal Names as Domain
            Names", RFC 2352, DOI 10.17487/RFC2352, May 1998,
            <https://www.rfc-editor.org/info/rfc2352>.
 [RFC2826]  Internet Architecture Board, "IAB Technical Comment on the
            Unique DNS Root", RFC 2826, DOI 10.17487/RFC2826, May
            2000, <https://www.rfc-editor.org/info/rfc2826>.
 [RFC2860]  Carpenter, B., Baker, F., and M. Roberts, "Memorandum of
            Understanding Concerning the Technical Work of the
            Internet Assigned Numbers Authority", RFC 2860,
            DOI 10.17487/RFC2860, June 2000,
            <https://www.rfc-editor.org/info/rfc2860>.

Lemon, et al. Informational [Page 21] RFC 8244 Special-Use Domain Names Problem October 2017

 [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
            Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
            <https://www.rfc-editor.org/info/rfc4193>.
 [RFC6303]  Andrews, M., "Locally Served DNS Zones", BCP 163,
            RFC 6303, DOI 10.17487/RFC6303, July 2011,
            <https://www.rfc-editor.org/info/rfc6303>.
 [RFC6598]  Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and
            M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address
            Space", BCP 153, RFC 6598, DOI 10.17487/RFC6598, April
            2012, <https://www.rfc-editor.org/info/rfc6598>.
 [RFC6760]  Cheshire, S. and M. Krochmal, "Requirements for a Protocol
            to Replace the AppleTalk Name Binding Protocol (NBP)",
            RFC 6760, DOI 10.17487/RFC6760, February 2013,
            <https://www.rfc-editor.org/info/rfc6760>.
 [RFC6761]  Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
            RFC 6761, DOI 10.17487/RFC6761, February 2013,
            <https://www.rfc-editor.org/info/rfc6761>.
 [RFC6762]  Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
            DOI 10.17487/RFC6762, February 2013,
            <https://www.rfc-editor.org/info/rfc6762>.
 [RFC7050]  Savolainen, T., Korhonen, J., and D. Wing, "Discovery of
            the IPv6 Prefix Used for IPv6 Address Synthesis",
            RFC 7050, DOI 10.17487/RFC7050, November 2013,
            <https://www.rfc-editor.org/info/rfc7050>.
 [RFC7686]  Appelbaum, J. and A. Muffett, "The ".onion" Special-Use
            Domain Name", RFC 7686, DOI 10.17487/RFC7686, October
            2015, <https://www.rfc-editor.org/info/rfc7686>.
 [RFC7719]  Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
            Terminology", RFC 7719, DOI 10.17487/RFC7719, December
            2015, <https://www.rfc-editor.org/info/rfc7719>.
 [RFC7788]  Stenberg, M., Barth, S., and P. Pfister, "Home Networking
            Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April
            2016, <https://www.rfc-editor.org/info/rfc7788>.
 [SDO-CABF] CA/Browser Forum, "CA/Browser Forum Home Page",
            <https://cabforum.org>.

Lemon, et al. Informational [Page 22] RFC 8244 Special-Use Domain Names Problem October 2017

 [SDO-CABF-BALLOT144]
            CA/Browser Forum, "Ballot 144 - Validation Rules for
            .onion Names", February 2015, <https://cabforum.org/2015/
            02/18/ballot-144-validation-rules-dot-onion-names>.
 [SDO-CABF-DEADLINE]
            CA/Browser Forum, "SSL Certificates for Internal Server
            Names", January 2013,
            <https://www.digicert.com/internal-names.htm>.
 [SDO-CABF-INT]
            CA/Browser Forum, "Guidance on the Deprecation of Internal
            Server Names and Reserved IP Addresses", June 2012,
            <https://cabforum.org/internal-names/>.
 [SDO-IAB-ICANN-LS]
            IETF, "Liaison Statement from the IAB to the ICANN Board
            on Technical Use of Domain Names", September 2014,
            <https://datatracker.ietf.org/liaison/1351>.
 [SDO-IAB-SUDN-REG]
            IAB, "Internet Architecture Board statement on the
            registration of special use names in the ARPA domain",
            March 2017, <https://www.iab.org/documents/
            correspondence-reports-documents/2017-2/iab-statement-on-
            the-registration-of-special-use-names-in-the-arpa-
            domain/>.
 [SDO-IANA-SUDR]
            IANA, "Special-Use Domain Names", <http://www.iana.org/
            assignments/special-use-domain-names>.
 [SDO-ICANN-COLL]
            Interisle Consulting Group, LLC, "Name Collision in the
            DNS", Version 1.5, August 2013, <https://www.icann.org/
            en/system/files/files/name-collision-02aug13-en.pdf>.
 [SDO-ICANN-DAG]
            ICANN, "gTLD Applicant Guidebook", Version 2012-06-04,
            June 2012, <https://newgtlds.icann.org/en/applicants/agb/
            guidebook-full-04jun12-en.pdf>.
 [SDO-ICANN-SAC090]
            ICANN Security and Stability Advisory Committee, "SSAC
            Advisory on the Stability of the Domain Namespace",
            ICANN SAC090, December 2016, <https://www.icann.org/en/
            system/files/files/sac-090-en.pdf>.

Lemon, et al. Informational [Page 23] RFC 8244 Special-Use Domain Names Problem October 2017

 [SDO-ICANN-SSAC]
            ICANN, "Security and Stability Advisory Committee (SSAC)",
            December 2016, <https://www.icann.org/groups/ssac>.
 [TOR]      Tor, "Tor - Anonymity Online",
            <https://www.torproject.org>.

Contributors

 Mark Andrews, Stuart Cheshire, David Conrad, Paul Ebersman, Aaron
 Falk, and Suzanne Woolf all made helpful and insightful observations
 or patiently answered questions.  This should not be taken as an
 indication that any of these folks actually agree with what the
 document says, but their generosity with time and thought are
 appreciated in any case.
 Stephane Bortzmeyer, John Dickinson, Bob Harold, Paul Hoffman, Russ
 Housley, Joel Jaeggli, Andrew McConachie, George Michaelson, Petr
 Spacek, and others provided significant review and/or useful
 comments.
 This document also owes a great deal to Ed Lewis' excellent work on
 what a "domain name" is [DOMAIN-NAMES].
 We would also like to acknowledge the authors of
 [PROBLEM-SPECIAL-NAMES], including Alain Durand, Geoff Huston, Peter
 Koch, and Joe Abley, for their efforts to frame the issues and engage
 the working group, as well as their contributions to the list of
 issues from their document [PROBLEM-SPECIAL-NAMES].

Lemon, et al. Informational [Page 24] RFC 8244 Special-Use Domain Names Problem October 2017

Authors' Addresses

 Ted Lemon
 Nominum, Inc.
 800 Bridge Parkway
 Redwood City, CA  94065
 United States of America
 Phone: +1 650 381 6000
 Email: ted.lemon@nominum.com
 Ralph Droms
 Email: rdroms.ietf@gmail.com
 Warren Kumari
 Google
 1600 Amphitheatre Parkway
 Mountain View, CA  94043
 United States of America
 Email: warren@kumari.net

Lemon, et al. Informational [Page 25]

/data/webs/external/dokuwiki/data/pages/rfc/rfc8244.txt · Last modified: 2017/10/19 19:44 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki