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

ultranium1 · May 10, 2025, 8:18pm

That’s it!
I completely forgot to mention that I use it.

I just freshly installed a new VM with F42, and DNS worked fine until i installed OpenSnitch 1.6.8.

I knew it couldn’t be Fedora itself causing this problem, but having OpenSnitch working perfectly fine in F40 and F41 made me think it’s not guilty.

dleee · May 10, 2025, 9:24pm

So guys, you won’t believe what happened!

I was tinkering with OpenSnitch (version 1.7.0) again.
This time, I did the following:

Allowed IN/OUT connections.
Turned off OpenSnitch in the GUI.
Disabled GUI autostart.
Ran systemctl disable opensnitchd.service.
Rebooted the system.

Now resolved is working as expected!

I tried reverting the changes step by step, but I couldn’t find the clue.
Whenever OpenSnitch is enabled, the issue returns.

EDIT. Added pool

dleee · May 10, 2025, 9:26pm

Do you use OpenSnitch?

YES
NO

0 voters

z0pyrus · May 10, 2025, 10:04pm

did you enable opensnitch again? Or have you applied the fix from @kyonerd (delay the start through systemd)?

dleee · May 10, 2025, 10:44pm

@z0pyrus in my case the second quoted “solution” is the only helpful.
But I revert systemd-resolved edits to the original state.

I enabled OpenSnitch back, was trying to play with its settings again, but nothing has helped.

As I am using nextdns’s app now there is not an issue, I can disable systemd-resolved at all.

dleee · May 11, 2025, 9:07pm

So, finally I’ve almost found the clue.

Something has changed in the kernel 6.14 and now it’s “conflicting” with eBPF.
Changing Process monitor method to proc resolves the issue.

I’ll open the issue in the OpenSnitch’s github later.

grumpey · May 11, 2025, 9:09pm

For opensnitch this also appears to work … (it’s a bit of a hack … )

sudo systemctl edit opensnitch.service
Add the following:

[Service]
ExecStartPost=/usr/bin/bash -c "sleep 2; /usr/bin/systemctl restart systemd-resolved.service"

pemensik · May 12, 2025, 10:19am

systemd-resolved should be fine with starting before network info is received via DHCP. I think that is quite common and supported. Is there any upstream issue for this problem, created at GitHub - systemd/systemd: The systemd System and Service Manager? I am afraid bugzilla bugs for these kinds of issues are rarely evaluated properly.

Delaying After=network-online.target (which is what After=NetworkManager-wait-online.service does) should not be necessary.

Can you please show resolvectl status output before the restart and after it, when it helps?

Before=network.target and After=network-online.target contradicts itself and is certainly not a proper configuration. In some cases reaching network-online.target might require working DNS resolution, which systemd-resolved is trying to provide as early as possible. It should receive updates when network information is received.

I expect opensnitch may do some actions breaking resolved, which is somehow resilient IMO. I have found just Unstable systemd-resolved with multiple DNS servers · Issue #1040 · evilsocket/opensnitch · GitHub on opensnitch, which is much older than Fedora 42. This does not seem to be component in Fedora

Please create issues both at upstream of opensnitch and systemd (and include links in the other counterpart) and try to include logs of actions done by both of systemd-resolved and opensnitch. Current solution is fine as workaround, but certainly not a long-term solution.

dleee · May 12, 2025, 4:05pm

@pemensik Hello, thanks for chiming in!

The issue wasn’t submitted to the systemd’s github.

That one looks a bit weird.
I feel like this one is closer, as I also sometimes found
[2025-05-04 12:45:58] ERR [eBPF DNS]: unable to load eBPF module (opensnitch-dns.o). Your kernel version (6.14-amd64) might not be compatible. If this error persists, change process monitor method to 'proc'

Mine resolvestl status:

Show

$ resolvectl status
Global
           Protocols: LLMNR=resolve -mDNS +DNSOverTLS DNSSEC=no/unsupported
    resolv.conf mode: stub
  Current DNS Server: 9.9.9.9#dns.quad9.net
         DNS Servers: 9.9.9.9#dns.quad9.net 149.112.112.112#dns.quad9.net 2620:fe::fe#dns.quad9.net
                      2620:fe::9#dns.quad9.net
