Live data from Hacker News

Let 'localhost' be localhost

tools.ietf.org

41–50 of 117 posts

Re: Let 'localhost' be localhost

#41

Earlier quoted context omitted.

No. This draft describes a change by which localhost becomes effectively a new TLD in which all names map to the loopback address. Names in other TLDs won't be affected.

Sorry to nitpick, but this is technically a Draft, not a RFC. Drafts are just that: drafts, not standards. They automatically expire after 6 months if not renewed. As stated in [1]: Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. [...] Internet-Drafts are draft documents, and are valid for a maximum of six months. They may be updated, replaced, o…

Much appreciated. I've updated my prior comment to reflect the correction.

Re: Let 'localhost' be localhost

#42
post #8

I'm not very networking-wise, got a question: is the "local machine" alwyas a well-defined thing? I'm thinking about stuff like where hosts are transparently distributed. Maybe there are systems out there that take advantage of resolving localhost to other than 127.* in order to make applications easy to transparently migrate when scaling servers out, or something?

We have a reasonably distributed system. Localhost only ever occurs in a testing environment.

Re: Let 'localhost' be localhost

#43

Isn't there a problem here? This draft says: IPv4 loopback addresses are defined in Section 2.1 of [RFC5735] as "127.0.0.0/8". That's not perfectly true. RFC5735 defines 127/8 as loopback addresses, but it leaves the door open for other addresses to be assigned to the loopback interface. And indeed doing so is a common pattern for network devices, and a less common (but very useful) pattern for services. So let's say…

> IPv4 loopback addresses are defined in Section 2.1 of [RFC5735] as "127.0.0.0/8".

Did you just assume IPv4? That's IPist!

Seriously though. IPv6 exists. And it has a different address and notation for localhost (::1). Which means that using an IP(v4)-address alone is not guaranteed to be bulletproof.

The only bulletproof way to ensure that you bind to a genuine loopback interface is letting the OS tell you which address that is. And for that you need a "localhost" hosts-file entry or equivalent.

Re: Let 'localhost' be localhost

#44
Nice! I'm very much in favor of this change.

I develop my webserver locally, and it has many subdomains. So I have "www.localhost", "files.localhost", "doc.localhost", etc.

I have to add each subdomain to my /etc/hosts file before I can use it, as you can't have wildcards in that file. And even then, if I type a new one into Chromium, it will try and redirect me to a Google search result, unless I prefix the whole thing, eg "http://doc.localhost/"; once I do that and it connects, then the Omnibar will match the actual localhost entry easily going forward.

This should help anyone in a similar situation of testing their server with subdomains on localhost.

Re: Let 'localhost' be localhost

#45

Isn't there a problem here? This draft says: IPv4 loopback addresses are defined in Section 2.1 of [RFC5735] as "127.0.0.0/8". That's not perfectly true. RFC5735 defines 127/8 as loopback addresses, but it leaves the door open for other addresses to be assigned to the loopback interface. And indeed doing so is a common pattern for network devices, and a less common (but very useful) pattern for services. So let's say…

> IPv4 loopback addresses are defined in Section 2.1 of [RFC5735] as "127.0.0.0/8". Did you just assume IPv4? That's IPist! Seriously though. IPv6 exists. And it has a different address and notation for localhost (::1). Which means that using an IP(v4)-address alone is not guaranteed to be bulletproof. The only bulletproof way to ensure that you bind to a genuine loopback interface is letting the OS tell you which ad…

> Did you just assume IPv4? That's IPist!

The next line in the document is "IPv6 loopback addresses are defined in Section 3 of [RFC5156] as '::1/128'." :)

Re: Let 'localhost' be localhost

#46

Isn't there a problem here? This draft says: IPv4 loopback addresses are defined in Section 2.1 of [RFC5735] as "127.0.0.0/8". That's not perfectly true. RFC5735 defines 127/8 as loopback addresses, but it leaves the door open for other addresses to be assigned to the loopback interface. And indeed doing so is a common pattern for network devices, and a less common (but very useful) pattern for services. So let's say…

I've commonly changed localhost to addresses outside the 127/8 region for debugging purposes (and assigned other names to loopback addresses which will presumably still be allowed). If this RFC is ratified, it will be one of those things I'll forget repeatedly for a while.

Re: Let 'localhost' be localhost

#47
What if I develop something on localhost, and two months later I decide I want to test/implement a feature on Android/iOS.

Do I have to remap my whole localhost development in order to be able to access my localhost from a tablet?

Re: Let 'localhost' be localhost

#48
post #39

I have had a number of customers who have broken our applications, which have daemons listening on localhost, by editing their /etc/hosts files and removing the localhost entry. I guess various people edit /etc/hosts to prevent applications from talking to licensing servers, and in the process happen to accidentally blow away the localhost entry (since these customers don't know what they're doing). We had this happe…

Looks like we need eternal IPv4 support, if it is just for 127.0.0.1 :(

Re: Let 'localhost' be localhost

#49
post #13
post #5

Earlier quoted context omitted.

.local ? https://en.m.wikipedia.org/wiki/.local

Like the linked wikipedia article says, .local is used by mDNS(zeroconf/bonjour/avahi/etc.), so you might see weird stuff if you use it for a "normal" DNS environment. AFAICT current "best practice" for private networks is to use a private subdomain of your real domain. Say, .internal.example.com.

That's why i use sometimes simply .loc.. :)

Re: Let 'localhost' be localhost

#50
post #44

Nice! I'm very much in favor of this change. I develop my webserver locally, and it has many subdomains. So I have "www.localhost", "files.localhost", "doc.localhost", etc. I have to add each subdomain to my /etc/hosts file before I can use it, as you can't have wildcards in that file. And even then, if I type a new one into Chromium, it will try and redirect me to a Google search result, unless I prefix the whole th…

I wish whoever owns localhost.org (which resolves to 127.0.0.1) configured it so that *.localhost.org also worked. Would help with the browsers too.
Post reply on HN