171–179 of 179 posts
Earlier quoted context omitted.
chrome does this. if i dont specify http or https before domain chrome will try to search any .dev or .loc or ... domain with googe search engine. anoying
I think a trailing slash is what makes Chrome try to resolve instead of searching.
At 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.
A 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.
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…
Some genius at my company decided that ~180,000 Windows endpoints needed "localhost" removed from their hosts file, which has resulted in millions of requests per minute for localhost hitting our resolvers just to return 127.0.0.1. My guess is that it was some hack they tried to disable IPv6, but aside from the insane load it added to the DNS infrastructure, the other result is that if these machines talk to a malici…
I suspect that removing the "localhost." record was nothing to do with IPv6 and everything to do with a corporate policy to not have anything other than the Microsoft default contents in hosts files, possibly because of concerns relating to malware prevention. The problem is possibly the result of the default hosts content changing in Windows NT 6.1.
* https://support.microsoft.com/en-gb/help/972034/
As of Windows NT 6.1, lookups of "localhost." are handled internally within (as I understand) the DNS Client, and never require inspecting a hosts file or sending a query to a DNS server. So the new default hosts file content no longer contains a "localhost." record. But use the Windows NT 6.1 or later default hosts file content on earlier versions of Windows NT, and one will see "localhost." queries being sent by the DNS Client to a server.
Handling "localhost." within the DNS Client is -- reportedly -- so that the DNS Client can inspect the local machine's protocol support and only return non-empty AAAA and A resource record sets if IPv6 or IPv4 is actually enabled on the machine.
* 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) 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.
I 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 resol…
Indeed. * 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?
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.
Earlier quoted context omitted.
Sorry, 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…
I'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 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 IPv…
It's unfortunate, however, that the creator of the video did not capture the output of curl -v, or perhaps even an strace. The logic presented in my first post is nonetheless what curl does, and should apply, so something else is going wrong here. I still think there's a wide difference between "in this particular case, something is causing the IPv6 address to hang" and "Localhost resolving to IPv6 basically breaks with Docker".
Earlier quoted context omitted.
Indeed. * 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?
SRV 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.
Earlier quoted context omitted.
I'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 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 IPv…
Nobody said it broke Docker (it was the resolution that "broke". But the resolution clearly did not work and we had people running through tutorials only to find curl would hang and timeout unless switching to 127.0.0.1 or passing the -4 flag.
Why couldn't they just redirect "localhost" at the DNS level to 127.0.0.1?
Trust: 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…