Fallback DNS Servers: 1.1.1.1#cloudflare-dns.com 1.0.0.1#cloudflare-dns.com
                      2606:4700:4700::1111#cloudflare-dns.com 2606:4700:4700::1001#cloudflare-dns.com

Link 2 (enp0s31f6)
    Current Scopes: none
         Protocols: -DefaultRoute LLMNR=resolve -mDNS +DNSOverTLS DNSSEC=no/unsupported
     Default Route: no

Link 3 (wlp0s20f3)
    Current Scopes: none
         Protocols: +DefaultRoute LLMNR=resolve -mDNS +DNSOverTLS DNSSEC=no/unsupported
       DNS Servers: 192.168.10.1
        DNS Domain: lan
     Default Route: yes

$ ping g.co
ping: g.co: Temporary failure in name resolution

$ systemctl restart systemd-resolved.service

$ ping g.co
PING g.co (142.250.187.206) 56(84) bytes of data.
64 bytes from lhr25s33-in-f14.1e100.net (142.250.187.206): icmp_seq=1 ttl=111 time=53.2 ms

$ resolvectl status
Global
           Protocols: LLMNR=resolve -mDNS +DNSOverTLS DNSSEC=no/unsupported
    resolv.conf mode: stub
  Current DNS Server: 9.9.9.9#dns.quad9.net
         DNS Servers: 9.9.9.9#dns.quad9.net 149.112.112.112#dns.quad9.net 2620:fe::fe#dns.quad9.net
                      2620:fe::9#dns.quad9.net
Fallback DNS Servers: 1.1.1.1#cloudflare-dns.com 1.0.0.1#cloudflare-dns.com
                      2606:4700:4700::1111#cloudflare-dns.com 2606:4700:4700::1001#cloudflare-dns.com

Link 2 (enp0s31f6)
    Current Scopes: none
         Protocols: -DefaultRoute LLMNR=resolve -mDNS +DNSOverTLS DNSSEC=no/unsupported
     Default Route: no

Link 3 (wlp0s20f3)
    Current Scopes: DNS LLMNR/IPv4
         Protocols: +DefaultRoute LLMNR=resolve -mDNS +DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.10.1
       DNS Servers: 192.168.10.1
        DNS Domain: lan
     Default Route: yes

Replying to your message from bugzilla.
Everything seems fine in the log, but DNS isn’t working properly.

It should help if all interactions since boot are displayed in order they happened, for example by command:
journalctl -u systemd-resolved -u NetworkManager

Show

