DNS issue after latest update

birdibird · 13 February 2025 11:22

Hi all,

Since the last full update I am experiencing problems with DNS resolve

$ ping ping.manjaro.org
ping: ping.manjaro.org: Temporary failure in name resolution

It happens both with kernel 6.12 and 6.13.
To try to solve it I tried with and without openresolv.

my /etc/resolvconf.conf is:

resolv_conf=/etc/resolv.conf
name_servers="9.9.9.9 149.112.112.112"

and /etc/resolv.conf:

nameserver 9.9.9.9
nameserver 149.112.112.112

/etc/systemd/resolved.conf

[Resolve]
DNS=9.9.9.9 149.112.112.112 2620:fe::fe 2620:fe::9

$ inxi -Nxx

Network:
  Device-1: Intel Comet Lake PCH-LP CNVi WiFi driver: iwlwifi v: kernel
    bus-ID: 00:14.3 chip-ID: 8086:02f0
  Device-2: Intel Ethernet I219-LM vendor: Fujitsu Client driver: e1000e
    v: kernel port: N/A bus-ID: 00:1f.6 chip-ID: 8086:0d4e

$ ip route

default via 192.168.1.1 dev wlp0s20f3 proto dhcp src 192.168.1.104 metric 600
192.168.1.0/24 dev wlp0s20f3 proto kernel scope link src 192.168.1.104 metric 600

$ ip addr

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute
       valid_lft forever preferred_lft forever
2: enp0s31f6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether ec:79:49:39:56:af brd ff:ff:ff:ff:ff:ff
    altname enxec79493956af
3: wwp0s20f0u7i12: <BROADCAST,MULTICAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether ba:94:2b:0c:43:4a brd ff:ff:ff:ff:ff:ff
4: wlp0s20f3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 2c:db:07:e7:fe:b9 brd ff:ff:ff:ff:ff:ff
    altname wlx2cdb07e7feb9
    inet 192.168.1.104/24 brd 192.168.1.255 scope global dynamic noprefixroute wlp0s20f3
       valid_lft 85947sec preferred_lft 85947sec
    inet6 fe80::f83d:30f7:4482:2684/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

$ sudo systemctl status systemd-networkd.service

○ systemd-networkd.service - Network Configuration
     Loaded: loaded (/usr/lib/systemd/system/systemd-networkd.service; disabled; preset: enabled)
     Active: inactive (dead)
TriggeredBy: ○ systemd-networkd.socket
       Docs: man:systemd-networkd.service(8)
             man:org.freedesktop.network1(5)
   FD Store: 0 (limit: 512)

$ sudo systemctl status systemd-resolved.service

● systemd-resolved.service - Network Name Resolution
     Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; enabled; preset: enabled)
     Active: active (running) since Thu 2025-02-13 11:43:30 CET; 2min 33s ago
 Invocation: cf32b6525dd04b0aac7d3fadd352971e
       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: 435 (systemd-resolve)
     Status: "Processing requests..."
      Tasks: 1 (limit: 18670)
     Memory: 5.6M (peak: 6.4M)
        CPU: 1.369s
     CGroup: /system.slice/systemd-resolved.service
             └─435 /usr/lib/systemd/systemd-resolved

Feb 13 11:43:30 veertje systemd[1]: Starting Network Name Resolution...
Feb 13 11:43:30 veertje systemd-resolved[435]: Positive Trust Anchors:
Feb 13 11:43:30 veertje systemd-resolved[435]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
Feb 13 11:43:30 veertje systemd-resolved[435]: 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>
Feb 13 11:43:30 veertje systemd-resolved[435]: Using system hostname 'veertje'.
Feb 13 11:43:30 veertje systemd[1]: Started Network Name Resolution.
Feb 13 11:43:44 veertje systemd-resolved[435]: wlp0s20f3: Bus client set search domain list to: home
Feb 13 11:43:44 veertje systemd-resolved[435]: wlp0s20f3: Bus client set default route setting: yes
Feb 13 11:43:44 veertje systemd-resolved[435]: wlp0s20f3: Bus client set DNS server list to: 9.9.9.9, 149.112.112.112

The only solution I found until now is to manually enter in terminal directly after boot:

sudo systemctl restart systemd-resolved.service

And then this changed:

$ sudo systemctl status systemd-resolved.service

systemd-resolved.service - Network Name Resolution
     Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; enabled; preset: enabled)
     Active: active (running) since Thu 2025-02-13 11:54:44 CET; 20s ago
 Invocation: 1c388145d75941bd86d4674975e5bb09
       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: 4338 (systemd-resolve)
     Status: "Processing requests..."
      Tasks: 1 (limit: 18670)
     Memory: 3M (peak: 3.3M)
        CPU: 265ms
     CGroup: /system.slice/systemd-resolved.service
             └─4338 /usr/lib/systemd/systemd-resolved

Feb 13 11:54:43 veertje systemd[1]: Starting Network Name Resolution...
Feb 13 11:54:44 veertje systemd-resolved[4338]: Positive Trust Anchors:
Feb 13 11:54:44 veertje systemd-resolved[4338]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
Feb 13 11:54:44 veertje systemd-resolved[4338]: 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.i>
Feb 13 11:54:44 veertje systemd-resolved[4338]: Using system hostname 'veertje'.
Feb 13 11:54:44 veertje systemd-resolved[4338]: mDNS-IPv4: There appears to be another mDNS responder running, or previously systemd-resolved crashed with some outstanding transfers.
Feb 13 11:54:44 veertje systemd-resolved[4338]: mDNS-IPv6: There appears to be another mDNS responder running, or previously systemd-resolved crashed with some outstanding transfers.
Feb 13 11:54:44 veertje systemd[1]: Started Network Name Resolution.

