Name services (DNS) resolver borked after upgrading to Fedora 33





Last Updated on 10/28/2020 by dboth

I just installed Fedora 33 today, the first day it became available. One of the major changes, a switch from the ancient nss resolver to systemd-resolved has already caused me a significant amount of trouble and borked my entire network.

The problem

I run my own name server using BIND on my network server and all has been good for over 20 years. I have configured my DHCP server to provide the IP address of my name server to every workstation that is connected to my network and that, in turn, along with a couple backup name servers, is stored in /etc/resolv.conf.

The introduction of systemd-resolved caused various strange resolution problems on my network hosts. The symptoms varied depending upon the purpose of the host. This mostly presented as inability to find IP addresses for hosts that were inside the network on most systems. On other systems it resulted in failure to resolve any names at all.

It also seems that some programs work and some do not. For example, even though nslookup returned the correct IP addresses for hosts on both inside and outside networks, ping would not contact the designated host. Even more strange, I could ssh to that same host – sometimes.

The new resolver has four operational modes. You can read about them in the link in the first paragraph, above. None of those options seems to work correctly when the network has its own name server which is designed to perform lookups for both internal and external hosts.

The new resolver is supposed to key off which provided configuration that /etc/resolv.conf is a symlink to. You should also read the man page for systemd-resolved but, despite the fact it says that setting /etc/resolv.conf as a symlink to /run/systemd/resolve/resolv.conf should cause the new resolver to work the same way the old one does, it most assuredly does not.

The fix

Although I have seen a number of options for resolving (pun intended) this problem, the only thing I found that works reliably is to stop and disable the new resolver. First I deleted the existing link for resolv.conf and added a new link.

# rm -f /etc/resolv.conf
# ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf

The following commands stop and disable the systemd-resolved service.

# systemctl stop systemd-resolved.service ; systemctl disable systemd-resolved.service
Removed /etc/systemd/system/multi-user.target.wants/systemd-resolved.service.
Removed /etc/systemd/system/dbus-org.freedesktop.resolve1.service.

No reboot is required, the old resolver takes over, and now name services works fine.

I may try to figure out this new resolver but I am no hurry now that I have things working again. One would think that the developers would have figured this all out and fixed it before moving to systemd-resolved as the default host resolver. It is obvious that systemd-resolved needs more work before going mainstream. I think it may have some use in corner use cases that caused a few installations problems but it is a solution in search of a problem for most of us.

Update

2020-10-28

It has been nearly a day since I started updating my systems. What I find is that the later hosts seem to be working fine after perhaps having some time to communicate with each other. Name resolution is working on those hosts when using systemd-resolved.

My thinking is that all the hosts must have the new resolver in order to communicate and build and maintain a local name file. I will try to explore this as I get some time. I also need to experiment with the tools and commands provided with systemd-resolved.