By: Peter Koch
Date: April 17, 2016
In October 2015, just prior to IETF 94, publication of “The .onion Special-Use Domain Name” (RFC 7686) put an end to intense debate within the Domain Name System Operations (DNSOP) working group (WG) and the wider IETF community. RFC 7686 added the “onion” label to the Special-Use Domain Names registry maintained by the Internet Assigned Numbers Authority (IANA). This was the second addition to that registry after RFC 6762 to reserve “local” for the Multicast DNS protocol.
A blog post by IETF Chair Jari Arkko explained the details and external dependencies of the Certificate Authority system that led to the approval, while also suggesting that the registration procedure laid out in RFC 6761 needed review and action.
The first and last time that the IETF reserved top-level domain names under its formal standardization process was in 1999, when RFC 2606 reserved “test”, “example”, and “invalid”, for test and documentation purposes and “localhost” to document operational practices. This was done in light of the recently founded Internet Corporation for Assigned Names and Numbers (ICANN) opening the first round of top-level domains.
A few months later and within the same historic context, the Internet Architecture Board (IAB) published “IAB Technical Comment on the Unique DNS Root” (RFC 2826) and the “Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority” (RFC 2860) was achieved between the IETF and ICANN. The following excerpt from the Memorandum clearly separates the roles regarding domain names:
4.3. 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.
Note that (a) assignments of domain names for technical uses (such as domain names for inverse DNS lookup), (b) assignments of specialized 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. (For the purposes of this MoU, the term “assignments” includes allocations.)
In the event ICANN adopts a policy that prevents it from complying with the provisions of this Section 4 with respect to the assignments described in (a) – (c) above, ICANN will notify the IETF, which may then exercise its ability to cancel this MoU under Section 2 above.
Another year later, in September 2001, the ARPA top-level domain, initially named after the Advanced Research Projects Agency (ARPA) was renamed the Address and Routing Parameter Area Domain and the IAB took responsibility and published a registration policy in RFC 3172.
In 2011, the DNSOP working group published “Locally Served DNS Zones” (RFC 6303) to establish an IANA registry of DNS zones that every recursive resolver should serve from local knowledge, instead of following the normal DNS delegation path. The registry was seeded with various domains in the IN-ADDR.ARPA and IP6.ARPA reverse mapping space, particularly for private addresses of RFC 1918, where there cannot exist a globally unique mapping due to multiple independent instances of the same IP address. This was done primarily to reduce the DNS load on the sacrificial servers of the so-called AS112 project. The domains reserved in RFC 2606 deliberately were not imported into the new registry.
In early 2013, the IETF published “Special-Use Domain Names” (RFC 6761), which established a new registry quite similar to that initiated by RFC 6303. Names (and their descendants) in the new Special-Use Domain Names registry would be considered non-DNS names and their resolution would be redirected to other mechanisms before they were fed into the local DNS resolver:
[…] Hence, the act of defining such a special name creates a higher-level protocol rule, above ICANN’s management of allocable names on the public Internet.
In other words, these names would be greyed out of the Domain Name System and thus any registration within the DNS would not make sense, since compliant resolvers would never even try to resolve them the generic way.
RFC 6762, specifying Multicast DNS, then added the “local” TLD to the new registry that had been seeded with domains from RFC 2606. It should be noted that neither “local” nor any other TLD will be subject to a DNS delegation in the public DNS tree. Quite the opposite: it is expected that presence in the Special-Use Domain Names registry will prevent any such delegation.
Several questions arose around the procedure in RFC 6761, some of which will require wider community discussion:
Is the registration available for protocols not under IETF change control? RFC 6761 specifiesStandards Action or IESG Approval as the registration policy for Special-Use Domain Names, where RFC 5226 states that the latter should be a rare exception to the former only. How should the eligibility criteria for non-IETF protocols be defined?
Are the seven questions meant as criteria or as directions? RFC 6761 gives seven different entities that may need to implement special treatment of a Special-Use Domain Name, including application software, stub and recursive resolvers, and authoritative DNS servers. It also suggests that if there is no special handling by any of the seven, the registration might not be useful. However, no guidance is given to assess treatment of how many of the entities ought to be necessary or sufficient for registration and what alternate approaches might be chosen.
Can the Special-Use Domain Names registry keep its promise? Following from the previous question, how would software compliant with RFC 6761 learn the existence of a future Special-Use Domain Name and the special handling required? This is even more important if leaking DNS queries into the Internet is to be avoided for security reasons, as in the case of “onion”.
How will consistency with RFC 2826 and RFC 2860 be maintained? Can the emerging view of the existence of domain names that are not DNS names be made consistent with the uniqueness postulate expressed in RFC 2826? What mechanisms exist or need to exist to avoid conflicts between registrations under RFC 6761 and (future) ICANN TLD application rounds?
Since names have a tendency towards controversy, there are also the questions of who is going to determine the exact name at what stage in the process and whether a whole subtree of the DNS could be safely set aside for the intended purpose. The risk for the IETF is that it might find itself entangled in a mesh of legal and economic challenges without access to the resources necessary to inform or defend its decisions.
A detailed discussion will take place in the DNSOP WG. In addition, the ARCING BoF will address the question of signaling other resolution contexts beyond the Internet’s Domain Name System.