16 ms·
Internet Draft: Let 'localhost' be localhost
- agwa 9y agoTo be clear, this is not an RFC yet. It's not even adopted by a working group, although I hope it will be. Mods: can RFC be removed from the title? [Edit: thanks for updating the title!]
- aeorgnoieang 9y agoSo, an RFRFC?
- delinka 9y agoPretty sure it's already called a "draft."
- kfriede 9y agoHm, I'm not familiar with that acronym.
- parent5446 9y agoIt stands for Document Requesting All Faults and Technicalities. (Source: I have a PhD in speaking out of my ass.)
- delinka 9y agoI bet you're an excellent party ventriloquist. ;-)
- agwa 9y agoIt's called an I-D, for "Internet Draft." Very roughly, a Standards Track document in the IETF goes through four stages: 1. Someone submits an I-D as an individual. Literally anyone can do this and such a document carries no weight. 2. A working group (WG) "adopts" the I-D and proceeds to work on the document as a group. The document still carries no weight at this stage. 3. The I-D is published as an RFC. When this happens, the document finally has real weight. The document can no longer be changed, although it can be updated or obsoleted by another RFC. 4. When the RFC matures, it can be promoted to an Internet Standard. Let localhost be localhost is still in the first stage.
- tialaramex 9y agoTo be fair this is the fourth draft of "Let localhost be localhost". Internet Drafts deliberately "expire" unless you write an updated version every so often proving it's still interesting and being worked on. @agwa says they have "no weight" but pragmatically what matters is always whether people do what the document says, not its supposed "weight" within a standards body. For example many of you will have used Let's Encrypt, the whole of Let's Encrypt is built upon a standard issuance and management protocol, ACME. But ACME is still only an Internet Draft, albeit it's likely to go to RFC before the end of this year. So it didn't matter that in your view it "has no weight", it had millions of people using it. If this I-D takes off and is widely accepted by, say, Microsoft and Apple, even if it never becomes an RFC it has a real effect. On the other hand, if it becomes a standards track RFC but Apple decides to ignore it and never promise that "localhost is localhost" in their operating systems then it's worthless despite the "Standard" tag.
- JdeBP 9y agoThe one that I liked to point to was TSIG. ISC and Nominum got RFC 2845 through in a matter of months. Microsoft submitted its first Internet Draft of GSS TSIG in 1998, and it did not get through the RFC process for about 5 years, despite already being in real world use by Windows.
- sctb 9y agoThank you, we've replaced “RFC” with ”Internet Draft”.
- jonathonf 9y agoI've had web browsers perform a web search for 'localhost', or even just redirect me to localhost.com. Annoying.
- deleted 9y ago[deleted]
- mi100hael 9y agoThat's probably due to shitty ISP DNS hijacking/redirecting requests if it can't resolve a name.
- jonathonf 9y agoI assure you it's not. :)
- tambourine_man 9y agoYeah. The ancients speak of a time when address and search bars where separated. I think it's a legend.
- coltonv 9y agoI remember this. Also, if I remember correctly, seamlessly integrating search and address bar was the thing that really made Chrome take off. Sure, it was an all around better product than IE/Safari, but to get people to actually download it over just using the default requires it to be significantly more convenient, and it sure was.
- flukus 9y ago>Also, if I remember correctly, seamlessly integrating search and address bar was the thing that really made Chrome take off. That was part of it. What's weird is that the Mozilla suite had the same thing before firefox even existed, in many ways firefox was a step backward. I believe opera did this years earlier too.
- 9y ago
- nhance 9y agoIf 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. It's easy to type and easy to remember and should always do a good job of expressing intent of usage.
- deleted 9y ago[deleted]
- schoen 9y agoI don't think that quite fits into the security model of many of the purposes for which people use localhost, as they often want to avoid all external dependencies (including Internet access!) and all external trust. If they do use your domain name then they have to trust that nobody has subsequently seized the name in court, nobody has hacked or DDOSed your nameservers, there's not an interruption of network connectivity between them and your servers, and that the ISPs forwarding the DNS queries didn't substitute a different response for the one you intended to return (since currently your leaf records aren't DNSSEC-signed).
- mholt 9y agoI don't think (?) I've ever made this typo. How many hits do you get? (I feel like "ocalhost", "locahost", or "localhos" would be more common typos.)
- nhance 9y agoI have no clue, it's all handled by the registrar's DNS. I know when it last expired I was getting a good number of emails from people begging for it to come back asap. The other commentators here are right, it won't solve a good number of the issues in this proposal, but works well if you need something for developing against subdomains.
- sillysaurus3 9y agolocalhost would be a good name for a bar in SF.
- eduren 9y agoCan anybody with more knowledge point out techniques that this would break? Are there any software or networking patterns that currently rely on localhost _not_ resolving to the loopback? EDIT: The RFC mentions that MySQL currently differentiates between the two, but that's it.
- mschuster91 9y agoHmm I guess people may use IPs other than 127.0.0.1 like 127.0.0.2 for Docker or maybe VPN/VM shenanigans...
- inopinatus 9y agoThis remains valid under the draft.
- hazeii 9y agoWithin ".localhost."... www.localhost.mydomain.com?
- xnxn 9y agoThe trailing "." signifies the end of the domain name, so your example domain would be unaffected.
- mnarayan01 9y ago> Application software MUST NOT use a searchlist to resolve a localhost name.
- deleted 9y ago[deleted]
- hazeii 9y agoThanks, I misread the draft as '<star>.localhost.<star>'(!)
- mnarayan01 9y ago
- pmarreck 9y agoWhy couldn't they just redirect "localhost" at the DNS level to 127.0.0.1?
- deleted 9y ago[deleted]
- 0xCMP 9y agoWell, because that IP isn't what localhost is supposed to be pointed to. It's supposed to point at 127.0.0.1. The IP you mentioned is more likely to be the IP of the router you're connected to. Usually 127.0.0.1 is limited to the computer's internal network via a loopback network interface and `localhost` should be resolving just to that, but this RFC makes it so that no matter what `localhost` will point locally instead of somewhere else which helps people who want to bind to just the internal loopback and nothing else.
- wolfgang42 9y agoFor context, as the parent has edited their post: the original question was asking why localhost couldn't have a DNS entry for 192.something.
- acdha 9y agoTrust: there's no “DNS level” which you can reason about reliably across the wide range of networks people use. Developers would still get bug reports because some ISP resolved localhost to the IP address of their search / ad page, or a dodgy home router returned its setup page, etc. Lest that seem contrived, there are major ISPs – national level in Europe – which ran transparent HTTP proxy-caches which stored pages for years beyond their expiration date. I have zero confidence that some ISP wouldn't through incompetence or marketing have localhost resolve to something you don't expect. Building it into the network stack means that entire class of errors stops happening.
- fundabulousrIII 9y agooh, screw off. Run your own servers and mandate your configurations for search and acceptable servers or go tsig and penalize your providers. this isn't hard. In fact for a scalable|good business it should be mandatory.
- lolcalhost 9y agoThis 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.
- deleted 9y ago[deleted]
- ehPReth 9y agoThis wouldn't affect that: it applies to the bare TLD localhost and its subdomains -- not localhost.<something>
- user5994461 9y agoFirst, 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]). That does remind me of the times I was dealing with weird connection issues in some critical services. 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. 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.
- rmc 9y agoThe weirdest was a co-worker who had some simple webserver, which was listening on only IPv4 or IPv6 (but not both). When he went to "localhost" on Firefox it used IPv4 and he was able to see it. On Chrome "localhost" was IPv6 (or the other way around), and he got "Could not connect" error. It confused him no end how this simple web server worked on FF but not Chrome. :)
- tootie 9y agoI always have local.my company.com DNS that resolves to 127.0.0.1. I can get a valid cert that way too.
- rblatz 9y agoI hope you don't publish that record to the world.
- icebraining 9y agoWhy?
- brazzledazzle 9y agoJust a guess: CORS-related attacks
- age_bronze 9y agoThere 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?
- lightbyte 9y agoFrom the actual draft: > 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]). >Second, HTTP user agents sometimes distinguish certain contexts as "secure"-enough to make certain features available. Given the certainty that "127.0.0.1" cannot be maliciously manipulated or monitored, [SECURE-CONTEXTS] treats it as such a context. Since "localhost" might not actually map to the loopback address, that document declines to give it the same treatment. This exclusion has (rightly) surprised some developers, and exacerbates the risks of hard-coded IP addresses by giving developers positive encouragement to use an explicit loopback address rather than a localhost name. >This document hardens [RFC6761]'s recommendations regarding "localhost" by requiring that DNS resolution work the way that users assume: "localhost" is the loopback interface on the local host. Resolver APIs will resolve "localhost." and any names falling within ".localhost." to loopback addresses, and traffic to those hosts will never traverse a remote network.
- filleokus 9y agoThe domain "localhost.", and any names falling within ".localhost.", are known as "localhost names". Localhost names are special in the following ways […] Is this not implemented on macOS or am I just misunderstanding? ~ ping test.localhost ping: cannot resolve test.localhost: Unknown host ~ ping localhost.test ping: cannot resolve localhost.test: Unknown host
- tntniceman 9y agoAs I understood it, that simply states that if any of those domains were implemented, they should loopback, as opposed to all domains containing "localhost" ARE implemented.
- filleokus 9y agoThank you for the clarification!
- djrogers 9y agoIt would be rather surprising if a brand new draft RFC from a google employee were already implemented in macOS...
- filleokus 9y agoYeah of course, sorry, I misread the document. I took that part as to describe the current state.
- Matheus28 9y agoTo clarify a bit further than what the other comments said (abc.localhost. isn't implemented on macOS): The RFC draft is talking about domains ending in ".localhost.", not any domain containing ".localhost." (so abc.localhost.example.com wouldn't be localhost). All domains have to end with a period, or they're not fully qualified. "example.com" could mean "example.com.my.domain." if whatever you're using uses "my.domain." as the root. But "example.com." is always "example.com." Nowadays that feature isn't used very often, as the root of domains not ending in a period is usually assumed to be in the root zone.
- bryanrasmussen 9y agothis 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.
- chr1 9y agoDoes this mean that an entry in /etc/hosts assigning ip to localhost will be ignored?
- hetfeld 9y agoSerious question. Anyone?
- xg15 9y agoWell, the explicit intent of the proposal is to hardwire the localhost = 127.0.0.1 / ::1 mapping, so my guess is yes.
- inopinatus 9y agoThat is not the effect of the draft. The effect is that localhost = lo0. Other addresses are valid.
- inopinatus 9y agoNot necessarily. The requirement for applications concerned about security properties of localhost names is that the resolved address is bound to a loopback interface, in order to satisfy the test in section 5.1 of this draft. However, I expect many application developers to mistakenly assume that only 127/8 and ::1 are valid loopback interface addresses.
- wolfgang42 9y agoOr, indeed, to assume (as I did for many years) that only 127.0.0.1 itself is a valid loopback address. I was rather surprised when I looked it up and found that it was the entire 127 block.
- e12e 9y agoThis can be useful for testing - especially before one could safely assume SNI support - but also for setting up various Web (or other network) servers locally - with an entry in /etc/hosts (so dev-local can point to some other local ip than test-local) etc.
- alexellisuk 9y agoLocalhost 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.
- deathanatos 9y agoSorry, but none of that is correct. First, if you publish a container's port in docker, such as with the -p flag, e.g., docker run --rm -p 8080:80/tcp nginx:latest Docker will listen, on the host, on ::; it will accept IPv4 connections on that bind. (Through IPv4-mapped IPv6 addresses[1], which is a transition mechanism.) But even if we force Docker to bind to only IPv4, curl will still work: docker run --rm -p 127.0.0.1:8080:80/tcp nginx:latest curl will attempt an IPv6 connection first in this case (since localhost resolves to ::1), and fallback when it fails (since localhost also resolves to 127.0.0.1). If you pass -v to curl, it will tell you as much: * Trying ::1... * TCP_NODELAY set * connect to ::1 port 8080 failed: Connection refused * Trying 127.0.0.1... * TCP_NODELAY set * Connected to localhost (127.0.0.1) port 8080 (#0) Perhaps there is some pathological case where Docker and curl and IPv6 and localhost don't all work together, but one would need more information to tell. But it doesn't "basically break" Docker. [1]: https://en.wikipedia.org/wiki/IPv6_address#Transition_from_IPv4 https://en.wikipedia.org/wiki/IPv6_address#Transition_from_I...
- alexellisuk 9y agoI'm sorry but none of what you've said is correct - I'm speaking from experience from the Docker community. Watch this ASCII recording to see the issue https://asciinema.org/a/xM8m0iqOepkSwCRBTIP9hYXGU https://asciinema.org/a/xM8m0iqOepkSwCRBTIP9hYXGU We run into the issue on RPi/Raspbian - curl hangs indefinitely. I had someone report to me that he couldn't access localhost:8080 in a web-browser using a Docker container for FaaS because it was resolving to this IPv6 - he was on Arch Linux. Perhaps you can reverse your hasty down-voting?
- alexellisuk 9y ago
- nailer 9y agoSurprised the more common .localdomain is omitted as a domain rather than having a .localhost domain.
- dredmorbius 9y agoor ".lan"
- deleted 9y ago[deleted]
- feelin_googley 9y agoAt least on the OS I use, which is more IPv6 ready than most, /etc/hosts solves this "uncertainty" problem. I have found that failing to include a localhost entry in the HOSTS file can lead to some strange behavior. 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. There should always be a mechanism for the user to override the internet DNS. And applications should continue to respect it.
- cbhl 9y agoI remember in the late 90s running into a "mysterious" problem where www.hotmail.com would fail to load, but hotmail.com (without www.) worked just fine. Spent the better part of a year just remembering to not type "www." until one day they made the domain redirect to the canonical name (breaking both). After asking around a bit, someone showed me where the Windows equivalent of /etc/hosts was, and lo-and-behold, there was an outdated entry for www.hotmail.com there. Deleting the offending line fixed the problem. Desktop computers are actually the odd one out in letting people manually override DNS -- if you want to fix the DNS for a phone or smart tv or thermostat or video game console, you need to configure DHCP and a resolver on a router in the middle.
- the8472 9y ago/etc/hosts also seems to work on android https://android.stackexchange.com/a/110483 https://android.stackexchange.com/a/110483
- cbhl 9y agoOnly if you've rooted your phone, and $EMPLOYER doesn't let rooted phones access certain resources.
- wolfgang42 9y ago> the Windows equivalent of /etc/hosts Which is, bizarrely, etc\hosts (somewhere in C:\Windows\). I've always wondered why they felt the need to make an 'etc' folder just to have the hosts file in it.
- ericfrederich 9y agoSounds reasonable, but would probably break a ton of stuff. Does this provide enough benefits to outweigh the downsides?
- inopinatus 9y agoI would very much like to see this draft extended to cover SRV lookup as well. 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. 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.
- JdeBP 9y agoIndeed. * http://jdebp.eu./FGA/dns-srv-record-use-by-clients.html http://jdebp.eu./FGA/dns-srv-record-use-by-clients.html But what should such a standardized SRV lookup for _proto1._proto2.localhost. yield as the answer? For starters, what port numbers?
- inopinatus 9y agoSRV lookup for localhost names should yield a (probably identical) localhost name that (by the rest of this draft) necessarily then resolves to a loopback address. For ports we have the list of well-known services maintained by IANA, for which an extract appears on many systems in /etc/services. Local configuration can adjust as necessary.
- JdeBP 9y agoLocal configuration cannot adjust as necessary. Remember: the headlined article is something that is being proposed to fix into an RFC, and indeed the whole point of it is to hardwire something that, in fact, is currently a matter of local configuration.
- ccheever 9y agoOne time I was debugging a problem for a user of our desktop software (I work on https://expo.io https://expo.io) 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. Took a while to track that was down. Was both bewildering and sort of satisfying to figure it out in the end.
- tcbawo 9y agoAt 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.
- lloeki 9y agoA similar, common issue is to not have the machine's hostname pointing to a valid IP address in /etc/hosts (99% of the time it should be loopback, some like to point it to a fixed eth0 address), which causes delays in various part of an otherwise fine OS.
- yrro 9y agonss_myhostname fixes this without you having to modify /etc for every host.
- sgtpepper43 9y agoJust add a line your hosts file mapping lolcathost to 127.0.0.1 and you never have to worry about it again. No that's not a typo
- DonHopkins 9y agoThere was the time that Keith Henson tried to explain the local loopback address to Scientology lawyers during a deposition... http://www.cryonet.org/cgi-bin/dsp.cgi?msg=6289 http://www.cryonet.org/cgi-bin/dsp.cgi?msg=6289 Henson: (patiently) It's at 127.0.0.1. This is a loop back address. This is a troll. Lieberman: what's a troll? 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. https://en.wikipedia.org/wiki/Keith_Henson https://en.wikipedia.org/wiki/Keith_Henson
- wyldfire 9y agoWhat's the "'ho" referred to? An alias for Scientology/SeaOrg, or a particular individual?
- zanchey 9y agoWe have two entries in our DNS which point to 127.0.0.1/::1 - localhost and elvis. This enables the following on Solaris and similar systems: $ ping elvis elvis is alive
- dmacedo 9y agoAlso very important to point out; this same standardisation is missing on the TLD level. Both for safeguarding internal use, and making a global TLD reserved on the global DNS zones. You'll find organisations using in production .local .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. More importantly .dev [1] and .zone [2] are now valid TLDs, so watch out people! [1] https://www.iana.org/domains/root/db/dev.html https://www.iana.org/domains/root/db/dev.html [2] https://www.iana.org/domains/root/db/zone.html https://www.iana.org/domains/root/db/zone.html
- hobarrera 9y ago.local is reserved for mDNS too, so using it internally via an authoritative DNS is bound to result in issues.
- TheAceOfHearts 9y agoIMO, a lot of these vanity TLDs are stupid and harmful to the web. macOS has been using .app as its application extension for decades. Now when you want to search for a specific app on the browser you'll have to be more careful. The fact that they allowed .dev, which is a fairly common TLD for development, is pretty unbelievable. I haven't seen any evidence that by allowing companies to register these TLDs we've brought forth some kind of improvement or benefit to users. There's a recent issue with TLDs that makes me particularly angry. There's ongoing work on this homenet spec. Originally it proposed using .home to route exclusively within the local network. But since .home is already used by a large number of people for private purposes, they changed it to .home.arpa. How the heck have we gotten to the point where we can justify allowing .google as a TLD, but we can't reserve something nice and short for non-companies?
- JdeBP 9y agoI noted this some years ago. * http://jdebp.eu./FGA/dns-use-domain-names-that-you-own.html http://jdebp.eu./FGA/dns-use-domain-names-that-you-own.html
- JdeBP 9y agoOn the one hand, this isn't exactly a new idea and in the real world has been happening for years now. * 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. (http://jdebp.eu./Softwares/djbwares/guide/dnscache.html http://jdebp.eu./Softwares/djbwares/guide/dnscache.html) I implemented implicit localhost support in my proxy DNS servers for OS/2, as well. * 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. * Unbound has built-in "local zone" defaults mapping between "localhost." and both 127.0.0.1 and ::1. 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.