Some notes on systemd-resolved, the systemd DNS resolver

December 12, 2017

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.

  • glibc's 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 resolve in your hosts: line in /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 resolve module 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 network's DHCP.

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).


Comments on this page:

From 193.219.181.219 at 2017-12-13 01:07:00:

Systemd actually seems to be trying to steal networking from NetworkManager, or at least a lot of it.

If you're talking about NM learning to autoconfigure systemd-resolved, I'd rather call that "replacing the massive resolvconf shellscript" than stealing much of anything.

That said, the dns= and rc-manager= options in NetworkManager.conf(5) might be worth taking a look. Especially if you do use resolvconf/OpenResolv to propagate settings to Unbound, you'll want to switch that back on.

(...and I suppose then you can use resolvconf/OpenResolv to propagate settings to systemd-resolved, just to add to the mess.)

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).

For resolving, just the NSS module and the systemd-resolve tool. I really don't think the interface will become widespread; at most, programs will likely just use it for "progressive enhancement" on top of getaddrinfo (for obtaining DNSSEC information and such).

NetworkManager uses the API for configuring nameservers, and I think OpenVPN is planning to have the same ability. But that only matters if you use systemd-resolved in the first place.

By samis at 2017-12-13 02:42:15:

I've never liked resolved, given that all my boxen have a local DNS resolver as standard (either Dnsmasq or Unbound). A snippet from a server's configuration reflecting this:

killResolved = combineProperties "systemd-resolved is disabled in favour of      local DNS" $ props
  & notRunning resolved
  & File.hasContent "/etc/resolv.conf" [ "nameserver 127.0.0.1" ]

Samuel Hodgkins

By cks at 2017-12-14 11:13:00:

The side of systemd stealing (some) networking from NetworkManager that I was thinking of is systemd-networkd, where systemd wants to do at least simple networking setups itself. Possibly this is friendlier and more cooperative than it looks like from my outside perspective.

(As an outsider, it looks like systemd-networkd and NetworkManager are duplicating work, with NetworkManager being there first.)

From 47.8.93.158 at 2018-02-03 09:07:21:

The libidn2 bug you linked to was at that point marked experimental in the NEWS file, the user runs Gentoo and enabled the idn2 USE flag on sys-apps/systemd. So, it was not a bug in the sense that it would break your setup (you were not supposed to turn it on), and the wrong behaviour was actually in libidn2. We still use libidn here.

Written on 12 December 2017.
« Some things about booting with UEFI that are different from MBR booting
Our Apache file serving problem on our general purpose web server »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Tue Dec 12 19:47:22 2017
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.