Some domains are too big to fail. Apart from the obvious ones like google.com and facebook.com, upon which the availability of our daily lives depends, there are many others upon which the internet infrastructure (and much of the modern world itself depends). same).
These are domains like w3.org and ietf.org, which host the technical specifications that describe the World Wide Web and the Internet themselves. iana.org hosts a number of protocol registries and critical databases. These domain names appear in XML namespaces and other protocol specifications, and their continued resolvability is essential for these systems to function as intended.
There are other examples. At the Domain Names and Persistence Workshop, which took place at the 7th International Digital Preservation Conference in Bristol last week, I heard from representatives of organizations such as NCRI (which operates the Handle.net system) and the DOI International Foundation (which manages doi .org). These systems underpin much of the infrastructure of our modern interconnected life: the DOI system, for example, via CrossRef, is the standardized method by which scientists refer to the work of their peers in their papers. These references must be persistent over the long term (digital archivists like to think of the scale of centuries) for the work of modern universities to continue and for future generations to access and understand the evolution of scientific knowledge.
These organizations fear that their dependence on legacy domain names under traditional gTLDs and ccTLDs poses a threat to the stable functioning of these systems: despite doing everything to ensure the continued functioning of these domains, they remain exposed to everything from failure to pay renewal fees, domain hacking, closing their parent TLDs. One of the key questions the workshop tried to ask was: how can we make these areas truly persistent over the long term?
Several options were discussed as possible solutions. The first and most obvious solution is to ask ICANN to âoutrankâ these domains, to ensure that they are never accidentally deleted, transferred, or otherwise interfered with. Anyone who reads CircleID will probably have a good idea how difficult, time-consuming, and unlikely to be successful this approach would be.
Further, it would be rightly argued that creating “gold plated” (or perhaps “plated over shield”) domains would be the thinnest point of the corner: while it may be reasonable to protect w3.org for reasons of infrastructure protection. web, wouldn’t it also be legitimate to offer similar protection for google.com? it can be just as critical (if not more), and if so, why not also microsoft.com, ibm.com, and one of the thousands of other corporate domains?
Another solution would be to create a TLD specifically for “too big to fail” domains. While some of the participants discussed submitting an application for a Generic TLD in the next round of applications, it was pointed out that such an âinfrastructure TLDâ already exists: the routing and settings area. address, .ARPA.
.ARPA was the very first top-level domain, used to migrate Arpanet hosts to the modern Internet. After this was accomplished, it was reused as the root of the reverse DNS system (i.e. from numbers to names). It is now also used by the eNUM system and the little used Whois replacement protocol, IRIS.
The management of .ARPA is governed by RFC 3172, which states:
This domain is called an âinfrastructure domainâ because its role is to support the operating infrastructure of the Internet. In particular, the “arpa” domain should not be used in the same way (eg, to name hosts) that other generic top level domains are commonly used. The operational administration of this domain, in accordance with the arrangements described in this document, will be carried out by the IANA under the terms of the Memorandum of Understanding between the IAB and ICANN regarding IANA.
Delegations under .ARPA can only be requested by issuing a âStandards Trackâ RFC – a very high barrier to entry. However, many systems (such as handle.net) that are under review are already specified in RFC documents, which could be amended to include an âIANA Considerationsâ section. In fact, RFC 3172 states that
All infrastructure domains located elsewhere in the DNS tree than as subdomains of “arpa”, for historical or other reasons, must adhere to all requirements set out in this document for subdomains of ” arpa â, and consideration should be given to migrate them intoâ arpa âas needed.
This strongly implies that the domains essential to the functioning of the Internet infrastructure should migrate to .ARPA.
Improving the security and stability of critical pieces of the Internet’s infrastructure is precisely what .ARPA is intended to do. At the end of the workshop, there seemed to be a consensus that such an approach offered the best chance of a viable solution to the domain name persistence problem.