I've had web browsers perform a web search for 'localhost', or even just redirect me to localhost.com. Annoying.
Yeah. The ancients speak of a time when address and search bars where separated.
I think it's a legend.
Internet Draft: Let 'localhost' be localhost
71–80 of 179 posts
Re: Internet Draft: Let 'localhost' be localhost
#72First, 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 s…
Hello me from last week. Had exactly this bug, sometimes nginx couldn't connect to the backend (but very rarely, and not reproducible on demand), which I eventually tracked to the fact that localhost sometimes resolved to ::1 instead of 127, which is what the backend was listening on. Still don't understand why it was only like 1 in 1000 requests, and not every or every other request. Just one more slice of ipv6 myst…
Is the Nginx client using the happy eyeballs algorithm?
https://en.m.wikipedia.org/wiki/Happy_Eyeballs
Can be a source of race conditions.
Re: Internet Draft: Let 'localhost' be localhost
#73Re: Internet Draft: Let 'localhost' be localhost
#74Does this mean that an entry in /etc/hosts assigning ip to localhost will be ignored?
Well, the explicit intent of the proposal is to hardwire the localhost = 127.0.0.1 / ::1 mapping, so my guess is yes.
Re: Internet Draft: Let 'localhost' be localhost
#75Does this mean that an entry in /etc/hosts assigning ip to localhost will be ignored?
Not 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.
Re: Internet Draft: Let 'localhost' be localhost
#76Does this mean that an entry in /etc/hosts assigning ip to localhost will be ignored?
Well, the explicit intent of the proposal is to hardwire the localhost = 127.0.0.1 / ::1 mapping, so my guess is yes.
That is not the effect of the draft. The effect is that localhost = lo0. Other addresses are valid.
Re: Internet Draft: Let 'localhost' be localhost
#77First, 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 s…
> and that breaks everything If you're on a POSIX system, I'd argue that this is a bug in the client. Typically, the client should call getaddrinfo(3); as part of that, the application would either specify directly that it's only interested in AF_INET results, or just filter out non-AF_INET results. (Further, if you support IPv6 in the client, and thus request such results from getaddrinfo, you should skip to the nex…
The mechanism you alluded to (dual binding--receiving IPv4-mapped IPv6 addresses on an IPv6 socket) requires explicitly disabling the IPV6_V6ONLY option on each socket. Some systems have IPV6_V6ONLY as the default; I think modern FreeBSD releases do this out-of-the-box. I don't think many Linux distributions enable IPV6_V6ONLY by default, but administrators can enable it globally, necessitating a per-socket reversion.
Some systems, like OpenBSD, don't even support disabling IPV6_V6ONLY and therefore don't support dual binding at all. OpenBSD contentiously argues that dual binding is likely to lead to security exploits as applications that naively bind to "::" might not expect to de-queue IPv4-mapped IPv6 addresses, consequentially possibly breaking their local access control logic. For example, they may setup firewalls rules that restrict access to the IPv6 port but forget to set the same restrictions on IPv4 ports.
I'm not sure I agree with OpenBSD's approach, but in any event applications should explicitly disable the IPV6_V6ONLY socket option if they're relying on dual binding. Ideally they should use two different sockets; one for each address family. If the application stack doesn't make it easy to listen on multiple sockets, that's a strong hint that the design is broken.
Re: Internet Draft: Let 'localhost' be localhost
#78Earlier quoted context omitted.
I hope you don't publish that record to the world.
Why?
Same-site scripting:
Re: Internet Draft: Let 'localhost' be localhost
#79Earlier quoted context omitted.
I always have local.my company.com DNS that resolves to 127.0.0.1. I can get a valid cert that way too.
I hope you don't publish that record to the world.
It's already been done: https://git.daplie.com/Daplie/localhost.daplie.me-certificat...
Which I find to be a very practical solution for connecting to localhost over https, it frees you from having to install a self-signed certificates/CAs on your machine.
Re: Internet Draft: Let 'localhost' be localhost
#80First, 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 s…
> and that breaks everything If you're on a POSIX system, I'd argue that this is a bug in the client. Typically, the client should call getaddrinfo(3); as part of that, the application would either specify directly that it's only interested in AF_INET results, or just filter out non-AF_INET results. (Further, if you support IPv6 in the client, and thus request such results from getaddrinfo, you should skip to the nex…
Does it matter if it's a bug in the client?
Make it work like expected.
Especially when changing infrastructure like IPV4->IPV6 - don't break existing userbase code! (This is a fundamental precept of Linux development.)