Let 'localhost' be localhost | Hacker News Reader

Let 'localhost' be localhost

tools.ietf.org

383 pointssohkamyung114 comments

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 assigned 10.1.1.1/32 to a device loopback interface, I'm announcing it in my IGP, and I've bound a particular service to listen on 10.1.1.1:1234. Should the local resolver library be allowed to return 10.1.1.1 for servicename.localhost? Under this draft's (re)definition of loopback addresses, definitely not. So now we've lost that symbolic way to configure a service consumer to connect locally. You're left inventing workarounds such as your own namespace for loopbacks, or changing the service to also bind to, say, 127.1.1.1.

I also find it curious that this draft allows only address queries (presumably A and AAAA) under .localhost. I'd like to know the rationale for that restriction. For example, there may well be applications that only use SRV records.

Unnecessary restrictions can have unexpected & unknowable consequences. "Tools not policy".

Symbolic way to force a local application locally as follows:

16:04:25 speedy :{~} $ cat /etc/hosts

   ##
   # Host Database
   #
   # localhost is used to configure the loopback interface
   # when the system is booting.  Do not change this entry.
   ##
   127.0.0.1       localhost
   10.1.1.1        servicelocalhost

I don't mean to overconstrain the definition of loopback. If you have a good mechanism for specifying a specific IP range as loopback, and that mechanism can be understood by client software and resolution APIs, then I don't see any reason not to allow it.

The salient distinction from my perspective is traffic within a specific host, and traffic that traverses the network. If you have suggestions for language that make that distinction more clearly than the document currently does, I'm happy to incorporate it. :)

https://twitter.com/dbrower/status/781001487157719040 raises similar concerns. The rationale is simple: I wanted to make the smallest change possible to RFC6761, and item 3 of https://tools.ietf.org/html/rfc6761#section-6.3 already contains the address query restriction.

It's probably reasonable to reconsider it, that's just a larger change than the one I was specifically trying to make. :)

"If you have suggestions for language that make that distinction more clearly than the document currently does, I'm happy to incorporate it. :)"

Currently where it says "an IP loopback addresses", it may be worth saying something like "any of the IP loopback addresses for the device".

I agree that technically "an IP loopback address" ought to be sufficient, but I have also found it is a very common belief, probably even the majority belief, among people who use networking that "127.0.0.1" is the one and only loopback address. (I've lost count of the systems I've slightly broken just by feeding them 127.1.1.1 or equivalent.) I'm sure people who are the sort to read and write standards know better, but since it doesn't hurt the standard itself to emphasize the point, perhaps it's worth it.

Thankfully IPv6 defined a single "localhost" or loopback IP: ::1/128

There is none of this 127/8 mess.

that "mess" is great for testing though, you can spin up numerous instances each on their own loopback address.

You can use a link local address of your public interface in IPv6.

That's just one, adding more require elevated privileges, with 127.0.0.0/8 you have 256³ at your disposal.

Hey, thanks for the considered reply. I rustled up alternative language you might consider for section 3.1 paragraph 1:

"Name resolution APIs and libraries MUST recognize localhost names as special, and MUST always return a unicast address that cause the node to send an IP datagram to itself."

This deliberately echoes the language of RFC4291 and RFC6890 when defining loopbacks. Can I also suggest revising references, looks like RFC5735 has been obsoleted by RFC6890.

Overall I think this draft is a helpful clarification, thanks for creating it!

> 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.

> 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'." :)

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.

> So let's say I've assigned 10.1.1.1/32 to a device loopback interface, I'm announcing it in my IGP, and I've bound a particular service to listen on 10.1.1.1:1234. Should the local resolver library be allowed to return 10.1.1.1 for servicename.localhost? Under this draft's (re)definition of loopback addresses, definitely not. So now we've lost that symbolic way to configure a service consumer to connect locally. You're left inventing workarounds such as your own namespace for loopbacks, or changing the service to also bind to, say, 127.1.1.1.

