After Updating from Fedora 41 to Fedora 43, after a reboot or when switching between different WLANs the DNS resolution is broken from time to time.
resolv.conf shows the DNS servers in the correct order: more /etc/resolv.conf … nameserver 192.168.0.2 nameserver 192.168.0.1 nameserver 8.8.8.8 search becke.ch …
(/etc/resolv.conf is symlinked to /run/systemd/resolve/resolv.conf)
BUT some applications for example Thunderbird report an error “Could not connect to mail server mail….becke.ch; the connection was refused“ AND “resolvectl status” returns the WRONG Current DNS Server:
resolvectl status Global Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported resolv.conf mode: uplink … Link 3 (wlp0s20f3) Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 Protocols: +DefaultRoute LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported Current DNS Server: 8.8.8.8 DNS Servers: 192.168.0.2 192.168.0.1 8.8.8.8 DNS Domain: becke.ch Default Route: yes …
WORKAROUND:
A) Disable and Re-Enable the WLAN (this works from time to time).
B) OR run “sudo systemctl restart systemd-resolved” (but after some “Suspends” without rebooting the problem is back from time to time)
After running “sudo systemctl restart systemd-resolved”, “resolvectl status” returns the correct Current DNS Server:
resolvectl status Global Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported resolv.conf mode: uplink … Link 3 (wlp0s20f3) Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 Protocols: +DefaultRoute LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported Current DNS Server: 192.168.0.2 DNS Servers: 192.168.0.2 192.168.0.1 8.8.8.8 DNS Domain: becke.ch Default Route: yes …
Maybe this Problem is related to: “After Updating to Fedora 42, DNS resolution is broken until systemd-resolved is restarted” (at least I got the hint from there that running “sudo systemctl restart systemd-resolved” solves the DNS issue … temporarily …)
No I have not (at least not intentionally and therefore I double checked running “sudo dnf list | grep opensnitch” and “sudo systemctl | grep opensnitch” - and no OpenSnitch is not installed/running)
The service does not care which resolver you want, they are all considered valid and any one from the list can be selected at random later for load balancing.
If you want to exclude Google DNS, stop announcing it on the router or switch to manual DNS configuration on the client.
Thank you. I think this might fix the symptom but not the root cause:
The DNS resolution has always been working in Fedora 41.
According to resolv.conf - which always lists the DNS Servers in the correct orders (see my initial analysis on top) : “… nameserver Name server IP address … Up to MAXNS (currently 3, see <resolv.h>) name servers may be listed, one per keyword. If there are multiple servers, the resolver library queries them in the order listed… The algorithm used is to try a name server, and if the query times out, try the next, until out of name servers, …“ this is not at all a random load balancing algorithm. My DNS 192.168.0.2 is and has always been up and running so there is not time out.
Therefore according to “After Updating to Fedora 42, DNS resolution is broken until systemd-resolved is restarted“ I think the problem is related to: “It seems like systemd-resolved.service was starting too early, before the network connection (and DNS info) was actually ready.“
Do you know why DNS resolving has been working stable in Fedora 41 and is now randomly failing in 43? What has been changed? Is there a way to go back or even use the legacy fallback option? I have now tried running multiple times “sudo systemctl restart systemd-resolved” and checked with “resolvectl status” and the “Current DNS Server” was always set correct to “192.168.0.2” no random round-robin. So for now whenever Thunderbird tells me “Could not connect to mail server …; the connection was refused” I will run “sudo systemctl restart systemd-resolved” which symptomatically fixes the problem until this issue has been fixed (maybe I even make it a cron job running every minute :-D).
You can change it by edititing /etc/NetworkManager/NetworkManager.conf according the the manual page for NetworkManager.conf. Run the command man NetworkManager.conf to display it or google for “man NetworkManager.conf”.
The option dns=default should revert back to do direct dns lookup without systemd-resolved. Perhaps you also need to disable systemd-resoled.service.
However, this does not really matter as even deducing the cause will not change the fact that systemd-resolved does not support strict DNS order.
The only way to make it stable is convincing the devs that this feature is important and should be officially supported upstream, but this is even less realistic because it’s a faulty legacy paradigm.
Thank you. I would not agree that it is a faulty legacy paradigm. I think the best solution would have been to make this configurable. I will try to modify “/etc/nsswitch.conf“, line “hosts: …” and move “dns“ resolution to the beginning after “files myhostname mdns4_minimal“.
Just disable that systemd abomination. You don’t need it to resolve domains.
Here’s how to do it step by step:
sudo systemctl disable --now systemd-resolved
Next, edit NetworkManager’s config to set it as the default DNS handler. Open /etc/NetworkManager/NetworkManager.confand add this:
[main] dns=default
Restart NetworkManager to apply the changes:
sudo systemctl restart NetworkManager
After that, check your DNS with
nmcli device show | grep -i dns
it should show the correct servers from your network.
This setup has always worked for me, no issues at all. I did this right after my F42 install, and the upgrade to 43 didn’t affect it. systemd is a cancer, though; it just grows its badly written services everywhere, complicating simple things like DNS that NetworkManager handles perfectly on its own.
DNS not working anymore. After applying your changes and disabling “systemd-resolved“ and rebooting, DNS was not working anymore and for example the file “/etc/resolv.conf” was gone. I’ve now reverted the changes and at least DNS is working most of the time with the issue described above.
Just tested it on another PC, not even Fedora, but Raspberry Pi with systemd-resolved.
Disabled and stopped the service: $ systemctl status systemd-resolved ○ systemd-resolved.service - Network Name Resolution Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service;disabled; preset: enabled) Active: inactive (dead)
Rebooted, and DNS is still working:
$ cat /etc/resolv.conf # Generated by NetworkManager nameserver x nameserver x
$ dig ``google.com`` ; <<>> DiG 9.20.15-1~deb13u1-Debian <<>> ``google.com`` ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35131 ;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;``google.com``. IN A ;; ANSWER SECTION: google.com``. 48 IN A 142.250.129.101 google.com``. 48 IN A 142.250.129.139 google.com``. 48 IN A 142.250.129.100 google.com``. 48 IN A 142.250.129.113 google.com``. 48 IN A 142.250.129.102 google.com``. 48 IN A 142.250.129.138 ;; Query time: 3 msec ;; SERVER: x#53(x) (UDP) ;; WHEN: Tue Jan 13 07:11:36 GMT 2026 ;; MSG SIZE rcvd: 135
That makes me think, that your original issue plus inability to have DNS working after disabling systemd-resolved could have its source elsewhere.
Please check if you have Network Manager installed and working, and nmcli status show outputs the result.
Thank you @vekruse and @dnfuq . Finally only the steps regarding “rm /etc/resolv.conf“ and “touch /etc/resolv.conf“ were missing and now everything is ok. The final sequence of commands is as follows:
no systemd bloat. 