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.
> 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?
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.
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.
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.
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.
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 :)
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.
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).
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?
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.
[+] [-] inopinatus|9 years ago|reply
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".
[+] [-] mikewest|9 years ago|reply
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.
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. :)
[+] [-] amluto|9 years ago|reply
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?
[+] [-] smoyer|9 years ago|reply
[+] [-] rsync|9 years ago|reply
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 ?
[+] [-] facetube|9 years ago|reply
[+] [-] ghshephard|9 years ago|reply
16:04:25 speedy :{~} $ cat /etc/hosts
[+] [-] josteink|9 years ago|reply
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.
[+] [-] lambda|9 years ago|reply
[+] [-] Raphmedia|9 years ago|reply
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.
[+] [-] okket|9 years ago|reply
[+] [-] byuu|9 years ago|reply
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.
[+] [-] nalllar|9 years ago|reply
Shortcut to avoid being redirected to a search for uncommon TLDs: end with a /, no need for the http://.
[+] [-] Scarblac|9 years ago|reply
[+] [-] drostie|9 years ago|reply
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.
[+] [-] josegonzalez|9 years ago|reply
[+] [-] tominous|9 years ago|reply
[+] [-] phs318u|9 years ago|reply
https://en.m.wikipedia.org/wiki/.local
[+] [-] y0ghur7_xxx|9 years ago|reply
related discussion:
http://serverfault.com/questions/17255/top-level-domain-doma...
[+] [-] hlandau|9 years ago|reply
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] xg15|9 years ago|reply
So ".localhost." means "every domain within the 'localhost' tld", not "every domain that contains the string 'localhost'".
[+] [-] amingilani|9 years ago|reply
https://iwantmyname.com/?domain=localhost
[+] [-] throwanem|9 years ago|reply
[+] [-] im4w1l|9 years ago|reply
edit: I don't really have any expertise or experience with this at all, just a thought.
[+] [-] eksu|9 years ago|reply
I think reserving .localhost for loopback would be great for my workflow. Maybe it would check hosts for overrides before going straight to loopback?
[+] [-] zrm|9 years ago|reply
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.
[+] [-] andreareina|9 years ago|reply
[+] [-] stubish|9 years ago|reply
[+] [-] bsimpson|9 years ago|reply
[+] [-] bjackman|9 years ago|reply
[+] [-] EdwardDiego|9 years ago|reply
[+] [-] justincormack|9 years ago|reply
[+] [-] Steeeve|9 years ago|reply
[+] [-] the8472|9 years ago|reply
[+] [-] 0x0|9 years ago|reply
[+] [-] y0ghur7_xxx|9 years ago|reply
nothing. the rfc talks only about the localhost tld.
[+] [-] yeezul|9 years ago|reply
Do I have to remap my whole localhost development in order to be able to access my localhost from a tablet?
[+] [-] mcherm|9 years ago|reply
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.
[+] [-] noja|9 years ago|reply
[+] [-] mobiuscog|9 years ago|reply
[+] [-] devnull42|9 years ago|reply
[+] [-] rburhum|9 years ago|reply
[+] [-] bsimpson|9 years ago|reply
[+] [-] mikewest|9 years ago|reply
It should be unaffected by the suggestion in this document.
[+] [-] gant|9 years ago|reply
[+] [-] drostie|9 years ago|reply
[+] [-] andreareina|9 years ago|reply
[+] [-] textmode|9 years ago|reply
[deleted]