Setting localhost to resolve to 10.1.1.1 works, sometimes, for this particular use case, but it doesn't work particularly well. Consider what happens when your served is multi-homed: which interface's address should "localhost" resolve to? What if you have one service at 10.1.1.1 and another at 192.168.0.1, both are on the same box, and both want to be called "localhost".

If you're single-homed, then why not bind INADDR_ANY and let localhost be 127.0.0.1?

Ah, I think you've assumed that the assignment of 10.1.1.1/32 to lo in that example is to replace 127.0.0.1/8. It's in-addition-to. The most common case is multi-homed routers that wish to announce a management address into the IGP, but I've also used it for stuff from proxy farms to making containerized/virtualized microservices a bit more portable, and I'm far from the most sophisticated user. There's people out there doing exotic things with anycast or VPNs or VOIP or MPLS that do this too. I once built a Cisco UCCE site that required it as part of ensuring there was a diverse path for their queue state replication that was in a separate routing protocol convergence domain. And so on - it's far from unusual.

Aha, and you want to make servicename.localhost resolve there. That makes sense. Making plain "localhost" go somewhere special seems dubious.

And, in fact, 127.0.53.53 already has a special use (try `dig @8.8.8.8 -ta drive` and `dig @8.8.8.8 -tmx drive`)

https://www.iana.org/domains/root/db/drive.html

It's a valid TLD...

https://www.icann.org/news/announcement-2-2014-08-01-en

shows why drive. was set to return 127.0.53.53.

Same thing happened with prod. and other TLD's. These are all names that were/are being used internally and now are valid TLD's that are going to cause issues for people :/

"You're left inventing workarounds such as your own namespace for loopbacks, or changing the service to also bind to, say, 127.1.1.1."

I don't understand this - you say you are "left with" an entire /8 that is universally recognized as the loopback ... what more could you want ?

I am genuinely curious - what is the utility of having lots of different network address ranges to define as the loopback ?

Mocking machines for testing is one reason.

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 happen enough that we eventually stopped using "localhost" and started using 127.0.0.1 in our code.

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

I was expecting IPv4 to be around forever, for similar reasons that COBOL and the still emulated 8254 PC beep are: there's too much critical infrastructure using it.

Honestly, when could we ever retire IPv4? We've had, what three or four decades now, of building the world's infrastructure on it. What's a realistic scenario to retire that stuff even if everyone gets on IPv6 in 10 years. Another 50 years? 100? 500?

Our great-great-grandkids will still be troubleshooting the 'hey who deleted localhost from /etc/hosts' problem.

While some people might edit their host for nefarious purposes, I think it's wrong to attribute all of it to malice.

Personally, I set the host file to use https://github.com/StevenBlack/hosts in order to block ads on every computers I touch.

I also often use software that manage the host file and ignore the default physical file.

The relevant part of the GP might be "since these customers don't know what they're doing."

