You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Local applications may submit network name resolution requests via three interfaces:
The native, fully-featured API systemd-resolved exposes on the bus, see org.freedesktop.resolve1(5) and (org.freedesktop.LogControl1(5))[https://www.freedesktop.org/software/systemd/man/org.freedesktop.LogControl1.html] for details. Usage of this API is generally recommended to clients as it is asynchronous and fully featured (for example, properly returns DNSSEC validation status and interface scope for addresses as necessary for supporting link-local networking).
The glibc getaddrinfo(3) API [...]. This API is widely supported, including beyond the Linux platform. In its current form it does not expose DNSSEC validation status information however, and is synchronous only.
Currently we use getaddrinfo and threads, which is a sane default, however having the ability to access the D-Bus interface could simplify things quite a bit, especially given how widespread systemd is. One of the main drawbacks of DNS resolution at the moment is that it keeps on spawning threads (and having expensive module ctors, we're seeing the hit).
The text was updated successfully, but these errors were encountered:
Source
Currently we use
getaddrinfo
and threads, which is a sane default, however having the ability to access the D-Bus interface could simplify things quite a bit, especially given how widespread systemd is. One of the main drawbacks of DNS resolution at the moment is that it keeps on spawning threads (and having expensive module ctors, we're seeing the hit).The text was updated successfully, but these errors were encountered: