<p><pre><code> 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]).
</code></pre>
That does remind me of the times I was dealing with weird connection issues in some critical services.<p>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.<p>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.
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.<p>It's easy to type and easy to remember and should always do a good job of expressing intent of usage.
There was the time that Keith Henson tried to explain the local loopback address to Scientology lawyers during a deposition...<p><a href="http://www.cryonet.org/cgi-bin/dsp.cgi?msg=6289" rel="nofollow">http://www.cryonet.org/cgi-bin/dsp.cgi?msg=6289</a><p>Henson: (patiently) It's at 127.0.0.1. This is a loop back
address. This is a troll.<p>Lieberman: what's a troll?<p>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.<p><a href="https://en.wikipedia.org/wiki/Keith_Henson" rel="nofollow">https://en.wikipedia.org/wiki/Keith_Henson</a>
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.
At least on the OS I use, which is more IPv6 ready than most, /etc/hosts solves this "uncertainty" problem.<p>I have found that failing to include a localhost entry in the HOSTS file can lead to some strange behavior.<p>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.<p>There should always be a mechanism for the user to override the internet DNS. And applications should continue to respect it.
We have two entries in our DNS which point to 127.0.0.1/::1 - localhost and elvis.<p>This enables the following on Solaris and similar systems:<p><pre><code> $ ping elvis
elvis is alive</code></pre>
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.
I would very much like to see this draft extended to cover SRV lookup as well.<p>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.<p>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.
Also very important to point out; this same standardisation is missing on the TLD level.<p>Both for safeguarding internal use, and making a global TLD reserved on the global DNS zones.
You'll find organisations using in production <i>.local </i>.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.<p>More importantly .dev [1] and .zone [2] are now valid TLDs, so watch out people!<p>[1] <a href="https://www.iana.org/domains/root/db/dev.html" rel="nofollow">https://www.iana.org/domains/root/db/dev.html</a><p>[2] <a href="https://www.iana.org/domains/root/db/zone.html" rel="nofollow">https://www.iana.org/domains/root/db/zone.html</a>
On the one hand, this isn't exactly a new idea and in the real world has been happening for years now.<p>* 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. (<a href="http://jdebp.eu./Softwares/djbwares/guide/dnscache.html" rel="nofollow">http://jdebp.eu./Softwares/djbwares/guide/dnscache.html</a>) I implemented implicit localhost support in my proxy DNS servers for OS/2, as well.<p>* 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.<p>* Unbound has built-in "local zone" defaults mapping between "localhost." and both 127.0.0.1 and ::1.<p>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.
One time I was debugging a problem for a user of our desktop software (I work on <a href="https://expo.io" rel="nofollow">https://expo.io</a>) 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.<p>Took a while to track that was down. Was both bewildering and sort of satisfying to figure it out in the end.
Can anybody with more knowledge point out techniques that this would break?<p>Are there any software or networking patterns that currently rely on localhost _not_ resolving to the loopback?<p>EDIT: The RFC mentions that MySQL currently differentiates between the two, but that's it.
<p><pre><code> The domain "localhost.", and any names falling within ".localhost.",
are known as "localhost names". Localhost names are special in the
following ways […]
</code></pre>
Is this not implemented on macOS or am I just misunderstanding?<p><pre><code> ~ ping test.localhost
ping: cannot resolve test.localhost: Unknown host
~ ping localhost.test
ping: cannot resolve localhost.test: Unknown host</code></pre>
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?
To be clear, this is not an RFC yet. It's not even adopted by a working group, although I hope it will be.<p>Mods: can RFC be removed from the title? [Edit: thanks for updating the title!]
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.
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.