Relevant (source: http://catb.org/jargon/html/koans.html):

A novice was trying to fix a broken Lisp machine by turning the power off and on.

Knight, seeing what the student was doing, spoke sternly: “You cannot fix a machine by just power-cycling it with no understanding of what is going wrong.”

Knight turned the machine off and on.

The machine worked.

Every one of the cases I have had to debug in which someone had deleted the localhost entry was someone who had entries for blocking Adobe's licensing servers.

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.

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.

You can use xip.io

127.0.0.1.xip.io www.127.0.0.1.xip.io files.127.0.0.1.xip.io doc.127.0.0.1.xip.io

all resolve to 127.0.0.1

I use 42foo.com which does exactly that.

Thanks! Nice and short, too.

I set up Worksonmy.computer to do the same yesterday

There is also lvh.me

DNS rebinding means you shouldn't allow untrusted domains to resolve to a localhost IP address...

For another memorable one try .localtest.me See http://readme.localtest.me/ for more details.

> it will try and redirect me to a Google search result, unless I prefix the whole thing, eg "http://doc.localhost/"

Shortcut to avoid being redirected to a search for uncommon TLDs: end with a /, no need for the http://.

Similarly you can start with just a //, no need for the http:.

Starting with // doesn't work in all browsers, such as Safari.

You know that you do not need to use that naming convention, right?

You might as well set up domains for www.pocalhost, files.pocalhost, doc.pocalhost.

Or, why even have that part at all? You can just as easily set up the hosts record in /etc/hosts for www, and then visit http://www/ and it should work just fine on both Windows and Linux.

I'm guessing there might be a cookie or content security policy that requires testing with actual subdomains, so www alone might not work for their usecase. It's also nice to use a name that is guaranteed not to have conflicts, so localhost might be preferable for that reason.

Maybe someone should standardize internal TLD(s) for corporate and other use cases that would make developers less sad, as at least they have alternatives.

.local ?

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

Unfortunately that is less and less possible due to multicast DNS which hijacked that TLD.

Isn't .private reserved?

Yes, but that just means they can decide to do something special with it in the future, not that you can use it for your own purposes.

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.

Google registered the .dev gTLD for their internal use. So I've been doing the same, hijacking all requests for the .dev gTLD and serving up my own zones.

Google has both .dev and .prod.

That's fine until Google buys your company. :)

I am willing to take that risk. :)

I will not be that sad.

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

The annoying part is that Chrome treats valid (g)TLDs differently. If you type test.dev in your browser it will try to resolve test.dev. But if you type test.loc, it will google for test.loc.

There are a lot of workarounds sure, but try explaining that to everyone else.

FYI, some Linux distributions default to .localdomain instead.

But for my machines, I just use a domain that I own.

.local is for mdns only. I've been using .lan instead for locally poisoned DNS entries (in my case, dnsmasq being both DNS server and dhcpd to make it easy).

No, absolutely not. If people choose that for a local domain, that breaks mDNS.

It would be great if mDNS was reliable enough that you wouldn't need to hack together a private DNS in most cases.

Before the gTLDs were expanded it was easy: just choose an unused word. These days I tend to see either subdomains of the main public domain, or a public domain registered solely for internal use.

The proper way to do it, though it does mean that things such as using ssl for wildcard domains at an arbitrary level become difficult and potentially expensive.

If they're internal domains you can run your own CA. No need to use wildcard certs or pay anything at all.

Are there any reasons not to use a real domain?

I agree with you. There should exist a standardized tld for internal networks that we can use and be sure that no one else has control over. Buying a domain and use a subdomain of that one is not a good workaround. .internal would be nice and is not used by now. I may go write an rfc now :)

related discussion:

http://serverfault.com/questions/17255/top-level-domain-doma...

What happens as soon as two different organizations want to connect their networks together and they both turn otu to be using the same hijacked TLD?

Use a real domain name instead.

> What happens as soon as two different organizations want to connect their networks together and they both turn otu to be using the same hijacked TLD?

Why "hijacked" TLD? It would be a standard TLD.

If two orgs merge, and they both happen to use the same hostnames for some things, like say git.internal, they just refactor those hosts, or merge them since they merge.

It is not usually as easy as you suggest to just merge or refactor conflicting domains.

Even if you're lucky, and it is git.internal - rather than source.internal with VSS on one and ClearCase on the other - there may be conflicting repository names. These'll be configured on developer's PCs, CI servers, automated deployment scripts. And that's just one domain name.

That's potentially a lot of work to connect two organizations: who may well not be connecting because of a merger - they may simply be contractors.

If ABC Corp and XZY Corp had their local stuff on internal.abc.com and internal.xyz.com, then all their old domains - and urls - keep working after they connect their networks. Whether and when to merge their services together becomes a decision based on the merits of each merge, rather than something that is forced because they choose a bad naming scheme.

Why go through all the pain of renaming hosts if you can avoid it by using a real domain name in the first place?

How is this simpler than just using real domain names? I use an int.company.com domain for my internal hosts and have for 20+ years.

