Some notes on systemd-resolved, the systemd DNS resolver
My office workstation's upgrade to Fedora 27 resulted in a little incident with NetworkManager, which I complained about on Twitter; the resulting Twitter conversation brought systemd-resolved to my attention. My initial views weren't all that positive (because I'm biased here; systemd's recent inventions have often not been good things) but I didn't fully understand its state on my systems, so I wound up doing some digging. I'm still not too enthused, but I've wound up less grumpy than I was before and I'm not going to be forcefully blocking systemd-resolved from running at all just yet.
Systemd-resolved is systemd's DNS resolver. It has three interfaces:
- A DBUS API that's exposed at /org/freedesktop/resolve1. I don't know
how many things use this API (or at least try to use it).
- A local caching DNS resolver at 127.0.0.53 (IPv4 only) that clients
can query to specifically talk to systemd-resolved, even if you have
another local caching DNS server at 127.0.0.1.
getaddrinfo()and friends, which would send all normal hostname lookups off to systemd-resolved. Importantly, this is sanely implemented as a NSS module. If you don't have
/etc/nsswitch.conf, systemd-resolved is not involved in normal hostname resolution.
All of my Fedora machines have systemd-resolved installed as part
of systemd but none of them appear to have the NSS
enabled, so none of them are using systemd-resolved as part of
normal hostname resolution. They do appear to enable the DBus service
(as far as I can sort out the chain of DBus stuff that leads to
unit activation). The systemd-resolved daemon itself is not normally
running, and there doesn't seem to be any systemd socket stuff that
would activate it if you sent a DNS query to port 53 on 127.0.0.53,
so on my Fedora machines it appears the only way it will ever start
is if something makes an explicit DBus query.
However, once activated resolved has some behaviors that I don't think I'm fond of (apart from the security bugs and the regular bugs). I'm especially not enthused about its default use of LLMNR, which will normally see it broadcasting certain DNS queries out on all of my active interfaces. I consider LLMNR somewhere between useless and an active risk of various things, depending on what sort of network I'm connected to.
Resolved will make queries to DNS servers in parallel if you have
more than one of them available through various paths, but here I
think it's a reasonable approach to handling DNS resolution in the
face of things like VPNs, which otherwise sort of requires awkward
hand configuration. It's unfortunate that this
behavior can harm people who know what they're doing and who want
behavior like their local DNS resolver (or
resolv.conf) to always
override the DNS resolver settings they're getting from some random
Since resolved doesn't actually shove itself in the way of anyone who didn't actively ask for it (via DBus or querying 127.0.0.53), I currently feel it's unobjectionable enough to leave unmasked and thus potentially activated via DBus. Assuming that I'm understanding and using journalctl correctly, it never seems to have been activated on either of my primary Fedora machines (and they have journalctl logs that go a long way back).