91–100 of 179 posts
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]). 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 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
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.
If 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.
Earlier quoted context omitted.
The anagram alcolhost would be a nice one too
"St Alcohol" and "Alcohol St" are also good anagrams
At 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 fo…
I 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, the…
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]). That does remind me of the times I was dealing with weird connection issues in some critical s…
But a lot of standard libraries (including parts of Java and Go) get this wrong, and pick exactly one IP address arbitrarily. When you combine a buggy client with a buggy server, and their preferences for IPv4/IPv6 disagree, then all hell breaks loose.
These are the open bugs I'm aware of:
Sounds reasonable, but would probably break a ton of stuff. Does this provide enough benefits to outweigh the downsides?
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.
Earlier quoted context omitted.
> 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…
I agree about getaddrinfo(). Applications should have specified AF_INET to gethostbyname() and then when updating to getaddrinfo(), handle ipv6 correctly or skip it. The IPv4-mapped IPv6 addresses thing is a terrible idea that ends up turned off everywhere it makes a difference. Like all of these "transition" ideas, it tries to help, but it just hurts by causing admins/ops/devs to just make sure ipv6 is off everywher…