Surely it's not that hard to come up with a unique, memorable internal TLD? eg. the company name - "git.facebook", "foo.microsoft", "monitoring.dev.google"

I thought .local was a de-facto standard for this?

.local is used for link-local domains, for resolution by multicast DNS ('zeroconf'). See https://tools.ietf.org/html/rfc6762.

Microsoft used to suggest using it for local networks, but now advise against it.

Presumably single-letter TLDs will never be allocated. So you could allocate yourself one of those. Or maybe something with hyphens in not beginning with xn--.

I think for non-DNS experts (like me) it's important to know that in DNS terminology, the notation "tld." is used to donate top-level domains. (Note the trailing period)

So ".localhost." means "every domain within the 'localhost' tld", not "every domain that contains the string 'localhost'".

Just so we're clear. All these domains would just go away?

https://iwantmyname.com/?domain=localhost

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, or obsoleted by other documents at any time.

- [1] https://datatracker.ietf.org/submit/

The name "Request for Comments" is historical, but still very confusing. IDs are the literal requests for comments now, and RFCs the standards.

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

Maybe I'm overthinking this, but wouldn't a better solution be to say that server1.localhost doesn't have to be loopback, but that it must be resolved by asking the DNS server at localhost (or alternatively defined in the hosts file).

edit: I don't really have any expertise or experience with this at all, just a thought.

I think people already hosting their own DNS server at localhost don't need to worry about real domain allocations as they can spoof whatever they want for development.

I think reserving .localhost for loopback would be great for my workflow. Maybe it would check hosts for overrides before going straight to loopback?

isn't that the role of .localdomain tho?

It seems like the problem with doing this is that there are multiple localhost IPs. If it was as simple as "every A query for [any].localhost is 127.0.0.1, every AAAA query is ::1" then it would be one thing, but the A query could also be 127.0.0.2 etc.

So for example this would mean that if I put an entry for "server5.localhost 127.0.0.5" in my local DNS server then that entry can't be used, because the client's local resolver API will match *.localhost and it now "MUST NOT send queries for localhost names to their configured caching DNS server(s)" so it likely returns 127.0.0.1 instead of 127.0.0.5.

Is there an actual case to be made for pointing localhost to anything other than the loopback device?

Only if you are intent on using a hack to produce an unmaintainable system. Making 'localhost' point to anything other than loopback is just asking for trouble. People will do it because they can, but not because they should.

Chrome on Android lets you bind your phone/tablet's localhost to your computer's localhost. This enables you to test during development, even if your corporate IT people disallow connections between devices on the same WiFi network (or partition personal devices onto a different network than corporate hardware).

Hey that's a neat trick. If I'm reading the docs[1] correctly, as far as the application is concerned it is connected to the loopback. The same thing happens when I `ssh -L <port>:localhost:<port> <local-vm>`.

I think it also follows the spirit of the idea since the change is local to the machine you're using.

[1] https://developers.google.com/web/tools/chrome-devtools/debu...

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?

No, if your application is distributed, you won't be referring to localhost.

And why not?

If we are running distributed services, we know the machine that the code is run on is running. We can even reference this by many languages version of "this" keyword.

localhost is only "this" for IP4/6

I think the GP meant that the client won't be calling on the server through 'localhost', at least not as a hard-coded parameter.

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

On a related note, few things annoy me more than when my browser updates localhost to www.localhost.com.

in firefox you can set browser.fixup.alternate.enabled = false

There are several "localhost.<tld>" domains in the wild today. What happens to those?

> There are several "localhost.<tld>" domains in the wild today. What happens to those?

nothing. the rfc talks only about the localhost tld.

Ah, you're right. Thanks for clarifying.

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?

Yes.

Let me try wording this differently for you. "What if I develop something with only local calls between my front and back ends, and later I decide I want to test/implement a front-end feature on Android/iOS which doesn't support running the back end. Do I have to change my development so it is no longer local?" - the answer is yes.

