The US government has posted a step-by-step guide to how it authorizes changes to the internet's root zone – the heart of the world's domain-name system.
The 16-page slide deck [PDF] published by the Department of Commerce's National Telecommunications and Information Administration (NTIA) sheds light on what has been a contentious and largely secret process for the past 15 years.
It also comes as an official proposal to move control of the global DNS away from the US government has been put out for public comment.
That proposal was drafted by a group that, it seems, didn't ask the NTIA how it carried out its job overseeing the world's DNS, leading to a complex and bureaucratic solution to a simple technical function.
The NTIA's guide – which appears to confirm that it does indeed only play a "clerical role" when it comes to making changes to the top-level of the internet – may rebalance the internet community's proposal in favor of a more lightweight system.
The guide addresses only the "naming" aspect of the IANA functions contract, and separates that out into two threads: a root zone file change; and a root zone Whois change.
The former deals with changes to top-level domain registries – such as dot-com, dot-uk, and so on – and the latter covers who is named as the person responsible for those registries.
When you look up, say, google.com in your web browser, the software needs an IP network address to contact. Your browser can ask* a root server for the systems responsible for looking up dot-coms; the servers handling .com lookups will then tell your browser which IP addresses to use to contact the google.com website servers.
Changes to the root zone can therefore have a phenomenal effect on the global structure of the internet, and it is therefore highly guarded; it's the very top level of the internet, defining who controls .com to .edu to .mil to .uk to .ca to .nz. See here [PDF] for more background.
For root zone file changes, the NTIA receives a request from the IANA contract operator (ICANN) and authorizes US company Verisign to make a change to the internet's root servers; for root zone Whois changes, the NTIA authorizes ICANN directly to make the change.
In both cases, the NTIA notes that its role is "clerical and administrative" and says its role is "limited to verifying that processes, procedures, and policies are followed; and providing authorization to implement or proceed with requests based on that verification." Its involvement is "judgment free with regards to content."
The deck then walks through the current process, where it receives secure email from ICANN – it even handily including examples email formats – checks to see that ICANN has self-certified that it has followed its own processes, and if so authorizes the change. When it comes to a Whois change, the NTIA checks that there are no errors in the request before it authorizes a change.
Overall the process is strikingly simple, which makes it all the more extraordinary that it has been the focus of numerous international conferences and even a World Summit. Governments across the world have been concerned that the US government could theoretically knock their individual internet registries offline.
What the slide deck also does is focus attention on the organization that makes the changes: ICANN. Even though the system has been running with no apparent problems for over a decade, the fact ICANN has to receive authorization for each change has kept it in check.
For the US government's role to be "transitioned" to an outside body, many believe ICANN's accountability needs to be greatly improved however, especially if the key part of the IANA contract relies on self-certification of processes. The US administration has been edging out of its role as internet overlord since 2006 – well before a whistleblower called Ed Snowden turned up to make life awkward for Uncle Sam.
The NTIA also gives a small insight into the volume of requests that are dealt with. For last month, November 2014, it received 47 root zone file changes; 30 root Whois changes; and 22 delegation or re-delegation requests. Its response time was between one and 24 hours, the agency self-reported. ®
* Yes, typically the browser asks the underlying OS or a library to resolve domain names, and yes, that information is usually cached. This is just a simplified example.