Some domains are too big to fail. Quite apart from the obvious ones like google.com and facebook.com, upon whose availability our everyday lives depends, there are many others upon which the infrastructure of the Internet (and much of the modern world itself) depends.

These are domains like w3.org and ietf.org, which host the technical specifications which describe the World Wide Web and the Internet themselves. iana.org hosts a number of critical protocol registries and databases. These domain names appear in XML namespaces and other protocol specifications, and their ongoing resolvability is key to these systems functioning as expected.

There are other examples. At the Domain Names and Persistence Workshop, which took place at the 7th International Digital Curation Conference in Bristol last week, I heard from representatives of organisations such as CNRI (which operates the Handle.net system) and the International DOI Foundation (which runs doi.org). These systems underpin much of the infrastructure of our modern interconnected life: the DOI system, for example, through CrossRef, is the standardised method by which scientists refer to the work of their peers in their papers. These references need to be persistent over the long-term (digital archivists like to think on the scale of centuries) in order for the work of modern academia to continue, and for future generations to access and understand the development of scientific knowledge.

These organisations are worried that their dependence on plain old domain names under traditional gTLDs and ccTLDs presents a threat to the stable operation of these systems: despite doing everything possible to ensure the ongoing function of these domains, they remain at risk from everything from failing to pay renewal fees, domain hijacking, to having their parent TLD shut down. One of the key questions the workshop tried to ask was: how can we make these domains truly persistent over the long term?

Several options were discussed as possible solutions. The first and most obvious solution is to ask ICANN to “gold plate” these domains, to make sure that they’re never accidentally deleted, transferred or otherwise interfered with. Anyone who reads CircleID will probably have a good idea exactly how difficult, time-consuming and unlikely to succeed this approach would be.

Furthermore, it would be rightly argued that creating “gold-plated” (or perhaps “armour-plated”) domains would be the thin end of the wedge: while it may be reasonable to protect w3.org on the grounds of protecting the infrastructure of the Web, wouldn’t it also be legitimate to offer similar protection for google.com? it may be just as critical (if not even more so), and if that is the case, why not also microsoft.com, ibm.com and any of thousands of other corporate domains?

Another solution would be the establishment of a TLD specifically for domains that are “too big to fail”. While some of the attendees discussed submitting an application for a generic TLD in the upcoming application round, it was pointed out that such an “infrastructure TLD” already exists: the Address Routing and Parameter Area, .ARPA.

.ARPA was the first ever top-level domain, used to migrate Arpanet hosts onto the modern Internet. After this had been accomplished it was repurposed as the root of the Reverse DNS (i.e. numbers to names) system. It is now also used by the eNUM system and the little-used Whois replacement protocol, IRIS.

Management of .ARPA is governed by RFC 3172, which states:

This domain is termed an “infrastructure domain”, as its role is to support the operating infrastructure of the Internet. In particular, the “arpa” domain is not to be used in the same manner (e.g., for naming hosts) as other generic Top Level Domains are commonly used. The operational administration of this domain, in accordance with the provisions described in this document, shall be performed by the IANA under the terms of the MoU between the IAB and ICANN concerning the IANA.

Delegations under .ARPA can only be requested by the publication of a “Standards Track” RFC - a very high barrier to entry. Nevertheless, many of the systems (such as handle.net) which are under consideration are already specified in RFC documents, which could be amended to include an “IANA Considerations” section. In fact, RFC 3172 states that

Any infrastructure domains that are located elsewhere in the DNS tree than as sub-domains of “arpa”, for historical or other reasons, should adhere to all of the requirements established in this document for sub-domains of “arpa”, and consideration should be given to migrating them into “arpa” as and when appropriate.

Which strongly implies that domains that are critical to the operation of the Internet’s infrastructure are expected to migrate to .ARPA.

Enhancing the security and stability of critical elements of the Internet’s infrastructure is precisely what .ARPA is intended to do. At the conclusion of the workshop there seemed to be a consensus that such an approach offered the best chance of a workable solution to the issue of domain name persistence.