$ journalctl -u systemd-resolved -u NetworkManager
May 12 18:38:48 fedora systemd[1]: Starting systemd-resolved.service - Network Name Resolution...
May 12 18:38:48 fedora systemd-resolved[927]: Positive Trust Anchors:
May 12 18:38:48 fedora systemd-resolved[927]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
May 12 18:38:48 fedora systemd-resolved[927]: . IN DS 38696 8 2 683d2d0acb8c9b712a1948b27f741219298d0a450d612c483af444a4c0fb2b16
May 12 18:38:48 fedora systemd-resolved[927]: Negative trust anchors: home.arpa 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 19.172.in-addr.arpa 20.172.in-addr.arpa 21.172.in-addr.arpa 22.172.in-addr.arpa 23.172.in-addr.arpa 24.172.in-addr.arpa 25.172.in-addr.arpa 26.172.in-addr.arpa 27.172.in-addr.arpa 28.172.in-addr.arpa 29.172.in-addr.arpa 30.172.in-addr.arpa 31.172.in-addr.arpa 170.0.0.192.in-addr.arpa 171.0.0.192.in-addr.arpa 168.192.in-addr.arpa d.f.ip6.arpa ipv4only.arpa resolver.arpa corp home internal intranet lan local private test
May 12 18:38:48 fedora systemd-resolved[927]: Using system hostname 'fedora'.
May 12 18:38:48 fedora systemd[1]: Started systemd-resolved.service - Network Name Resolution.
May 12 18:38:49 fedora systemd[1]: Starting NetworkManager.service - Network Manager...
May 12 18:38:49 fedora NetworkManager[1171]: <info>  [1747067929.8530] NetworkManager (version 1.52.0-1.fc42) is starting... (boot:50b10120-9610-472d-b25a-5b974481b363)
May 12 18:38:49 fedora NetworkManager[1171]: <info>  [1747067929.8532] Read config: /etc/NetworkManager/NetworkManager.conf, /usr/lib/NetworkManager/conf.d/{20-connectivity-fedora.conf,22-wifi-mac-addr.conf,99-nvme-nbft-no-ignore-carrier.conf}, /var/lib/NetworkManager/NetworkManager-intern.conf
May 12 18:38:49 fedora NetworkManager[1171]: <info>  [1747067929.8561] manager[0x55f87c1fc7d0]: monitoring kernel firmware directory '/lib/firmware'.
May 12 18:38:49 fedora NetworkManager[1171]: <info>  [1747067929.8578] hostname: hostname: using hostnamed
May 12 18:38:49 fedora NetworkManager[1171]: <info>  [1747067929.8580] dns-mgr: init: dns=systemd-resolved rc-manager=unmanaged (auto), plugin=systemd-resolved
May 12 18:38:49 fedora NetworkManager[1171]: <info>  [1747067929.8587] rfkill1: found Wi-Fi radio killswitch (at /sys/devices/pci0000:00/0000:00:14.3/ieee80211/phy0/rfkill1) (driver iwlwifi)
May 12 18:38:49 fedora NetworkManager[1171]: <info>  [1747067929.8589] manager[0x55f87c1fc7d0]: rfkill: Wi-Fi hardware radio set enabled
May 12 18:38:49 fedora NetworkManager[1171]: <info>  [1747067929.8589] manager[0x55f87c1fc7d0]: rfkill: WWAN hardware radio set enabled
May 12 18:38:49 fedora NetworkManager[1171]: <info>  [1747067929.8605] Loaded device plugin: NMAtmManager (/usr/lib64/NetworkManager/1.52.0-1.fc42/libnm-device-plugin-adsl.so)
May 12 18:38:49 fedora NetworkManager[1171]: <info>  [1747067929.8632] Loaded device plugin: NMBluezManager (/usr/lib64/NetworkManager/1.52.0-1.fc42/libnm-device-plugin-bluetooth.so)
May 12 18:38:49 fedora NetworkManager[1171]: <info>  [1747067929.8645] Loaded device plugin: NMWifiFactory (/usr/lib64/NetworkManager/1.52.0-1.fc42/libnm-device-plugin-wifi.so)
May 12 18:38:49 fedora NetworkManager[1171]: <info>  [1747067929.8658] Loaded device plugin: NMTeamFactory (/usr/lib64/NetworkManager/1.52.0-1.fc42/libnm-device-plugin-team.so)
May 12 18:38:49 fedora NetworkManager[1171]: <info>  [1747067929.8665] Loaded device plugin: NMWwanFactory (/usr/lib64/NetworkManager/1.52.0-1.fc42/libnm-device-plugin-wwan.so)
May 12 18:38:49 fedora NetworkManager[1171]: <info>  [1747067929.8667] manager: rfkill: Wi-Fi enabled by radio killswitch; enabled by state file
May 12 18:38:49 fedora NetworkManager[1171]: <info>  [1747067929.8667] manager: rfkill: WWAN enabled by radio killswitch; enabled by state file
May 12 18:38:49 fedora NetworkManager[1171]: <info>  [1747067929.8668] manager: Networking is enabled by state file
May 12 18:38:49 fedora NetworkManager[1171]: <info>  [1747067929.8671] settings: Loaded settings plugin: keyfile (internal)
May 12 18:38:49 fedora NetworkManager[1171]: <info>  [1747067929.8749] dhcp: init: Using DHCP client 'internal'
May 12 18:38:49 fedora NetworkManager[1171]: <info>  [1747067929.8750] manager: (lo): new Loopback device (/org/freedesktop/NetworkManager/Devices/1)
May 12 18:38:49 fedora NetworkManager[1171]: <info>  [1747067929.8753] manager: (lo): assume: will attempt to assume matching connection 'lo' (a9a98efe-43b8-4e5b-bdb9-7ca6daa2a33c) (guessed)
May 12 18:38:49 fedora NetworkManager[1171]: <info>  [1747067929.8754] device (lo): state change: unmanaged -> unavailable (reason 'connection-assumed', managed-type: 'assume')
May 12 18:38:49 fedora NetworkManager[1171]: <info>  [1747067929.8757] device (lo): state change: unavailable -> disconnected (reason 'connection-assumed', managed-type: 'assume')
May 12 18:38:49 fedora NetworkManager[1171]: <info>  [1747067929.8761] device (lo): Activation: starting connection 'lo' (a9a98efe-43b8-4e5b-bdb9-7ca6daa2a33c)
May 12 18:38:49 fedora NetworkManager[1171]: <info>  [1747067929.8766] manager: (enp0s31f6): new Ethernet device (/org/freedesktop/NetworkManager/Devices/2)
May 12 18:38:49 fedora NetworkManager[1171]: <info>  [1747067929.8773] settings: (enp0s31f6): created default wired connection 'Wired connection 1'
May 12 18:38:49 fedora NetworkManager[1171]: <info>  [1747067929.8773] device (enp0s31f6): state change: unmanaged -> unavailable (reason 'managed', managed-type: 'external')
May 12 18:38:50 fedora NetworkManager[1171]: <info>  [1747067930.0689] device (wlp0s20f3): driver supports Access Point (AP) mode
May 12 18:38:50 fedora NetworkManager[1171]: <info>  [1747067930.0693] manager: (wlp0s20f3): new 802.11 Wi-Fi device (/org/freedesktop/NetworkManager/Devices/3)
May 12 18:38:50 fedora NetworkManager[1171]: <info>  [1747067930.0695] device (wlp0s20f3): state change: unmanaged -> unavailable (reason 'managed', managed-type: 'external')
May 12 18:38:50 fedora NetworkManager[1171]: <info>  [1747067930.2964] device (wlp0s20f3): set-hw-addr: set MAC address to FF:FF:FF:FF:FF:FF (scanning)
May 12 18:38:50 fedora systemd[1]: Started NetworkManager.service - Network Manager.
May 12 18:38:50 fedora NetworkManager[1171]: <info>  [1747067930.4989] bus-manager: acquired D-Bus service "org.freedesktop.NetworkManager"
May 12 18:38:50 fedora NetworkManager[1171]: <info>  [1747067930.4996] device (lo): state change: disconnected -> prepare (reason 'none', managed-type: 'assume')
May 12 18:38:50 fedora NetworkManager[1171]: <info>  [1747067930.4997] device (lo): state change: prepare -> config (reason 'none', managed-type: 'assume')
May 12 18:38:50 fedora NetworkManager[1171]: <info>  [1747067930.5003] modem-manager: ModemManager available
May 12 18:38:50 fedora NetworkManager[1171]: <info>  [1747067930.5393] device (wlp0s20f3): supplicant interface state: internal-starting -> disconnected
May 12 18:38:50 fedora NetworkManager[1171]: <info>  [1747067930.5394] Wi-Fi P2P device controlled by interface wlp0s20f3 created
May 12 18:38:50 fedora NetworkManager[1171]: <info>  [1747067930.5395] manager: (p2p-dev-wlp0s20f3): new 802.11 Wi-Fi P2P device (/org/freedesktop/NetworkManager/Devices/14)
May 12 18:38:50 fedora NetworkManager[1171]: <info>  [1747067930.5396] device (p2p-dev-wlp0s20f3): state change: unmanaged -> unavailable (reason 'managed', managed-type: 'external')
May 12 18:38:50 fedora NetworkManager[1171]: <info>  [1747067930.5398] device (wlp0s20f3): state change: unavailable -> disconnected (reason 'supplicant-available', managed-type: 'full')
May 12 18:38:50 fedora NetworkManager[1171]: <info>  [1747067930.5401] device (p2p-dev-wlp0s20f3): state change: unavailable -> disconnected (reason 'none', managed-type: 'full')
May 12 18:38:50 fedora NetworkManager[1171]: <info>  [1747067930.5413] device (lo): state change: config -> ip-config (reason 'none', managed-type: 'assume')
May 12 18:38:50 fedora NetworkManager[1171]: <info>  [1747067930.5418] device (lo): state change: ip-config -> ip-check (reason 'none', managed-type: 'assume')
May 12 18:38:50 fedora NetworkManager[1171]: <info>  [1747067930.5424] device (lo): state change: ip-check -> secondaries (reason 'none', managed-type: 'assume')
May 12 18:38:50 fedora NetworkManager[1171]: <info>  [1747067930.5425] device (lo): state change: secondaries -> activated (reason 'none', managed-type: 'assume')
May 12 18:38:50 fedora NetworkManager[1171]: <info>  [1747067930.5427] device (lo): Activation: successful, device activated.
May 12 18:38:53 fedora NetworkManager[1171]: <info>  [1747067933.8021] policy: auto-activating connection 'Dee' (77d5407b-24a9-4ccf-bb2a-3d71d2ab68d4)
May 12 18:38:53 fedora NetworkManager[1171]: <info>  [1747067933.8038] device (wlp0s20f3): Activation: starting connection 'Dee' (77d5407b-24a9-4ccf-bb2a-3d71d2ab68d4)
May 12 18:38:53 fedora NetworkManager[1171]: <info>  [1747067933.8041] device (wlp0s20f3): state change: disconnected -> prepare (reason 'none', managed-type: 'full')
May 12 18:38:53 fedora NetworkManager[1171]: <info>  [1747067933.8047] manager: NetworkManager state is now CONNECTING
May 12 18:38:53 fedora NetworkManager[1171]: <info>  [1747067933.8228] device (wlp0s20f3): set-hw-addr: set-cloned MAC address to FF:FF:FF:FF:FF:FF (stable-ssid)
May 12 18:38:53 fedora NetworkManager[1171]: <info>  [1747067933.8265] device (wlp0s20f3): state change: prepare -> config (reason 'none', managed-type: 'full')
May 12 18:38:53 fedora NetworkManager[1171]: <info>  [1747067933.8271] device (wlp0s20f3): Activation: (wifi) access point 'Dee' has security, but secrets are required.
May 12 18:38:53 fedora NetworkManager[1171]: <info>  [1747067933.8272] device (wlp0s20f3): state change: config -> need-auth (reason 'none', managed-type: 'full')
May 12 18:38:53 fedora NetworkManager[1171]: <info>  [1747067933.8294] device (wlp0s20f3): supplicant interface state: disconnected -> inactive
May 12 18:38:53 fedora NetworkManager[1171]: <info>  [1747067933.8294] device (p2p-dev-wlp0s20f3): supplicant management interface state: disconnected -> inactive
May 12 18:38:53 fedora NetworkManager[1171]: <info>  [1747067933.8297] device (wlp0s20f3): state change: need-auth -> prepare (reason 'none', managed-type: 'full')
May 12 18:38:53 fedora NetworkManager[1171]: <info>  [1747067933.8303] device (wlp0s20f3): state change: prepare -> config (reason 'none', managed-type: 'full')
May 12 18:38:53 fedora NetworkManager[1171]: <info>  [1747067933.8310] device (wlp0s20f3): Activation: (wifi) connection 'Dee' has security, and secrets exist.  No new secrets needed.
May 12 18:38:53 fedora NetworkManager[1171]: <info>  [1747067933.8311] Config: added 'ssid' value 'Dee'
May 12 18:38:53 fedora NetworkManager[1171]: <info>  [1747067933.8311] Config: added 'scan_ssid' value '1'
May 12 18:38:53 fedora NetworkManager[1171]: <info>  [1747067933.8311] Config: added 'bgscan' value 'simple:30:-70:86400'
May 12 18:38:53 fedora NetworkManager[1171]: <info>  [1747067933.8312] Config: added 'key_mgmt' value 'SAE FT-SAE'
May 12 18:38:53 fedora NetworkManager[1171]: <info>  [1747067933.8312] Config: added 'psk' value '<hidden>'
May 12 18:38:53 fedora NetworkManager[1171]: <info>  [1747067933.8312] Config: added 'ieee80211w' value '2'
May 12 18:38:53 fedora NetworkManager[1171]: <info>  [1747067933.8695] device (wlp0s20f3): supplicant interface state: inactive -> authenticating
May 12 18:38:53 fedora NetworkManager[1171]: <info>  [1747067933.8696] device (p2p-dev-wlp0s20f3): supplicant management interface state: inactive -> authenticating
May 12 18:38:54 fedora NetworkManager[1171]: <info>  [1747067934.2446] device (wlp0s20f3): supplicant interface state: authenticating -> associating
May 12 18:38:54 fedora NetworkManager[1171]: <info>  [1747067934.2447] device (p2p-dev-wlp0s20f3): supplicant management interface state: authenticating -> associating
May 12 18:38:54 fedora NetworkManager[1171]: <info>  [1747067934.2888] device (wlp0s20f3): supplicant interface state: associating -> associated
May 12 18:38:54 fedora NetworkManager[1171]: <info>  [1747067934.2889] device (p2p-dev-wlp0s20f3): supplicant management interface state: associating -> associated
May 12 18:38:54 fedora NetworkManager[1171]: <info>  [1747067934.3993] device (wlp0s20f3): supplicant interface state: associated -> 4way_handshake
May 12 18:38:54 fedora NetworkManager[1171]: <info>  [1747067934.3993] device (p2p-dev-wlp0s20f3): supplicant management interface state: associated -> 4way_handshake
May 12 18:38:54 fedora NetworkManager[1171]: <info>  [1747067934.5340] device (wlp0s20f3): supplicant interface state: 4way_handshake -> completed
May 12 18:38:54 fedora NetworkManager[1171]: <info>  [1747067934.5341] device (wlp0s20f3): Activation: (wifi) Stage 2 of 5 (Device Configure) successful. Connected to wireless network "Dee"
May 12 18:38:54 fedora NetworkManager[1171]: <info>  [1747067934.5342] device (p2p-dev-wlp0s20f3): supplicant management interface state: 4way_handshake -> completed
May 12 18:38:54 fedora NetworkManager[1171]: <info>  [1747067934.5954] device (wlp0s20f3): state change: config -> ip-config (reason 'none', managed-type: 'full')
May 12 18:38:54 fedora NetworkManager[1171]: <info>  [1747067934.5968] dhcp4 (wlp0s20f3): activation: beginning transaction (timeout in 45 seconds)
May 12 18:38:54 fedora NetworkManager[1171]: <info>  [1747067934.6056] dhcp4 (wlp0s20f3): state changed new lease, address=192.168.10.101, acd pending
May 12 18:38:54 fedora NetworkManager[1171]: <info>  [1747067934.7697] dhcp4 (wlp0s20f3): state changed new lease, address=192.168.10.101
May 12 18:38:54 fedora NetworkManager[1171]: <info>  [1747067934.7723] policy: set 'Dee' (wlp0s20f3) as default for IPv4 routing and DNS
May 12 18:38:54 fedora systemd-resolved[927]: wlp0s20f3: Bus client set search domain list to: lan
May 12 18:38:54 fedora systemd-resolved[927]: wlp0s20f3: Bus client set default route setting: yes
May 12 18:38:54 fedora systemd-resolved[927]: wlp0s20f3: Bus client set DNS server list to: 192.168.10.1
May 12 18:38:54 fedora NetworkManager[1171]: <info>  [1747067934.7870] device (wlp0s20f3): state change: ip-config -> ip-check (reason 'none', managed-type: 'full')
May 12 18:38:54 fedora NetworkManager[1171]: <info>  [1747067934.7910] device (wlp0s20f3): state change: ip-check -> secondaries (reason 'none', managed-type: 'full')
May 12 18:38:54 fedora NetworkManager[1171]: <info>  [1747067934.7914] device (wlp0s20f3): state change: secondaries -> activated (reason 'none', managed-type: 'full')
May 12 18:38:54 fedora NetworkManager[1171]: <info>  [1747067934.7921] manager: NetworkManager state is now CONNECTED_SITE
May 12 18:38:54 fedora NetworkManager[1171]: <info>  [1747067934.7935] device (wlp0s20f3): Activation: successful, device activated.
May 12 18:38:54 fedora NetworkManager[1171]: <info>  [1747067934.7944] manager: NetworkManager state is now CONNECTED_GLOBAL
May 12 18:38:56 fedora NetworkManager[1171]: <info>  [1747067936.0696] manager: startup complete
May 12 18:39:07 fedora NetworkManager[1171]: <info>  [1747067947.2130] agent-manager: agent[2f35271204525d58,:1.62/org.kde.plasma.networkmanagement/1000]: agent registered
May 12 18:39:08 fedora NetworkManager[1171]: <info>  [1747067948.9732] audit: op="statistics" interface="enp0s31f6" ifindex=2 args="500" pid=1958 uid=1000 result="success"
May 12 18:39:09 fedora NetworkManager[1171]: <info>  [1747067949.0074] audit: op="statistics" interface="wlp0s20f3" ifindex=3 args="500" pid=1958 uid=1000 result="success"
May 12 18:39:09 fedora NetworkManager[1171]: <info>  [1747067949.0403] audit: op="statistics" interface="wlp0s20f3" ifindex=3 args="500" pid=1958 uid=1000 result="success"

