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).
Source
Currently we use
getaddrinfoand 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).