You are not logged in.

Pages: 1

#1 2025-01-20 18:25:23

Larnpixie
Member
Registered: 2025-01-20
Posts: 3

[SOLVED] No DNS until restart systemd-resolved

Hi,
this is my first post here - hope I'm doing this right and haven't forgotten any logs

A few weeks ago my system started behaving differently: the system won't resolve any DNS queries unless I manually restart systemd-resolved.service.
I've tried to double-check my network configuration, but I can't find any configuration problem.

It's a simple desktop computer setup using NetworkManager to manage my wifi connection and systemd-resolved.
NetworkManager has no custom configuration - both IPv4 and IPv6 are set to method=auto.

After booting and successfully connecting to my wifi, 'resolvectl status' looks like this:

Global
           Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
    resolv.conf mode: stub
Fallback DNS Servers: 192.168.178.58

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

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

Link 4 (wlp39s0)
    Current Scopes: none
         Protocols: +DefaultRoute +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
       DNS Servers: 192.168.178.58 fd00::58
        DNS Domain: fritz.box
     Default Route: yes

'systemctl status systemd-resolved.service' seems fine to me:

# systemctl status systemd-resolved.service 
● systemd-resolved.service - Network Name Resolution
     Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; enabled; preset: enabled)
    Drop-In: /etc/systemd/system/systemd-resolved.service.d
             └─override.conf
     Active: active (running) since Mon 2025-01-20 18:02:21 CET; 5min ago
 Invocation: 1d869ad03c6f4c55a91182ef9cb95c32
       Docs: man:systemd-resolved.service(8)
             man:org.freedesktop.resolve1(5)
             https://systemd.io/WRITING_NETWORK_CONFIGURATION_MANAGERS
             https://systemd.io/WRITING_RESOLVER_CLIENTS
   Main PID: 581 (systemd-resolve)
     Status: "Processing requests..."
      Tasks: 1 (limit: 33431)
     Memory: 8.6M (peak: 9.4M)
        CPU: 67ms
     CGroup: /system.slice/systemd-resolved.service
             └─581 /usr/lib/systemd/systemd-resolved

Jan 20 18:02:21 workstation systemd-resolved[581]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
Jan 20 18:02:21 workstation systemd-resolved[581]: 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 >
Jan 20 18:02:21 workstation systemd-resolved[581]: Using system hostname 'workstation'.
Jan 20 18:02:21 workstation systemd[1]: Started Network Name Resolution.
Jan 20 18:02:27 workstation systemd-resolved[581]: Switching to fallback DNS server 192.168.178.58.
Jan 20 18:02:29 workstation systemd-resolved[581]: wlp39s0: Bus client set default route setting: yes
Jan 20 18:02:29 workstation systemd-resolved[581]: Switching to fallback DNS server 192.168.178.58.
Jan 20 18:02:29 workstation systemd-resolved[581]: wlp39s0: Bus client set DNS server list to: fd00::58
Jan 20 18:02:29 workstation systemd-resolved[581]: wlp39s0: Bus client set search domain list to: fritz.box
Jan 20 18:02:29 workstation systemd-resolved[581]: wlp39s0: Bus client set DNS server list to: 192.168.178.58, fd00::58

'resolvectl query ard.de' does not work in this state. However, 'dig ard.de @192.168.178.58' works fine.

My workaround is now to 'systemctl restart systemd-resolved.service'. After this restart, I can't see any difference in my journal expecting the missing fallback entries:

Jan 20 18:02:21 workstation systemd-resolved[581]: Positive Trust Anchors:
Jan 20 18:02:21 workstation systemd-resolved[581]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
Jan 20 18:02:21 workstation systemd-resolved[581]: 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 >
Jan 20 18:02:21 workstation systemd-resolved[581]: Using system hostname 'workstation'.
Jan 20 18:02:21 workstation systemd[1]: Started Network Name Resolution.
Jan 20 18:02:27 workstation systemd-resolved[581]: Switching to fallback DNS server 192.168.178.58.
Jan 20 18:02:29 workstation systemd-resolved[581]: wlp39s0: Bus client set default route setting: yes
Jan 20 18:02:29 workstation systemd-resolved[581]: Switching to fallback DNS server 192.168.178.58.
Jan 20 18:02:29 workstation systemd-resolved[581]: wlp39s0: Bus client set DNS server list to: fd00::58
Jan 20 18:02:29 workstation systemd-resolved[581]: wlp39s0: Bus client set search domain list to: fritz.box
Jan 20 18:02:29 workstation systemd-resolved[581]: wlp39s0: Bus client set DNS server list to: 192.168.178.58, fd00::58
Jan 20 18:22:26 workstation systemd[1]: Stopping Network Name Resolution...
Jan 20 18:22:26 workstation systemd[1]: systemd-resolved.service: Deactivated successfully.
Jan 20 18:22:26 workstation systemd[1]: Stopped Network Name Resolution.
Jan 20 18:22:26 workstation systemd[1]: Starting Network Name Resolution...
Jan 20 18:22:26 workstation systemd-resolved[3660]: Positive Trust Anchors:
Jan 20 18:22:26 workstation systemd-resolved[3660]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
Jan 20 18:22:26 workstation systemd-resolved[3660]: 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>
Jan 20 18:22:26 workstation systemd-resolved[3660]: Using system hostname 'workstation'.
Jan 20 18:22:26 workstation systemd[1]: Started Network Name Resolution.