dleee · May 12, 2025, 10:59pm

GH issue submitted.

github.com/evilsocket/opensnitch

[Bug Report] OpenSnitch breaks DNS in Fedora 42 (eBPF incompatible with Kernel 6.14)

opened 10:57PM - 12 May 25 UTC

deenle

bug

Hello everybody! The issue appears to be related to the updated Kernel 6.14 and …OpenSnitch (was not in 6.13). Below is a detailed report. ### Describe the bug: If OpenSnitch works in `eBPF` mode on Fedora 42 (Kernel 6.14), the system cannot resolve DNS after boot. Restarting the systemd-resolved service resolves the issue. Alternatively, changing the method to `proc` also resolves the issue. Discussion at Fedora [here](https://discussion.fedoraproject.org/t/after-updating-to-fedora-42-dns-resolution-is-broken-until-systemd-resolved-is-restarted/148836) Bugzilla RedHat bug [2361468](https://bugzilla.redhat.com/show_bug.cgi?id=2361468) Connected to that? https://github.com/evilsocket/opensnitch/discussions/1340 - OpenSnitch version: 1.7.0-rc.2 - OS: Fedora Workstation - OS version: 42 - Window Manager: KDE Plasma - Kernel version: `Linux fedora 6.14.5-300.fc42.x86_64 #1 SMP PREEMPT_DYNAMIC Fri May 2 14:16:46 UTC 2025 x86_64 GNU/Linux` (lockdown=integrity) ### To Reproduce: Steps to reproduce the behavior (100% reproductible): 1. Install/Upgrade to Fedora 42 2. Install OpenSnitch 3. Boot the system 4. DNS resolution will not work after boot 5. Restart the systemd-resolved service using "systemctl restart systemd-resolved" 6. DNS resolution should now be working. ### Post error logs: **I'm sometimes able to find it in opensnitch's logs, but it's not persistent:** ``` [0m [2m [30m[100m DBG [0m Rules watcher started on path /etc/opensnitchd/rules ... [0m [2m [30m[100m DBG [0m [eBPF] trying to load /usr/local/lib/opensnitchd/ebpf/opensnitch-dns.o [0m [2m [30m[100m DBG [0m [eBPF] trying to load /usr/lib/opensnitchd/ebpf/opensnitch-dns.o [0m [97m [42m INF [0m Running on netfilter queue #0 ... [0m [2m [30m[100m DBG [0m [DNS] systemd-resolved monitor response error: &{ [] [] false} [0m [2m [30m[100m DBG [0m [eBPF] trying to load /etc/opensnitchd/opensnitch-dns.o [0m [97m [43m WAR [0m [eBPF DNS]: unable to load eBPF module (opensnitch-dns.o). Your kernel version (6.14.5-300.fc42.x86_64) might not be compatible. If this error persists, change process monitor method to 'proc' [0m [97m [43m WAR [0m EBPF-DNS: Unable to attach ebpf listener: unable to load eBPF module (opensnitch-dns.o). Your kernel version (6.14.5-300.fc42.x86_64) might not be compatible. If this error persists, change process monitor method to 'proc' ``` ``` opensnitchd -check-requirements Checking system requirements for kernel version 6.14.5-300.fc42.x86_64 Checking => CONFIG_KPROBES=y Checking => CONFIG_KPROBES_ON_FTRACE=y Checking => CONFIG_HAVE_KPROBES=y Checking => CONFIG_HAVE_KPROBES_ON_FTRACE=y Checking => CONFIG_KPROBE_EVENTS=y * kprobes ✔ Checking => CONFIG_UPROBES=y Checking => CONFIG_UPROBE_EVENTS=y * uprobes ✔ Checking => CONFIG_FTRACE=y * ftrace ✔ Checking => CONFIG_HAVE_SYSCALL_TRACEPOINTS=y Checking => CONFIG_FTRACE_SYSCALLS=y * syscalls ✔ Checking => CONFIG_NETFILTER_NETLINK_QUEUE=[my] Checking => CONFIG_NFT_QUEUE=[my] Checking => CONFIG_NETFILTER_XT_TARGET_NFQUEUE=[my] * nfqueue ✔ Checking => CONFIG_NETFILTER_NETLINK=[my] Checking => CONFIG_NETFILTER_NETLINK_QUEUE=[my] Checking => CONFIG_NETFILTER_NETLINK_ACCT=[my] Checking => CONFIG_PROC_EVENTS=[my] * netlink ✔ Checking => CONFIG_INET_DIAG=[my] Checking => CONFIG_INET_TCP_DIAG=[my] Checking => CONFIG_INET_UDP_DIAG=[my] Checking => CONFIG_INET_DIAG_DESTROY=[my] * net diagnostics ✔ ``` ``` opensnitchd -debug [2025-05-12 20:31:40] IMP Starting opensnitch-daemon v1.7.0 [2025-05-12 20:31:40] WAR Error loading network aliases: open /etc/opensnitchd/network_aliases.json: no such file or directory [2025-05-12 20:31:40] INF Loading network aliases from /etc/opensnitchd/network_aliases.json [2025-05-12 20:31:40] !!! Error loading configuration /etc/opensnitchd/default-config.json: open /etc/opensnitchd/default-config.json: permission denied ``` ``` objdump -h /usr/lib/opensnitchd/ebpf/opensnitch-dns.o /usr/lib/opensnitchd/ebpf/opensnitch-dns.o: file format elf64-bpfle Sections: Idx Name Size VMA LMA File off Algn 0 .text 00000000 0000000000000000 0000000000000000 00000040 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 uretprobe/gethostbyname 00008a10 0000000000000000 0000000000000000 00000040 2**3 CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE 2 uprobe/getaddrinfo 000001d0 0000000000000000 0000000000000000 00008a50 2**3 CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE 3 uretprobe/getaddrinfo 000040d0 0000000000000000 0000000000000000 00008c20 2**3 CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE 4 maps/addrinfo_args_hash 00000118 0000000000000000 0000000000000000 0000ccf0 2**2 CONTENTS, ALLOC, LOAD, DATA 5 maps/events 00000118 0000000000000000 0000000000000000 0000ce08 2**2 CONTENTS, ALLOC, LOAD, DATA 6 license 00000004 0000000000000000 0000000000000000 0000cf20 2**0 CONTENTS, ALLOC, LOAD, DATA 7 version 00000004 0000000000000000 0000000000000000 0000cf24 2**2 CONTENTS, ALLOC, LOAD, DATA 8 .debug_loc 000078b0 0000000000000000 0000000000000000 0000cf28 2**0 CONTENTS, RELOC, READONLY, DEBUGGING, OCTETS 9 .debug_abbrev 00000166 0000000000000000 0000000000000000 000147d8 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 10 .debug_info 00000888 0000000000000000 0000000000000000 0001493e 2**0 CONTENTS, RELOC, READONLY, DEBUGGING, OCTETS 11 .debug_ranges 000017c0 0000000000000000 0000000000000000 000151c6 2**0 CONTENTS, RELOC, READONLY, DEBUGGING, OCTETS 12 .debug_str 0000053e 0000000000000000 0000000000000000 00016986 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 13 .BTF 00000f27 0000000000000000 0000000000000000 00016ec4 2**0 CONTENTS, RELOC, READONLY 14 .BTF.ext 0000ac50 0000000000000000 0000000000000000 00017deb 2**0 CONTENTS, RELOC, READONLY 15 .eh_frame 00000070 0000000000000000 0000000000000000 00022a40 2**3 CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA 16 .debug_line 00003d2b 0000000000000000 0000000000000000 00022ab0 2**0 CONTENTS, RELOC, READONLY, DEBUGGING, OCTETS ``` Appreciate any support!

Topic		Replies	Views
DNS Broken in Fedora 33 after update Ask Fedora f33 , networking	2	396	June 27, 2021
DNS Issue on first update of Fedora 38 Ask Fedora f38	11	3447	July 7, 2023
NetworkManager.service must be restarted to allow successful DNS resolution Ask Fedora mate , f39 , workstation	2	257	April 19, 2024
Reinstalled systemd / systemd-udev now resolve is broken Ask Fedora systemd , systemd-resolved , workstation , f40	12	469	July 6, 2024
VPN dns problems with systemd-resolved Ask Fedora f35 , systemd-resolved	9	6316	February 4, 2022

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

Related topics