Having an emergency backup DNS resolver with systemd-resolved

October 24, 2024

At work we have a number of internal DNS resolvers, which you very much want to use to resolve DNS names if you're inside our networks for various reasons (including our split-horizon DNS setup). Purely internal DNS names aren't resolvable by the outside world at all, and some DNS names resolve differently. However, at the same time a lot of the host names that are very important to me are in our public DNS because they have public IPs (sort of for historical reasons), and so they can be properly resolved if you're using external DNS servers. This leaves me with a little bit of a paradox; on the one hand, my machines must resolve our DNS zones using our internal DNS servers, but on the other hand if our internal DNS servers aren't working for some reason (or my home machine can't reach them) it's very useful to still be able to resolve the DNS names of our servers, so I don't have to memorize their IP addresses.

A while back I switched to using systemd-resolved on my machines. Systemd-resolved has a number of interesting virtues, including that it has fast (and centralized) failover from one upstream DNS resolver to another. My systemd-resolved configuration is probably a bit unusual, in that I have a local resolver on my machines, so resolved's global DNS resolution goes to it and then I add a layer of (nominally) interface-specific DNS domain overrides that point to our internal DNS resolvers.

(This doesn't give me perfect DNS resolution, but it's more resilient and under my control than routing everything to our internal DNS resolvers, especially for my home machine.)

Somewhat recently, it occurred to me that I could deal with the problem of our internal DNS resolvers all being unavailable by adding '127.0.0.1' as an additional potential DNS server for my interface specific list of our domains. Obviously I put it at the end, where resolved won't normally use it. But with it there, if all of the other DNS servers are unavailable I can still try to resolve our public DNS names with my local DNS resolver, which will go out to the Internet to talk to various authoritative DNS servers for our zones.

The drawback with this emergency backup approach is that systemd-resolved will stick with whatever DNS server it's currently using unless that DNS server stops responding. So if resolved switches to 127.0.0.1 for our zones, it's going to keep using it even after the other DNS resolvers become available again. I'll have to notice that and manually fiddle with the interface specific DNS server list to remove 127.0.0.1, which would force resolved to switch to some other server.

(As far as I can tell, the current systemd-resolved correctly handles the situation where an interface says that '127.0.0.1' is the DNS resolver for it, and doesn't try to force queries to 127.0.0.1:53 to go out that interface. My early 2013 notes say that this sometimes didn't work, but I failed to write down the specific circumstances.)


Comments on this page:

By adrien at 2024-10-25 03:11:42:

The behavior when a server becomes unavailable is definitely sub-par.

I was recently on some wireless network and link quality was sometimes very low. It was all I had anyway and it was usable. At some point, systemd-resolved decided the DNS server was not answering and stopped using it. It was the only resolver available. And it would never attempt to use it again and systemd-resolved turned a very transient issue with link quality into a permanent one.

I hadn't lost the link (and for a good reason). I think that disconnecting and re-connecting would have "solved" it but that's not a real solution.

By Miksa at 2024-10-28 07:49:36:

I wish systemd-resolved had a parallel operation mode. Nowadays DNS is so lightweight compared to everything else there is no need to stick to one server. Query every DNS server every time and the fastest one wins. If you need to prioritize them maybe set a delay for some them.

Written on 24 October 2024.
« Doing basic policy based routing on FreeBSD with PF rules
Using pam_access to sometimes not use another PAM module »

Page tools: View Source, View Normal.
Search:
Login: Password:

Last modified: Thu Oct 24 23:08:43 2024
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.