However, 'resolvectl status' does change a bit (current scope and current DNS server) after the service is restarted:

Global
           Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
    resolv.conf mode: stub
Fallback DNS Servers: 192.168.178.58

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

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

Link 4 (wlp39s0)
    Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 mDNS/IPv4 mDNS/IPv6
         Protocols: +DefaultRoute +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.178.58
       DNS Servers: 192.168.178.58 fd00::58
        DNS Domain: fritz.box
     Default Route: yes
$ ls -l /etc/resolv.conf 
lrwxrwxrwx 1 root root 37 May 14  2021 /etc/resolv.conf -> /run/systemd/resolve/stub-resolv.conf

'/etc/systemd/resolved.conf' is default; I did create '/etc/systemd/resolved.conf.d/fallback_dns.conf' in hope it would solve the issue:

[Resolve]
FallbackDNS=192.168.178.58

I have no idea what the cause of this problem is :\


EDIT: After some more digging, there seems to be some compatibility issues with OpenSnitch. Removing this fixed the problem.

Last edited by Larnpixie (2025-01-20 19:21:56)

Offline

#2 2025-01-20 19:36:23

Awebb
Member
Registered: 2010-05-06
Posts: 6,688

Re: [SOLVED] No DNS until restart systemd-resolved

Opensnitch is a firewall, perhaps it needs some configuration first.

Offline

#3 2025-01-20 19:44:11

Larnpixie
Member
Registered: 2025-01-20
Posts: 3

Re: [SOLVED] No DNS until restart systemd-resolved

Awebb wrote:

Opensnitch is a firewall, perhaps it needs some configuration first.

Sure, I probably screwed something up, but the timeline seems odd to me.
I installed OpenSnitch many moons ago (and forgot about it, to be honest), but these DNS errors only started a few weeks ago.

And isn't it odd that restarting the systemd-resolved service "fixed" the problem? A missing OpenSnitch configuration should still be a problem after restarting the service, shouldn't it?

Offline

#4 2025-01-20 20:40:10

cryptearth
Member
Registered: 2024-02-03
Posts: 1,337

Re: [SOLVED] No DNS until restart systemd-resolved

running both NetworkManager and systemd sounds conflicting
I'm no expert and how to config both - but from many topics I read: either run one or the other - but not both - as when NetworkManager is set to systemd it will start it on its own - so systemd-resolved should be disabled to not autostart on its own and should be restarted on its own but only handled by NetworkManager

Offline

#5 2025-01-20 21:10:40

Larnpixie
Member
Registered: 2025-01-20
Posts: 3

Re: [SOLVED] No DNS until restart systemd-resolved

cryptearth wrote:

running both NetworkManager and systemd sounds conflicting
I'm no expert and how to config both - but from many topics I read: either run one or the other - but not both - as when NetworkManager is set to systemd it will start it on its own - so systemd-resolved should be disabled to not autostart on its own and should be restarted on its own but only handled by NetworkManager

If I remember correctly, the idea was to get local caching of DNS queries to speed things up. Since both wiki articles https://wiki.archlinux.org/title/Networ … forwarding and https://wiki.archlinux.org/title/System … omatically mentioned each other, I was under the impression that this was the intended use.
But I have probably created an unusual and untested configuration using them together with OpenSnitch smile

Offline

#6 2025-01-20 21:34:44

Awebb
Member
Registered: 2010-05-06
Posts: 6,688

Re: [SOLVED] No DNS until restart systemd-resolved

I've had this exact behavior with systemd-resolved on a number of machines, there was no OpenSnitch involved. I do not remember what I did to fix it, unfortunately.

Many things can go wrong, e.g.:

2.1.1.1 Automatically (https://wiki.archlinux.org/title/Systemd-resolved)

systemd-resolvconf only works when systemd-resolved.service is running. If you are not using systemd-resolved, make sure the systemd-resolvconf package is uninstalled, otherwise it will cause issues with networking software that expect a working /usr/bin/resolvconf binary.

Offline

Pages: 1

Board footer

Powered by FluxBB