
Internet Draft: Let 'localhost' be localhost - beliu
https://tools.ietf.org/html/draft-west-let-localhost-be-localhost-04
======
user5994461

       First, the lack of confidence that "localhost" actually resolves to
       the loopback interface encourages application developers to hard-code
       IP addresses like "127.0.0.1" in order to obtain certainty regarding
       routing.  This causes problems in the transition from IPv4 to IPv6
       (see problem 8 in [draft-ietf-sunset4-gapanalysis]).
    

That does remind me of the times I was dealing with weird connection issues in
some critical services.

It turned to be related to the use of "localhost" in the configuration. It
resolves to ipv6 on some systems and that breaks everything because the target
app is only listening to the ipv4 address.

Went as far as removing all references to localhost and added lint errors in
the configuration system so that noone could ever be able to give localhost as
a setting in anything.

~~~
deathanatos
> _and that breaks everything_

If you're on a POSIX system, I'd argue that this is a bug in the client.
Typically, the client should call getaddrinfo(3); as part of that, the
application would either specify directly that it's only interested in AF_INET
results, or just filter out non-AF_INET results.

(Further, if you support IPv6 in the client, and thus request such results
from getaddrinfo, you should skip to the next result if the connection fails.)

On the server, you can also bind to both the IPv4 and the IPv6 addresses. If
you listen to ::, you should get IPv4 connections too. (Through this[1]
mechanism.)

[1]:
[https://en.wikipedia.org/wiki/IPv6_address#Transition_from_I...](https://en.wikipedia.org/wiki/IPv6_address#Transition_from_IPv4)

~~~
kbutler
Does it matter if it's a bug in the client?

Make it work like expected.

Especially when changing infrastructure like IPV4->IPV6 - don't break existing
userbase code! (This is a fundamental precept of Linux development.)

~~~
frubar
Only in software development are we expected to go out of our way to support
people who don't know what they're doing. Imagine a medical student
complaining the professor that the scalpel doesn't cut on the dull end or a
would-be airline pilot upside down in their seat complaining he can't reach
the controls.

And your comment about never breaking existing userbase code is as ridiculous
as it is unreasonable. This would only be a reasonable expectation if only
correct code were possible to run. Since it's possible to run broken code (as
this anecdote demonstrates) then it must be possible to fix the system even if
that breaks some poorly written, but popular systems.

Does anyone want a world of e.g. Windows where decades old bugs have to be
replicated because we can't dare break programs so old all the authors are
retired or dead? I don't. Backwards compatibility has a cost and I'm not
willing to pay it unconditionally.

------
nhance
If this doesn't happen or takes too long, there's always lacolhost.com and
*.lacolhost.com. I own this domain, have registered it out until 2026 and vow
that the domain and all subdomains will always redirect to localhost.

It's easy to type and easy to remember and should always do a good job of
expressing intent of usage.

~~~
mholt
I don't think (?) I've ever made this typo. How many hits do you get?

(I feel like "ocalhost", "locahost", or "localhos" would be more common
typos.)

~~~
sillysaurus3
localhost would be a good name for a bar in SF.

~~~
dewiz
The anagram alcolhost would be a nice one too

~~~
kyle-rb
"St Alcohol" and "Alcohol St" are also good anagrams

~~~
such_a_casual
Did you think of that on your own? God I feel dumb. (I like being made to feel
dumb) I googled it and didn't get that answer. I guess remembering ST can be a
street or saint is a good rule.

------
DonHopkins
There was the time that Keith Henson tried to explain the local loopback
address to Scientology lawyers during a deposition...

[http://www.cryonet.org/cgi-bin/dsp.cgi?msg=6289](http://www.cryonet.org/cgi-
bin/dsp.cgi?msg=6289)

Henson: (patiently) It's at 127.0.0.1. This is a loop back address. This is a
troll.

Lieberman: what's a troll?

Henson: it comes from the fishing where you troll a bait along in the water
and a fish will jump and bite the thing, and the idea of it is that the
internet is a very humorous place and it's especially good to troll people who
don't have any sense of humor at all, and this is a troll because an ftp site
of 127.0.0.1 doesn't go anywhere. It loops right back around into your own
machine.

