systemd-resolved

From https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html:

systemd-resolved is a system service that provides network name resolution to local applications. It implements a caching and validating DNS/DNSSEC stub resolver, as well as an LLMNR and MulticastDNS resolver and responder. 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) 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 as defined by RFC3493 and its related resolver functions, including gethostbyname(3). 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. This API is backed by the glibc Name Service Switch (nss(5)). Usage of the glibc NSS module nss-resolve(8) is required in order to allow glibc’s NSS resolver functions to resolve hostnames via systemd-resolved.

  • Additionally, systemd-resolved provides a local DNS stub listener on the IP addresses 127.0.0.53 and 127.0.0.54 on the local loopback interface. Programs issuing DNS requests directly, bypassing any local API may be directed to this stub, in order to connect them to systemd-resolved. Note however that it is strongly recommended that local programs use the glibc NSS or bus APIs instead (as described above), as various network resolution concepts (such as link-local addressing, or LLMNR Unicode domains) cannot be mapped to the unicast DNS protocol.

The DNS stub resolver on 127.0.0.53 provides the full feature set of the local resolver, which includes offering LLMNR/MulticastDNS resolution. The DNS stub resolver on 127.0.0.54 provides a more limited resolver, that operates in “proxy” mode only, i.e. it will pass most DNS messages relatively unmodified to the current upstream DNS servers and back, but not try to process the messages locally, and hence does not validate DNSSEC, or offer up LLMNR/MulticastDNS. (It will translate to DNS-over-TLS communication if needed however.)

Resolvectl

Some of the systemd-resolved state can be inspected using resolvectl Most notably:

  • resolvectl status [LINK…]: Shows the global and per-link DNS settings currently in effect. If no command is specified, this is the implied default.

  • resolvectl statistics: Shows general resolver statistics, including information whether DNSSEC is enabled and available, as well as resolution and validation statistics.

  • resolvectl reset-statistics: Resets the statistics counters shown in statistics to zero. This operation requires root privileges.

  • resolvectl flush-caches: Flushes all DNS resource record caches the service maintains locally. This is mostly equivalent to sending the SIGUSR2 to the systemd-resolved service.

  • resolvectl reset-server-features: Flushes all feature level information the resolver learnt about specific servers, and ensures that the server feature probing logic is started from the beginning with the next look-up request. This is mostly equivalent to sending the SIGRTMIN+1 to the systemd-resolved service.

  • resolvectl dns [LINK [SERVER…]], resolvectl domain [LINK [DOMAIN…]], resolvectl default-route [LINK [BOOL…]], resolvectl llmnr [LINK [MODE]], resolvectl mdns [LINK [MODE]], resolvectl dnssec [LINK [MODE]], resolvectl dnsovertls [LINK [MODE]], resolvectl nta [LINK [DOMAIN…]]: Get/set per-interface DNS configuration.

Signals

  • Upon reception of the SIGUSR1 process signal systemd-resolved will dump the contents of all DNS resource record caches it maintains, as well as all feature level information it learnt about configured DNS servers into the system logs.
  • Upon reception of the SIGUSR2 process signal systemd-resolved will flush all caches it maintains. Note that it should normally not be necessary to request this explicitly – except for debugging purposes – as systemd-resolved flushes the caches automatically anyway any time the host’s network configuration changes. Sending this signal to systemd-resolved is equivalent to the resolvectl flush-caches command, however the latter is recommended since it operates in a synchronous way.
  • Upon reception of the SIGRTMIN+1 process signal systemd-resolved will forget everything it learnt about the configured DNS servers. Specifically any information about server feature support is flushed out, and the server feature probing logic is restarted on the next request, starting with the most fully featured level. Note that it should normally not be necessary to request this explicitly – except for debugging purposes – as systemd-resolved automatically forgets learnt information any time the DNS server configuration changes. Sending this signal to systemd-resolved is equivalent to the resolvectl reset-server-features command, however the latter is recommended since it operates in a synchronous way.