But I need to do that every time after restart.

Any idea how this happened after an update?
Any solutions?

Thanks!

linux-aarhus · 13 February 2025 11:35

DNS issues has nothing to do with an update - it is merely a coincidence that you face the issue after a restart.

When you have issues with DNS it is your configuration - that is - the configured name server(s) are not responding.

Quite often this can be an issue if you have both ipv4 and ipv6 dns.

Try disabling ipv6 for your system.

birdibird · 13 February 2025 12:04

Thanks for your fast reply.
It is weird, as before the update everything worked fine and after update and restart it didn’t. My network connection has´t changed in those minutes.

Disabling ipv6 didn’t solve it. Same issue exists.

As said above:
sudo systemctl restart systemd-resolved.service
does solve it

strange, isn’t it? any other ideas?

Mirdarthos · 13 February 2025 12:15

Tip

When posting terminal output, copy the output and paste it here, wrapped in three (3) backticks, before AND after the pasted text. Like this:

```
pasted text
```

Or three (3) tilde signs, like this:

~~~
pasted text
~~~

This will just cause it to be rendered like this:

Sed
sollicitudin dolor
eget nisl elit id
condimentum
arcu erat varius
cursus sem quis eros.

Instead of like this:

Sed sollicitudin dolor eget nisl elit id condimentum arcu erat varius cursus sem quis eros.

Alternatively, paste the text you wish to format as terminal output, select all pasted text, and click the </> button on the taskbar. This will indent the whole pasted section with one TAB, causing it to render the same way as described above.

Thereby increasing legibility thus making it easier for those trying to provide assistance.

For more information, please see:

As I’m a moderator on the forum, I have taken the liberty of doing this for you, this time.

Additionally

If your language isn’t English, please prepend any and all terminal commands with LC_ALL=C. For example:

LC_ALL=C bluetoothctl

This will just cause the terminal output to be in English, making it easier to understand and debug.

Note that the above text is partially pre-prepared as a general introduction for new forum Users. Please take the time to to understand how it is done and encourage quality responses.

birdibird · 13 February 2025 12:32

Thanks for the tip @Mirdarthos!
That looks indeed a lot better.

linux-aarhus · 13 February 2025 13:03

Are you using multiple resolvers - perhaps conflicting at startup?

birdibird · 13 February 2025 13:03

I don´t know. How can I check?

linux-aarhus · 13 February 2025 13:06

Manjaro does not use systemd-resolved by default - not that I recall - I could be wrong.

Manjaro uses openresolv by default and NetworkManager

Using systemd-resolved can work with a file based /etc/resolv.conf but works best with a symlink to /run/systemd/resolve/stub-resolv.conf

 $ ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 37  7 aug  2024 /etc/resolv.conf -> /run/systemd/resolve/stub-resolv.conf

This can be controlled manually using /etc/systemd/resolved.conf

heyjo · 13 February 2025 15:49

Check this:
pacman -Qs resolv
pacman -Qo resolvconf

cscs · 13 February 2025 20:18

This was my thought as the comments do not add up.

This should only be effective for openresolve

This is for systemd-resolved

And if using systemd-resolved this should be a symlink with a header like

# This is /run/systemd/resolve/resolv.conf managed by man:systemd-resolved(8).
# Do not edit.
#
# This file might be symlinked as /etc/resolv.conf. If you're looking at
# /etc/resolv.conf and seeing this text, you have followed the symlink.
#
# This is a dynamic resolv.conf file for connecting local clients directly to
# all known uplink DNS servers. This file lists all configured search domains.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

But you are obviously starting systemd-resolved.

This will be somewhat helpful … though we have already established your configs are broken.

PS.

This is definitely not used by default - NetworkManager is - was this also consciously replaced?

PPS.

If you dont want to wait on exchanges here … there is an old post outlining setting up systemd-resolved here:

birdibird · 13 February 2025 21:49

Thanks all for thinking with me.
This is the pacman output:

$ pacman -Qs resolv
local/libmicrodns 0.2.0-2
    Minimal mDNS resolver library
local/openresolv 3.13.2-2
    resolv.conf management framework (resolvconf)

$ pacman -Qo resolvconf
/usr/bin/resolvconf is owned by openresolv 3.13.2-2

No, I have not done anything here. NetworkManager is of course used.

Yes, I started is as a test: as, while I was searching the forum I encountered someone recommending trying sudo systemctl restart systemd-resolved.service, and this worked for me in getting dns resolved back.
I disabled it now again, as indeed I do not want multiple running and prefer to have the default openresolv and networkmanager work again.
What would be the steps for that?

(Or do you recommend me to use systemd-resolved instead and do the steps in the post linked above?)

cscs · 13 February 2025 21:57

I generally do suggest this.

I am not sure it will fix your issues, but I consider it a better choice and it has resolved some oddities around DNS for other users in the past.

birdibird · 13 February 2025 21:58

Well indeed, that was it!
I disabled the systemd-resolved.service and now all works again after reboot.

birdibird · 13 February 2025 21:59

It is still strange how this happened, I don´t know what caused it.
But I am happy it has been resolved.

Thanks all for the support!
This thread can be closed

cscs · 13 February 2025 21:59

Ah, sorry, thought we were already there.
Well, glad it worked out … and now you can investigate systemd-resolved properly at your leisure, if desired.

linux-aarhus · 14 February 2025 11:19

3 posts were split to a new topic: Systemd update changes system to systemd-resolved

birdibird · 15 February 2025 16:13

Ok, this is really weird.
Again after an update and restart resolv didn’t work.

This time I edited by hand /etc/resolv.conf and chmod 444 and chattr +i it.
That works.

I will indeed investigate systemd-resolved more, and maybe switch to that.

system · 18 February 2025 16:14

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.