3 ms·

Which is why I have gotten rid of getaddrinfo() calls in my server code, and rather resolve DNS directly reading the DNS server setting from the system. Other

Which is why I have gotten rid of getaddrinfo() calls in my server code, and rather resolve DNS directly reading the DNS server setting from the system. Other issues I faced : - Not epoll() friendly. Always forks a process while resolving domain name. - Valgrind complains of uninitialized memory touches when the function is called and I can't get rid of it.

AceJohnny2 3y ago
how confident are you that the DNS settings you are honoring are the ones the user intended? For example, in a split-VPN situation?
- habibur 3y ago
  Those redirections happen further in the stack. You are ok reading settings from /etc/resolve.conf, which frequently points to a localhost daemon that redirects your calls to whatever DNS setting you have in your connection. But parsing /etc/resolve.conf and using it is all that you need in your code.
  - guappa 3y ago
    And your code correctly parses all the options that can be in that file?
    - habibur 3y ago
      You don't need all the options. Search google. Parsing resolve.conf is an old technique and the file was written assuming individual apps will be parsing it. You will find instructions on how to do it in say 4 lines. Explicitly for this file. Not any random conf file from the system.
      - guappa 3y ago
        Then your application won't be portable. Which is fine if you have no plans of distributing it. But otherwise I can guarantee it will break on some machine.
  - uxp8u61q 3y ago
    Your complete lack of mention of nsswitch.conf makes me believe that you're not implenting anything correctly in this instance.
  - Karellen 3y ago
    * /etc/resolv.conf
- krab 3y ago
  If it's your application on your server, you can be pretty confident. Only later, it may surprise someone why doesn't this application react to system-wide config. Or it may never happen.
q3k 3y ago
> Which is why I have gotten rid of getaddrinfo() calls in my server code, and rather resolve DNS directly reading the DNS server setting from the system. This works as long as you don't need support for mDNS or LDAP host resolution, which depends on libnss/nsswitch on glibc-based systems. Which is fine, but should be a well documented limit of this of approach. (this is also what the Go runtime does by default, but they automatically fall back to the glibc resolver in any more complex case: https://pkg.go.dev/net#hdr-Name_Resolution https://pkg.go.dev/net#hdr-Name_Resolution)

AceJohnny2 3y ago

how confident are you that the DNS settings you are honoring are the ones the user intended? For example, in a split-VPN situation?

habibur 3y ago
Those redirections happen further in the stack. You are ok reading settings from /etc/resolve.conf, which frequently points to a localhost daemon that redirects your calls to whatever DNS setting you have in your connection. But parsing /etc/resolve.conf and using it is all that you need in your code.
- guappa 3y ago
  And your code correctly parses all the options that can be in that file?
  - habibur 3y ago
    You don't need all the options. Search google. Parsing resolve.conf is an old technique and the file was written assuming individual apps will be parsing it. You will find instructions on how to do it in say 4 lines. Explicitly for this file. Not any random conf file from the system.
    - guappa 3y ago
      Then your application won't be portable. Which is fine if you have no plans of distributing it. But otherwise I can guarantee it will break on some machine.
- uxp8u61q 3y ago
  Your complete lack of mention of nsswitch.conf makes me believe that you're not implenting anything correctly in this instance.
- Karellen 3y ago
  * /etc/resolv.conf
krab 3y ago
If it's your application on your server, you can be pretty confident. Only later, it may surprise someone why doesn't this application react to system-wide config. Or it may never happen.

q3k 3y ago

> Which is why I have gotten rid of getaddrinfo() calls in my server code, and rather resolve DNS directly reading the DNS server setting from the system. This works as long as you don't need support for mDNS or LDAP host resolution, which depends on libnss/nsswitch on glibc-based systems. Which is fine, but should be a well documented limit of this of approach. (this is also what the Go runtime does by default, but they automatically fall back to the glibc resolver in any more complex case: https://pkg.go.dev/net#hdr-Name_Resolution https://pkg.go.dev/net#hdr-Name_Resolution)