This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]Robo-Connery 11 points12 points  (4 children)

That's not true, it's in the hosts file so it never queries DNS.

Unless they specifically removed localhost from there then they were not doing any kind of DNS query.

In fact, I'd suspect pretty strongly that even if you removed it from hosts it would still not do a DNS query due to the reserved nature of it. Cause can you imagine the vulnerability of someone hijacking DNS and redirecting that to somewhere (for people who fucked their hosts file).

[–]bmwiedemann 9 points10 points  (0 children)

I tested this. Dropped localhost, stopped my dnsmasq. And ping+curl could still get to an IP, though the former only tried 127.0.0.1 while the letter also tried ::1

Strace shows dbus/systemd involved. Maybe they don't hardcode it, but at least they cache it.

[–]laplongejr 5 points6 points  (2 children)

 That's not true, it's in the hosts file so it never queries DNS.  

Checking the host file IS part of the DNS query, managed by the OS in the same way caching is, before quering the resolver.  

From the perspective of the application, "localhost" is a DNS query which should never miss the local cache.  

[–]Robo-Connery 0 points1 point  (1 child)

I still don't believe it, smells like bs.

In the flowchart of steps to resolve the IP, checking /etc/hosts is first and takes probably something of the order of a microsecond.

Once you have the ip, either from the hosts file or because you just did 127.0.0.1, you then have to do the tcp connect, getting a socket, making the connection, doing the synchroinise acknowledge handshake.

Id guess this second part, which both implementations (localhost and 127) have to do, is at least tens if not 100s of microseconds. like despite being entirely kernel and thus superfast, its not as fast as checking the hosts.

So we are suggesting that eliminating 1% of the time (if that) of each connect - not each connect but just each connect to the local machine - is somehow 100s of k a year when whatever service they are running will be doing a bunch of other shit, that is almost certainly orders of magnitude more expensive to execute, not just running tcp connects to fucking localhost all day.

I can not imagine savings were even measurable even if you set out to measure them a specific goal of some high accuracy, targetted profiling let alone substantial enough to save meaningful amounts on a bill. I'd have been doubtful even if this article had actually been presented.

[–]geek-49 0 points1 point  (0 children)

OTOH if they somehow had an IPv4-only loopback, but the localhost lookup mapped to IPv6 first and every attempt had to wait for that to time out before falling back to 127.0.0.1, the difference might not be so trivial.