Big question of the day: Is it time to lock down .localhost?

A proposal to tightly lock down localhost as a reserved top-level domain name has bubbled up to the surface again at the Internet Engineering Task Force.

The hostname localhost is used just about everywhere: it's useful for referring to the computer you're using in front of you, or whatever machine a piece of software is running on. It's useful during the development of applications and networked systems. So useful, in fact, that it is one of a very few "special" names given formal protection on the internet (the others being "test," "example," and "invalid").

But, as Google engineer Mike West noted in September last year, the protections in place may not be sufficiently strict. The relevant RFCs covering use of localhost say that the IPv4 block 127.0.0.1/8 and IPv6 block ::1/128 are reserved as loopback addresses: packets to these addresses stay on the local machine, aka the localhost. This localhost name and any names falling within .localhost are reserved, and that programmers can "assume that IPv4 and IPv6 address queries for localhost names will always resolve to the respective IP loopback address."

Thus, software connecting to localhost should resolve to, say, 127.0.0.1, and therefore connect to the host machine.

This may seem tickety-boo, but it doesn't seem very concrete – particularly when you realize that software is expected to run localhost past DNS resolvers to look up, which are expected to return a loopback address, such as 127.0.0.1. That has resulted, West claims, in people hardcoding localhost to 127.0.0.1 in their system configurations to ensure an external resolver doesn't hijack localhost.

Great. So what? Well, the inclusion of a hardcoded IPv4 address is only going to cause problems down the line as we slowly move to IPv6. It's just bad engineering.

And so West proposes cleaning up the situation by giving .localhost special status similar to the .onion top-level domain, and making sure that those addresses never resolve to anything but loopback addresses, giving people greater confidence in the inherent security of localhost addresses.

And now implementation

Which all seems pretty reasonable and straightforward. Except this being the internet and the IETF, the question is not whether you should do it, but how. And that is where the problems start.

West put out a revised version of his draft proposal on Sunday, and is looking to move it forward to becoming an IETF standard. The new draft has already prompted online discussion.

The big question is whether, in order to ensure that "localhost" connections never reach out to the broader internet, you need to add the name to the internet's root servers.

And it turns out that there used to be exactly that – an entry in the root zone file for "localhost" that basically acted as a block. But as time went on and the internet tidied itself up, there was less and less need for it. And then along came DNSSEC, which added an extra layer of security onto the domain name system but isn't really good at handling top-level domains that aren't supposed to exist. So localhost got pulled out.

Some DNS veterans don't see the need for adding it back in. "There is no good reason to bring it back for special processing. It's just a string," complained one.

One advocate for the new RFC agrees that adding ".localhost" to the root zone is a bad idea "because it would mask implementation errors" – any accidental live connections should get an error.

And that is the problem with tweaking anything on the internet when it is widely used in so many different ways across so many systems. Even the slightest change will break something somewhere.

Interestingly, where this localhost discussion ends up will probably be indicative of a much bigger issue: how important is IPv6 transition to internet engineers? ®