After Updating to Fedora 42, DNS resolution is broken until systemd-resolved is restarted

Ask Fedora
, ,
1

Pretty much title. I took the update to Fedora 42 (KDE) today, all appeared to go very smoothly, except upon reboot, DNS resolution was totally broken. After performing sudo systemctl restart systemd-resolved all goes back to normal. Until the next boot, and then the same thing happens.

The results of ‘journalctl -u systemd-resolved.service’ appear to be pretty normal from what I can see:

And I tried searching but got much older posts with kind of scattered discussion, so I couldn’t find a definitive answer for the cause of this.

1 Like
3

I have the same issue.

In my case, before manually restarting systemd-resolved.service, the resolvectl status commands returns:

Global
Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Failed to get link data for 2: Unknown object '/org/freedesktop/resolve1/link/_32'.
Failed to get link data for 3: Unknown object '/org/freedesktop/resolve1/link/_33'.
# ... (and so on for other links)

It seems like systemd-resolved.service was starting too early, before the network connection (and DNS info) was actually ready.

This workaround fixed it for me:

  1. Create a file named /etc/systemd/system/systemd-resolved.service.d/delay-start.conf
  2. Put this inside:
[Unit]
Before=
After=NetworkManager-wait-online.service
Before=nss-lookup.target network.target
  1. Reboot

Hope this also works for you.

4 Likes
4

I believe this is indeed what’s happening! My resolvectl status didn’t show any errors, but I actually stumbled across a similar solution early this morning, what I did was:

sudo systemctl edit systemd-resolved

And inserted:
[Unit]
After=NetworkManager.service

Not sure which is the “proper” way to do it but this accomplished the same thing and it seems to be good now!

3 Likes
5

Same thing happened to me after upgrading from 41.

Used 2nd method editing systemd-resolved boot order.
However, currently my logs have numerous different warnings like:
'sockets.target: Job virtlockd.socket/start deleted to break ordering cycle starting with sockets.target/start'

1 Like
6

Thank you folks, the workaround mentioned by @kyonerd worked for me. Should this be raised as a bug?

7

So, as you’re already the fourth I feel like the bug report should be raised.
However, I don’t see that anybody from the team is concerned..

P.S. I reverted those changes in order to be able to see if that’s fixed

8

Made an account to say add a +1. I upgraded ~4 hours ago and experienced this same issue and fix.

1 Like
9

I also experienced this issue, on Workstation 42. @stadsport’s solution worked for me. Seems to be fairly common, so I hope this will be addressed.

1 Like
10

Submitted.

Actually, in my case the second solution is the only which works.

3 Likes
11

Thank you Tim! I’ll make an account on there so I can +1 it too.

1 Like
12

@stadsport could you pls check if you have any SELinux warnings?

sudo ausearch -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR -ts recent

I was tinkering with that a bit, seems it’s not correlated, though..

13

I have exactly the same problem after upgrade.
sudo systemctl restart systemd-resolved works fine and I decided to enter it manually each time after boot.

14

I got “no matches” so I suppose not!

15

okay, thanks! that’s not the issue then

1 Like
16

Small update:

Gave up tinkering. So as I’m already using NextDNS.
Easily installed nextdns-cli, disabled systemd-resolved.
It works via DoH with support of ECH, iirc it didn’t work through systemd-resolved’s DoT.

17

Had this identical problem after f41->f42 upgrade today (5/1/2025). The solution proposed by kyonerd worked for me.

18

Got the same problem both when installing F42 KDE from scratch a couple weeks ago, and after upgrading F41 to F42 just yesterday.

I can’t believe that the new version could be shipped that way without noticing such a major problem during exhaustive pre-release testing, and, moreover, wasn’t fixed in almost a month, so there should be something “special” about our particular case I guess.

I can’t find anything that special about my config though, but there are two things which may be slightly uncommon for an average Fedora use case:

  1. I run F42 on KVM VMs
  2. I use static IP configuration

Aside from that, there was no other “oddities” in my case I could think of.
When I installed F42 from scratch, setting the static IP during installation was basically the only thing I configured before experiencing DNS issues right on the first boot.

19

Wow, that’s something new, having that issue after a fresh install!

I was thinking about it as well.
So, in my case, the IP is obtained via DHCP and I use my laptop.
I’m using Opensnitch, however, I tried different configs and seems like it didn’t interfere.

I tried the latest systemd 257.5 today, but it didn’t yield positive results.

Because the “solution” is already available :wink:

Maybe we should try seeking help in systemd’s Github Issue tracker?

20

You just reminded me, I have OpenSnitch as well. Maybe that’s a common denominator? Anyone else?

21

I also had the same issue and OpenSnitch installed