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".
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.
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. :)
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.
"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.
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!
> 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.
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.
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 :/
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
> 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.
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.
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.
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.”
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.
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.
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.
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.
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.
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.
.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).
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 :)
> 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.
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"
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'".
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.
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?
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.
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.
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?
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.
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.
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.
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.
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.
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.)
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".