Hacker News Reader

Comment by Sprocklem | Hacker News Reader

How do you propose that DNS resolution precede without opening a socket?

It opens a socket to the same process that called getaddrinfo. That is, it's just communicating with itself, using a brand-new randomly-generated port for each call. This should be completely unnecessary.

So, I have a program that does getaddrinfo(3) and nothing more, and this program setup a socket, listen(2) to it, create another socket and connect with it to the first one ?

This looks insane and not what strace(1) tells me

Could you give me more details ?

I didn't know glibc didn't do the same thing. `getaddrinfo()` on Windows seems to do this because randomly a program will try to connect to `::1:59962` or something, and if I don't allow it in my firewall, it will start whining that some getaddrinfo thread failed to start. This has happened across all sorts of different programs. It's infuriating.

I thought it was just a general libc thing. Isn't there a spec on this somewhere?

For one thing, it could delegate to a local service. Granted, the communication to this service is probably still be over a socket interface, but at least as a purely-local connection you would hopefully have some better worst-case performance characteristics.

This is basically what dnsmasq does when you use it as a local DNS cache.

Completely agree. Just use systemd-resolved which is the recommended way of doing DNS anyway.

And how do you communicate with systemd-resolved?

Via DBus:

https://www.freedesktop.org/software/systemd/man/org.freedes...

dbus is just a protocol that needs something else to actually transfer the data.

Normally, that's a socket in /run/dbus/system_bus_socket

And guess what. A UNIX socket does not use DNS or the damned getaddrinfo() function that's the ire of the article.

Reply on news.ycombinator.com