4 ms·

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

nomadluap 3y ago
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.
- kccqzy 3y ago
  Completely agree. Just use systemd-resolved which is the recommended way of doing DNS anyway.
  - guappa 3y ago
    And how do you communicate with systemd-resolved?
    - mambru 3y ago
      Via DBus: https://www.freedesktop.org/software/systemd/man/org.freedesktop.resolve1.html https://www.freedesktop.org/software/systemd/man/org.freedes...
      - guappa 3y ago
        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
        kccqzy 3y ago
        And guess what. A UNIX socket does not use DNS or the damned getaddrinfo() function that's the ire of the article.
LoganDark 3y ago
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.
- JackSlateur 3y ago
  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 ?
  - LoganDark 3y ago
    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.

kccqzy 3y ago
Completely agree. Just use systemd-resolved which is the recommended way of doing DNS anyway.
- guappa 3y ago
  And how do you communicate with systemd-resolved?
  - mambru 3y ago
    Via DBus: https://www.freedesktop.org/software/systemd/man/org.freedesktop.resolve1.html https://www.freedesktop.org/software/systemd/man/org.freedes...
    - guappa 3y ago
      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
      - kccqzy 3y ago
        And guess what. A UNIX socket does not use DNS or the damned getaddrinfo() function that's the ire of the article.

LoganDark 3y ago

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.

JackSlateur 3y ago
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 ?
- LoganDark 3y ago
  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?