I'm considering giving in to the systemd-resolved wave

February 9, 2023

I've traditionally had generally lukewarm views on systemd-resolved for my own desktops and our Ubuntu servers. Our Ubuntu servers directly use our local resolving DNS servers and I don't use it on my normal desktops, where I have a somewhat complex local resolver that uses Unbound (I do things like have local names and divert resolution for some domains). But while all of this works today, I feel that in the future my life may be made easier by switching to systemd-resolved, much like I may want to start using a bit of NetworkManager someday.

What makes systemd-resolved interesting, important, and perhaps ultimately inescapable is that it has become the de facto way to mediate among different parties who all want to influence your DNS resolution. Without systemd-resolved, either you get to tell everyone to keep their hands off /etc/resolv.conf and you have to sort it out by hand, or you get systems overwriting each other's work. There are some things I may need to use in the future that very much want to work through systemd-resolved if at all possible, and things like libvirt can apparently be hooked up to resolved to automatically resolve your virtual machine names (a project, an issue with approaches, a blog post).

My current Unbound resolver setup has a number of carefully maintained hacks to divert queries for various DNS zones off to places like our internal DNS resolvers (so that my desktop resolves our local names properly, including split horizon ones). It would be nice to use systemd-resolved to eliminate these, but unfortunately resolvectl has a frustrating limit; while it can selectively divert queries to alternate DNS servers, this diversion must be tied to an interface. As far as I know, you can't tell resolved 'send all .sandbox queries to <our local DNS server>'; instead, you have to say 'due to link X, send all ...'. The 'resolvectl dns' and 'domain' commands that configure this all require a link.

In a world where you're configuring these things because your overlay mesh networking came up and now you need to make DNS resolution understand some special names, this makes perfect sense; the special resolution is tied to the link and will go away when it does. But if you have several sets of diversions to several different DNS servers that are always there, you have to find interfaces to attach the extra ones to. At work I do have these extra interfaces (in the form of VLANs), but it feels ugly; the DNS diversions have nothing to do with the interfaces, I just need something to pacify systemd-resolved. I don't particularly blame resolved for this, because I'm doing something rather outside of its model.

(The Arch Wiki page on systemd-resolved is quite worth reading, as usual.)

PS: As far as I know, you can only attach one set of DNS servers and one set of domain diversions to a given interface. Otherwise I could attach several sets of them to my primary interface, ideally in its systemd-networkd configuration.

Written on 09 February 2023.
« The general 'recursive routing' problem in IP networking
Things that systemd-resolved is not for (as of systemd 251) »

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

Last modified: Thu Feb 9 23:30:49 2023
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.