[https://en.wikipedia.org/wiki/Keith_Henson](https://en.wikipedia.org/wiki/Keith_Henson)

~~~
wyldfire
What's the "'ho" referred to? An alias for Scientology/SeaOrg, or a particular
individual?

------
jonathonf
I've had web browsers perform a web search for 'localhost', or even just
redirect me to localhost.com.

Annoying.

~~~
tambourine_man
Yeah. The ancients speak of a time when address and search bars where
separated.

I think it's a legend.

~~~
coltonv
I remember this. Also, if I remember correctly, seamlessly integrating search
and address bar was the thing that really made Chrome take off. Sure, it was
an all around better product than IE/Safari, but to get people to actually
download it over just using the default requires it to be significantly more
convenient, and it sure was.

~~~
flukus
>Also, if I remember correctly, seamlessly integrating search and address bar
was the thing that really made Chrome take off.

That was part of it. What's weird is that the Mozilla suite had the same thing
before firefox even existed, in many ways firefox was a step backward. I
believe opera did this years earlier too.

------
tcbawo
At work someone once spent hours trying to resolve a network issue. Turns out
he didn't have a localhost entry in his /etc/hosts and some sadistic person
had created a VM named 'localhost' that registered a DNS entry via DHCP.

~~~
lloeki
A similar, common issue is to not have the machine's hostname pointing to a
valid IP address in /etc/hosts (99% of the time it should be loopback, some
like to point it to a fixed eth0 address), which causes delays in various part
of an otherwise fine OS.

~~~
yrro
nss_myhostname fixes this without you having to modify /etc for every host.

------
feelin_googley
At least on the OS I use, which is more IPv6 ready than most, /etc/hosts
solves this "uncertainty" problem.

I have found that failing to include a localhost entry in the HOSTS file can
lead to some strange behavior.

If there are "computers" out there that have no /etc/hosts or deny the
computer's owner access to it, then maybe it might be time for an Internet
Draft from Joe User.

There should always be a mechanism for the user to override the internet DNS.
And applications should continue to respect it.

~~~
cbhl
I remember in the late 90s running into a "mysterious" problem where
www.hotmail.com would fail to load, but hotmail.com (without www.) worked just
fine.

Spent the better part of a year just remembering to not type "www." until one
day they made the domain redirect to the canonical name (breaking both).

After asking around a bit, someone showed me where the Windows equivalent of
/etc/hosts was, and lo-and-behold, there was an outdated entry for
www.hotmail.com there. Deleting the offending line fixed the problem.

Desktop computers are actually the odd one out in letting people manually
override DNS -- if you want to fix the DNS for a phone or smart tv or
thermostat or video game console, you need to configure DHCP and a resolver on
a router in the middle.

~~~
wolfgang42
_> the Windows equivalent of /etc/hosts_

Which is, bizarrely, etc\hosts (somewhere in C:\Windows\\). I've always
wondered why they felt the need to make an 'etc' folder just to have the hosts
file in it.

~~~
inopinatus
Software historians differ on the degree to which the Windows NT 3.1 TCP/IP
stack & utilities were derived from BSD, but it's one possible reason.

~~~
kagamine
A very diplomatic way of putting it.

------
zanchey
We have two entries in our DNS which point to 127.0.0.1/::1 - localhost and
elvis.

This enables the following on Solaris and similar systems:

    
    
      $ ping elvis
      elvis is alive

------
bryanrasmussen
this reminds me of a class I went to at a major company in 1999, we had
problems following the setup instructions which included going to
localhost/db-admin-path, after some sleuthing it turned out somebody 'in
corporate' on the network we were using had named their computer localhost.

------
inopinatus
I would very much like to see this draft extended to cover SRV lookup as well.

Right now, section 3 of this draft would prohibit all SRV queries for
localhost, which may hinder development and deployment of a SRV based
application. That's an immediate problem.

But not only are there existing applications to which it is immediately
applicable - it is a design error in HTTP that plain address records are used
for resolution. One day this will be corrected, in which case measures like
this should continue to apply.

~~~
JdeBP
Indeed.

* [http://jdebp.eu./FGA/dns-srv-record-use-by-clients.html](http://jdebp.eu./FGA/dns-srv-record-use-by-clients.html)

But what should such a standardized SRV lookup for __proto1_.
__proto2_.localhost. yield as the answer? For starters, what port numbers?

~~~
inopinatus
SRV lookup for localhost names should yield a (probably identical) localhost
name that (by the rest of this draft) necessarily then resolves to a loopback
address.

For ports we have the list of well-known services maintained by IANA, for
which an extract appears on many systems in /etc/services. Local configuration
can adjust as necessary.

~~~
JdeBP
Local configuration _cannot_ adjust as necessary. Remember: the headlined
article is something that is being proposed to fix into an RFC, and indeed the
whole point of it is to _hardwire_ something that, in fact, is currently a
matter of local configuration.

------
dmacedo
Also very important to point out; this same standardisation is missing on the
TLD level.

Both for safeguarding internal use, and making a global TLD reserved on the
global DNS zones. You'll find organisations using in production _.local_.dev
(Taken by Google on 2014-11-20, followed by .app in 2015) *.zone (Taken by a
LLC on 2014-01-09 ) as internal domains, with potential conflicts with the
Internet's DNS resolution.

More importantly .dev [1] and .zone [2] are now valid TLDs, so watch out
people!

[1]
[https://www.iana.org/domains/root/db/dev.html](https://www.iana.org/domains/root/db/dev.html)

[2]
[https://www.iana.org/domains/root/db/zone.html](https://www.iana.org/domains/root/db/zone.html)

~~~
TheAceOfHearts
IMO, a lot of these vanity TLDs are stupid and harmful to the web.

macOS has been using .app as its application extension for decades. Now when
you want to search for a specific app on the browser you'll have to be more
careful.

The fact that they allowed .dev, which is a fairly common TLD for development,
is pretty unbelievable.

I haven't seen any evidence that by allowing companies to register these TLDs
we've brought forth some kind of improvement or benefit to users.

There's a recent issue with TLDs that makes me particularly angry. There's
ongoing work on this homenet spec. Originally it proposed using .home to route
exclusively within the local network. But since .home is already used by a
large number of people for private purposes, they changed it to .home.arpa.
How the heck have we gotten to the point where we can justify allowing .google
as a TLD, but we can't reserve something nice and short for non-companies?

------
sgtpepper43
Just add a line your hosts file mapping lolcathost to 127.0.0.1 and you never
have to worry about it again.

No that's not a typo

------
chr1
Does this mean that an entry in /etc/hosts assigning ip to localhost will be
ignored?

~~~
xg15
Well, the explicit intent of the proposal is to hardwire the localhost =
127.0.0.1 / ::1 mapping, so my guess is yes.

~~~
inopinatus
That is not the effect of the draft. The effect is that localhost = lo0. Other
addresses are valid.

------
JdeBP
On the one hand, this isn't exactly a new idea and in the real world has been
happening for years now.

* dnscache from djbdns has handled "localhost." queries internally all along, since 1999. It maps "localhost." to 127.0.0.1 and bgack again. Various people, including me, have since added code to do the same thing with the mappings between "localhost." and ::1. ([http://jdebp.eu./Softwares/djbwares/guide/dnscache.html](http://jdebp.eu./Softwares/djbwares/guide/dnscache.html)) I implemented implicit localhost support in my proxy DNS servers for OS/2, as well.

* It is conventional good practice to have a db.127.0.0 and a master.localhost "zone" file on BIND that do this. This is in Chapter 4 of the book by Albitz and Liu, for example.

* Unbound has built-in "local zone" defaults mapping between "localhost." and both 127.0.0.1 and ::1.

On the other hand, this proposal explicitly rules out all of the
aforementioned existing practice, by demanding that both proxy and content DNS
servers instead return "no such domain" answers for the domain name
"localhost.". That seems like a fairly pointless deviation from what is fast
approaching two decades of existing practice, for which no rationale is given
and none is apparent.

------
ccheever
One time I was debugging a problem for a user of our desktop software (I work
on [https://expo.io](https://expo.io)) by sharing his screen and taking over
his computer. And it turned out the reason the user was having problems was
that in his /etc/hosts file, he had an entry pointing localhost at the IP
address of some other computer on his network. Crazy. I have no idea how
anything worked on his machine.

Took a while to track that was down. Was both bewildering and sort of
satisfying to figure it out in the end.

------
nailer
Surprised the more common .localdomain is omitted as a domain rather than
having a .localhost domain.

~~~
dredmorbius
or ".lan"

------
eduren
Can anybody with more knowledge point out techniques that this would break?

Are there any software or networking patterns that currently rely on localhost
_not_ resolving to the loopback?

EDIT: The RFC mentions that MySQL currently differentiates between the two,
but that's it.

~~~
hazeii
Within " _.localhost._ "...

www.localhost.mydomain.com?

~~~
xnxn
The trailing "." signifies the end of the domain name, so your example domain
would be unaffected.

~~~
hazeii
Thanks, I misread the draft as '<star>.localhost.<star>'(!)

------
filleokus

       The domain "localhost.", and any names falling within ".localhost.",
       are known as "localhost names".  Localhost names are special in the
       following ways […]
    

Is this not implemented on macOS or am I just misunderstanding?

    
    
         ~ ping test.localhost
       ping: cannot resolve test.localhost: Unknown host
         ~ ping localhost.test
       ping: cannot resolve localhost.test: Unknown host

~~~
tntniceman
As I understood it, that simply states that if any of those domains were
implemented, they should loopback, as opposed to all domains containing
"localhost" ARE implemented.

~~~
filleokus
Thank you for the clarification!

------
ericfrederich
Sounds reasonable, but would probably break a ton of stuff. Does this provide
enough benefits to outweigh the downsides?

~~~
agwa
What do you think might break?

~~~
tscs37
Badly written software will break.

Or software relying on badly written DNS resolvers.

------
age_bronze
There was no RFC for localhost yet?! That's pretty surprising... That this RFC
have any practical meaning? People didn't actually register localhost. domain,
did they? Is there an actual line of code that this should change? Are they
just trying to promote writing localhost instead of 127.0.0.1?

~~~
lightbyte
From the actual draft:

> First, the lack of confidence that "localhost" actually resolves to the
> loopback interface encourages application developers to hard-code IP
> addresses like "127.0.0.1" in order to obtain certainty regarding routing.
> This causes problems in the transition from IPv4 to IPv6 (see problem 8 in
> [draft-ietf-sunset4-gapanalysis]).

>Second, HTTP user agents sometimes distinguish certain contexts as
"secure"-enough to make certain features available. Given the certainty that
"127.0.0.1" cannot be maliciously manipulated or monitored, [SECURE-CONTEXTS]
treats it as such a context. Since "localhost" might not actually map to the
loopback address, that document declines to give it the same treatment. This
exclusion has (rightly) surprised some developers, and exacerbates the risks
of hard-coded IP addresses by giving developers positive encouragement to use
an explicit loopback address rather than a localhost name.

>This document hardens [RFC6761]'s recommendations regarding "localhost" by
requiring that DNS resolution work the way that users assume: "localhost" is
the loopback interface on the local host. Resolver APIs will resolve
"localhost." and any names falling within ".localhost." to loopback addresses,
and traffic to those hosts will never traverse a remote network.

------
agwa
To be clear, this is not an RFC yet. It's not even adopted by a working group,
although I hope it will be.

Mods: can RFC be removed from the title? [Edit: thanks for updating the
title!]

~~~
aeorgnoieang
So, an RFRFC?

~~~
agwa
It's called an I-D, for "Internet Draft."

Very roughly, a Standards Track document in the IETF goes through four stages:

1\. Someone submits an I-D as an individual. Literally anyone can do this and
such a document carries no weight.

2\. A working group (WG) "adopts" the I-D and proceeds to work on the document
as a group. The document still carries no weight at this stage.

3\. The I-D is published as an RFC. When this happens, the document finally
has real weight. The document can no longer be changed, although it can be
updated or obsoleted by another RFC.

4\. When the RFC matures, it can be promoted to an Internet Standard.

Let localhost be localhost is still in the first stage.

~~~
tialaramex
To be fair this is the fourth draft of "Let localhost be localhost". Internet
Drafts deliberately "expire" unless you write an updated version every so
often proving it's still interesting and being worked on. @agwa says they have
"no weight" but pragmatically what matters is always whether people do what
the document says, not its supposed "weight" within a standards body.

For example many of you will have used Let's Encrypt, the whole of Let's
Encrypt is built upon a standard issuance and management protocol, ACME. But
ACME is still only an Internet Draft, albeit it's likely to go to RFC before
the end of this year. So it didn't matter that in your view it "has no
weight", it had millions of people using it.

If this I-D takes off and is widely accepted by, say, Microsoft and Apple,
even if it never becomes an RFC it has a real effect. On the other hand, if it
becomes a standards track RFC but Apple decides to ignore it and never promise
that "localhost is localhost" in their operating systems then it's worthless
despite the "Standard" tag.

~~~
JdeBP
The one that I liked to point to was TSIG. ISC and Nominum got RFC 2845
through in a matter of months. Microsoft submitted its first Internet Draft of
GSS TSIG in 1998, and it did not get through the RFC process for about 5
years, despite already being in real world use by Windows.

------
alexellisuk
Localhost resolving to IPv6 basically breaks with Docker they unless you give
special instructions only listens on IPv4. With curl for instance you can use
the -4 parameter but probably best we start saying test the site on 127.0.0.1
in tutorials.

~~~
deathanatos
Sorry, but none of that is correct.

First, if you publish a container's port in docker, such as with the -p flag,
e.g.,

    
    
        docker run --rm -p 8080:80/tcp nginx:latest
    

Docker will listen, on the host, on ::; it will accept IPv4 connections on
that bind. (Through IPv4-mapped IPv6 addresses[1], which is a transition
mechanism.)

But even if we _force_ Docker to bind to _only_ IPv4, curl will still work:

    
    
        docker run --rm -p 127.0.0.1:8080:80/tcp nginx:latest
    

curl will attempt an IPv6 connection first in this case (since localhost
resolves to ::1), and fallback when it fails (since localhost also resolves to
127.0.0.1). If you pass -v to curl, it will tell you as much:

    
    
      *   Trying ::1...
      * TCP_NODELAY set
      * connect to ::1 port 8080 failed: Connection refused
      *   Trying 127.0.0.1...
      * TCP_NODELAY set
      * Connected to localhost (127.0.0.1) port 8080 (#0)
    

Perhaps there is some pathological case where Docker and curl and IPv6 and
localhost don't all work together, but one would need more information to
tell. But it doesn't "basically break" Docker.

[1]:
[https://en.wikipedia.org/wiki/IPv6_address#Transition_from_I...](https://en.wikipedia.org/wiki/IPv6_address#Transition_from_IPv4)

~~~
alexellisuk
I'm sorry but none of what you've said is correct - I'm speaking from
experience from the Docker community.

Watch this ASCII recording to see the issue

[https://asciinema.org/a/xM8m0iqOepkSwCRBTIP9hYXGU](https://asciinema.org/a/xM8m0iqOepkSwCRBTIP9hYXGU)

We run into the issue on RPi/Raspbian - curl hangs indefinitely. I had someone
report to me that he couldn't access localhost:8080 in a web-browser using a
Docker container for FaaS because it was resolving to this IPv6 - he was on
Arch Linux.

Perhaps you can reverse your hasty down-voting?

~~~
alexellisuk
Nobody said it broke Docker (it was the resolution that "broke". But the
resolution clearly did not work and we had people running through tutorials
only to find curl would hang and timeout unless switching to 127.0.0.1 or
passing the -4 flag.

~~~
fundabulousrIII
hang == block. Docker is badly written and basically broken. With those
corrections, carry on.

------
lolcalhost
This sucks. I have registered and am actively using a 'localhost' domain name
under one of the new generic TLDs for for emails and account signups for quite
some time now.

~~~
ehPReth
This wouldn't affect that: it applies to the bare TLD localhost and its
subdomains -- not localhost.<something>

------
pmarreck
Why couldn't they just redirect "localhost" at the DNS level to 127.0.0.1?

~~~
0xCMP
Well, because that IP isn't what localhost is supposed to be pointed to. It's
supposed to point at 127.0.0.1. The IP you mentioned is more likely to be the
IP of the router you're connected to.

Usually 127.0.0.1 is limited to the computer's internal network via a loopback
network interface and `localhost` should be resolving just to that, but this
RFC makes it so that no matter what `localhost` will point locally instead of
somewhere else which helps people who want to bind to just the internal
loopback and nothing else.

~~~
wolfgang42
For context, as the parent has edited their post: the original question was
asking why localhost couldn't have a DNS entry for 192.something.