On the other hand, "remap my whole localhost development" is a REALLY impressive-sounding way of saying "change the one line in the config file that says to connect to 'localhost' to connect to 'api.myhost.com' instead." Or maybe, if you are a sloppy developer, "use search-and-replace to replace all instances of 'localhost' in the code with 'api.myhost.com'." Either way, it is a trivial change.

What happened to localdomain?

Couldn't we just define 'loopback' instead ?

This seems like a bad idea. It seems to be solving for a problem that doesn’t exist while introducing the potential for issues. If you want to prevent latency or lookups localhost should just live in the hosts file.

The folks at Tucows are going to get pissed off ;) https://who.is/whois/localhost.com

How would this affect Chrome on Android, which allows you to redirect localhost requests from a phone to access localhost on the computer it's tethered to?

That's done via port-forwarding. That is, Chrome is talking to the loopback interface on a particular port. The server listening at that port forwards the requests across the debugging bridge to the phone, and ferries the response back across in the same way.

It should be unaffected by the suggestion in this document.

I always thought it made sense to address local VMs with .localhost domains in my hostsfile. Apparently not?

You can address them with whatever domains you choose; suffixing them with .localhost is no better than suffixing them with .local, .loc, .qwyjibo, or not suffixing them at all: these are merely personal choices you made to give the domains some look and feel, but they aren't intrinsically privileged by the system.

I've taken to having my VMs support mDNS (specifically avahi on Debian), and I can connect to <hostname>.local without adding an entry to my hosts file or messing with DNS.

Has Theresa May got a role in the IETF as well? :)

"Implementation Considerations: This change would make developers sad [...]"

Sad panda.

But it makes total sense.

And please make it 127.0.0.1 and not ::1. I've found several instances where localhost resolved to ::1.

Use localhost4 & localhost6 if you don't want that kind of surprises.

It resolves to both on most major OSs, and I think it should as long as something isn't horribly misconfigured.

Most networking code on Unix-like OSes should (eventually) boil down to something like a call to getaddrinfo(2), a system call that returns the set of addresses that match a query — typically a hostname. The result set for localhost will often include both ::1 and 127.0.0.1, but the result from the function also includes what type of address (IPv4 or IPv6, essentially) they are: you're supposed to take both the address (such as ::1) and the address family (such as IPv6) and pass them to socket(2). (and if that fails, try the next one in the list)

This mechanism lets you resolve domains that might be IPv4 or IPv6 only, and not even need to care in the code: if the domain is IPv4 only, then getaddrinfo only returns addrinfos w/ IPv4 addresses. Likewise for v6. You forward the information to socket(2) and connect(2), and don't ever need to deal with a concrete addrinfo object.

-1 from me. 'localhost' is an artifact of a model of network computing that is no longer relevant; it's a special case of the general antipattern of network-topology sensitive design.

Back in the bad old days only a single user on a physical computer could log into a windows domain, because it was possible look up what user (singular) was on a host. Of course domain logins were also exquisitely sensitive to the nature of the network between client and server as well. It was a nightmare. Localhost is a product of that kind of thinking.

One-per-host resources that have to be shared across all users, security perimeters, vms, containers, etc. are an unwelcome headache. Of course, real systems don't actually share a localhost between all of these things, resulting in the even goofier concept of "which localhost do you mean?" That question was exactly why site-local addressing was deprecated from ipv6 https://tools.ietf.org/html/rfc3879

An actually portable standard for resolving well-known local entities would be great, but more special cases to try to fix the doomed localhost idea is a move in the wrong direction.

I guess the authors understand that "localhost" is not an ideal authentication mechanism, however, the fact is that many application do use it as such. And the reason why they decided to come up with the RFC, to at least fix this on the level of DNS resolvers.

(And I am not sure this thinking will ever be dead, it's kind of extension of notion of "territory" for physical objects, and you can still pretty safely assume that whatever is in my home is my own.)

Reply on news.ycombinator.com