4 ms·

That second parameter could accept a text IP-address eg "192.168.100.100". Like the address bar of a browser.

by ape4 2y ago

braiamp 2y ago
So, the dns lookup is still there, it's just optional. You would have to pass a flag to tell it not to try to do the lookup or you would have to do something fancy trying to know if the passed parameter is an IP.
asveikau 2y ago
This is already how all the DNS lookup APIs work.
- tptacek 2y ago
  The problem is with asking the kernel to perform dns lookups.
  - GauntletWizard 2y ago
    If SystemD had it's way, it would. The local system resolver cache is the default on most systems. DNS is well understood. Why not put it in the Kernel? If you're doing that, though, you'd better dang well give me secure key storage in the Kernel, too, or full TLS capability. Allow my program to n load it's RSA/ECC key at startup, then drop privileges to access that file, and have a kernel module handle the cryptography.
    - tptacek 2y ago
      It extremely doesn't make sense to have a DNS resolver resident in the kernel: DNS resolution is policy-intensive, involves various upgrades to cryptographic transports, and often requires debugging, all weak points of the kernel. Against all that, there's no performance advantage, and doing it admits a new networking API that almost no applications will use --- most new code being written in higher-level languages that already abstract over system calls.
      - GauntletWizard 2y ago
        There's a huge performance advantage, if you ask SystemD - Multiple resolutions can be cached. This is incredible bullshit, of course, but that is one of many lies Pottering has gotten away with.
        toast0 2y ago
        Caching resolutions can be a nice thing, and having in one place can be useful so that the throwing away the cache can be done consistently for all apps when useful (you likely should clear the cache when switching networks, or when the user asks you to), but none of that means it should be a kernel service. If there's enough volume of requests that a kernel level cache meaningfully improves real world scenarios, something is broken in those scenarios. :p (but I think you agree with me)

That second parameter could accept a text IP-address eg "192.168.100.100". Like the address bar of a browser.

by ape4 2y ago

That second parameter could accept a text IP-address eg "192.168.100.100". Like the address bar of a browser.

So, the dns lookup is still there, it's just optional. You would have to pass a flag to tell it not to try to do the lookup or you would have to do something fancy trying to know if the passed parameter is an IP.

asveikau 2y ago

This is already how all the DNS lookup APIs work.

tptacek 2y ago
The problem is with asking the kernel to perform dns lookups.
- GauntletWizard 2y ago
  If SystemD had it's way, it would. The local system resolver cache is the default on most systems. DNS is well understood. Why not put it in the Kernel? If you're doing that, though, you'd better dang well give me secure key storage in the Kernel, too, or full TLS capability. Allow my program to n load it's RSA/ECC key at startup, then drop privileges to access that file, and have a kernel module handle the cryptography.
  - tptacek 2y ago
    It extremely doesn't make sense to have a DNS resolver resident in the kernel: DNS resolution is policy-intensive, involves various upgrades to cryptographic transports, and often requires debugging, all weak points of the kernel. Against all that, there's no performance advantage, and doing it admits a new networking API that almost no applications will use --- most new code being written in higher-level languages that already abstract over system calls.
    - GauntletWizard 2y ago
      There's a huge performance advantage, if you ask SystemD - Multiple resolutions can be cached. This is incredible bullshit, of course, but that is one of many lies Pottering has gotten away with.
      - toast0 2y ago
        Caching resolutions can be a nice thing, and having in one place can be useful so that the throwing away the cache can be done consistently for all apps when useful (you likely should clear the cache when switching networks, or when the user asks you to), but none of that means it should be a kernel service. If there's enough volume of requests that a kernel level cache meaningfully improves real world scenarios, something is broken in those scenarios. :p (but I think you agree with me)