Wifi connection drops - DNSSEC validation failed

jones · 2024-08-07 20:03:38

Have been using wpa_supplicant for ages now to connect to any wifi network I am using.
Have been using yt-dlp for ages to download all the video from the webs.

I have been getting drops in my wifi connection for roughly a week now. Sometimes during a yt-dlp download, sometimes not in relation to that at all (I think). Maybe...
The last few hours have been a bit crazy, so I looked into the journal.
There seems to be a pattern related to dbus ... and xconf.service? Rather clueless here, sorry, but you can see what I mean–I think–in the following code:

$ journalctl -b --since="2024-08-07 20:20" --until="2024-08-07 20:50"
Aug 07 20:23:13 ArchLinuxT480s systemd[1]: Starting Daily man-db regeneration...
Aug 07 20:23:26 ArchLinuxT480s systemd[1]: man-db.service: Deactivated successfully.
Aug 07 20:23:26 ArchLinuxT480s systemd[1]: Finished Daily man-db regeneration.
Aug 07 20:23:26 ArchLinuxT480s systemd[1]: man-db.service: Consumed 11.260s CPU time, 171.5M memory peak.
Aug 07 20:44:14 ArchLinuxT480s systemd[1929]: Started dbus-:1.2-org.xfce.Xfconf@4.service.
Aug 07 20:44:14 ArchLinuxT480s xfce4-screensaver-dialog[30441]: pam_systemd_home(xfce4-screensaver:auth): New sd-bus connection (system-bus-pam-systemd-home-30441) opened.
Aug 07 20:44:14 ArchLinuxT480s xfce4-screensaver-dialog[30441]: gkr-pam: unlocked login keyring
Aug 07 20:44:14 ArchLinuxT480s xfce4-screensaver-dialog[30441]: pam_warn(xfce4-screensaver:account): function=[pam_sm_acct_mgmt] flags=0 service=[xfce4-screensaver] terminal=[:0.0] user=[john] ru>
Aug 07 20:45:24 ArchLinuxT480s systemd-resolved[1012]: [?] DNSSEC validation failed for question mediatradecraft.com IN DS: no-signature
Aug 07 20:45:24 ArchLinuxT480s systemd-resolved[1012]: [?] DNSSEC validation failed for question cdn.mediatradecraft.com IN DS: no-signature
Aug 07 20:45:24 ArchLinuxT480s systemd-resolved[1012]: [?] DNSSEC validation failed for question 01.cdn.mediatradecraft.com IN A: no-signature
Aug 07 20:45:24 ArchLinuxT480s systemd-resolved[1012]: [?] DNSSEC validation failed for question googleapis.com IN DS: no-signature
Aug 07 20:45:24 ArchLinuxT480s systemd-resolved[1012]: [?] DNSSEC validation failed for question ajax.googleapis.com IN DS: no-signature
Aug 07 20:45:24 ArchLinuxT480s systemd-resolved[1012]: [?] DNSSEC validation failed for question ajax.googleapis.com IN A: no-signature
Aug 07 20:45:24 ArchLinuxT480s systemd-resolved[1012]: [?] DNSSEC validation failed for question facebook.net IN DS: no-signature
Aug 07 20:45:24 ArchLinuxT480s systemd-resolved[1012]: [?] DNSSEC validation failed for question connect.facebook.net IN A: no-signature
Aug 07 20:45:24 ArchLinuxT480s systemd-resolved[1012]: [?] DNSSEC validation failed for question googleapis.com IN DS: no-signature
Aug 07 20:45:24 ArchLinuxT480s systemd-resolved[1012]: [?] DNSSEC validation failed for question ajax.googleapis.com IN DS: no-signature

and

$ journalctl -b --since="2024-08-07 21:23" --until="2024-08-07 21:30"
Aug 07 21:23:01 ArchLinuxT480s rtkit-daemon[2034]: Supervising 8 threads of 3 processes of 1 users.
Aug 07 21:23:01 ArchLinuxT480s rtkit-daemon[2034]: Supervising 8 threads of 3 processes of 1 users.
Aug 07 21:23:16 ArchLinuxT480s rtkit-daemon[2034]: Supervising 8 threads of 3 processes of 1 users.
Aug 07 21:23:16 ArchLinuxT480s rtkit-daemon[2034]: Supervising 8 threads of 3 processes of 1 users.
Aug 07 21:23:16 ArchLinuxT480s rtkit-daemon[2034]: Supervising 8 threads of 3 processes of 1 users.
Aug 07 21:23:16 ArchLinuxT480s rtkit-daemon[2034]: Supervising 8 threads of 3 processes of 1 users.
Aug 07 21:23:16 ArchLinuxT480s rtkit-daemon[2034]: Successfully made thread 35504 of process 35214 owned by '1000' RT at priority 10.
Aug 07 21:23:16 ArchLinuxT480s rtkit-daemon[2034]: Supervising 9 threads of 4 processes of 1 users.
Aug 07 21:23:17 ArchLinuxT480s systemd[1]: Starting Hostname Service...
Aug 07 21:23:17 ArchLinuxT480s systemd[1]: Started Hostname Service.
Aug 07 21:23:47 ArchLinuxT480s systemd[1]: systemd-hostnamed.service: Deactivated successfully.
Aug 07 21:28:12 ArchLinuxT480s systemd[1929]: Started dbus-:1.2-org.xfce.Xfconf@8.service.
Aug 07 21:28:13 ArchLinuxT480s xfce4-screensaver-dialog[35778]: pam_systemd_home(xfce4-screensaver:auth): New sd-bus connection (system-bus-pam-systemd-home-35778) opened.
Aug 07 21:28:14 ArchLinuxT480s xfce4-screensaver-dialog[35778]: gkr-pam: unlocked login keyring
Aug 07 21:28:14 ArchLinuxT480s xfce4-screensaver-dialog[35778]: pam_warn(xfce4-screensaver:account): function=[pam_sm_acct_mgmt] flags=0 service=[xfce4-screensaver] terminal=[:0.0] user=[john] ru>
Aug 07 21:29:17 ArchLinuxT480s rtkit-daemon[2034]: Supervising 7 threads of 2 processes of 1 users.
Aug 07 21:29:17 ArchLinuxT480s rtkit-daemon[2034]: Supervising 7 threads of 2 processes of 1 users.
Aug 07 21:29:31 ArchLinuxT480s systemd-resolved[1012]: [?] DNSSEC validation failed for question mediatradecraft.com IN DS: no-signature
Aug 07 21:29:31 ArchLinuxT480s systemd-resolved[1012]: [?] DNSSEC validation failed for question cdn.mediatradecraft.com IN DS: no-signature
Aug 07 21:29:31 ArchLinuxT480s systemd-resolved[1012]: [?] DNSSEC validation failed for question 01.cdn.mediatradecraft.com IN A: no-signature
Aug 07 21:29:32 ArchLinuxT480s systemd-resolved[1012]: [?] DNSSEC validation failed for question amazon-adsystem.com IN DS: no-signature
Aug 07 21:29:32 ArchLinuxT480s systemd-resolved[1012]: [?] DNSSEC validation failed for question c.amazon-adsystem.com IN A: no-signature
Aug 07 21:29:32 ArchLinuxT480s systemd-resolved[1012]: [?] DNSSEC validation failed for question google.com IN DS: no-signature
Aug 07 21:29:32 ArchLinuxT480s systemd-resolved[1012]: [?] DNSSEC validation failed for question www.google.com IN DS: no-signature
Aug 07 21:29:32 ArchLinuxT480s systemd-resolved[1012]: [?] DNSSEC validation failed for question www.google.com IN A: no-signature

Basic info regarding resolv.conf:

$ cat /etc/resolv.conf
# Generated by dhcpcd from wlp61s0.dhcp
# /etc/resolv.conf.head can replace this line
domain speedport.ip
nameserver 192.168.2.1
# /etc/resolv.conf.tail can replace this line

What can I do?

seth · 2024-08-07 20:26:39

Seeing resolved and dhcpcd and dhcpcd controlled resolv.conf and from the symptoms, please post the output of

find /etc/systemd -type l -exec test -f {} \; -print | awk -F'/' '{ printf ("%-40s | %s\n", $(NF-0), $(NF-1)) }' | sort -f

Have you deliberately configured https://wiki.archlinux.org/title/System … ved#DNSSEC ?

Edit: on top of that, the speedport has a DNS cache, doesn't?
Also that's a magenta ISP in central europe? The telekom is OTR for redirecting unresolvable domains to internal IPs/advertisement…
Have you tried changing the DNS to google/cloudflare/quad9 etc?

Last edited by seth (2024-08-07 20:30:06)

jones · 2024-08-07 21:02:38

The output of that monster of a command (did you type that out or did you c&p it ... ):

$ find /etc/systemd -type l -exec test -f {} \; -print | awk -F'/' '{ printf ("%-40s | %s\n", $(NF-0), $(NF-1)) }' | sort -f
cups.path                                | multi-user.target.wants
cups.service                             | printer.target.wants
cups.socket                              | sockets.target.wants
dbus-org.freedesktop.ratbag1.service     | system
dbus-org.freedesktop.resolve1.service    | system
dhcpcd.service                           | multi-user.target.wants
display-manager.service                  | system
fstrim.timer                             | timers.target.wants
gcr-ssh-agent.socket                     | sockets.target.wants
getty@tty1.service                       | getty.target.wants
gnome-keyring-daemon.socket              | sockets.target.wants
p11-kit-server.socket                    | sockets.target.wants
pipewire.socket                          | sockets.target.wants
pulseaudio.socket                        | sockets.target.wants
reflector.service                        | multi-user.target.wants
reflector.timer                          | timers.target.wants
remote-fs.target                         | multi-user.target.wants
systemd-resolved.service                 | multi-user.target.wants
tlp.service                              | multi-user.target.wants
xdg-user-dirs-update.service             | default.target.wants

Have you deliberately configured https://wiki.archlinux.org/title/System … ved#DNSSEC ?

I think so. Must have been because of another problem I had 3 years ago (see post 9).
It is set to allow-downgrade:

$ cat /etc/systemd/resolved.conf
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.
#
# Entries in this file show the compile time defaults.
# You can change settings by editing this file.
# Defaults can be restored by simply deleting this file.
#
# See resolved.conf(5) for details

[Resolve]
#DNS=
#FallbackDNS=8.8.8.8 1.1.1.1 9.9.9.10 2606:4700:4700::1111 2620:fe::10 2001:4860:4860::8888
#Domains=
#LLMNR=yes
#MulticastDNS=yes
DNSSEC=allow-downgrade
#DNSSEC=no
#DNSSEC=yes
#DNSOverTLS=no
#Cache=yes
#DNSStubListener=yes
#ReadEtcHosts=yes

on top of that, the speedport has a DNS cache, doesn't?
Also that's a magenta ISP in central europe? The telekom is OTR for redirecting unresolvable domains to internal IPs/advertisement…
Have you tried changing the DNS to google/cloudflare/quad9 etc?

No clue about the DNS cache. I have not yet worked with it or found it in any way.
Yes, the telekom is my ISP.
I have not changed the DNS to anyone of google/cloudflare/quad9 since I switched to telekom.

Last edited by jones (2024-08-07 21:14:35)

seth · 2024-08-07 21:26:50

I've a bunch of textblocks

It's not per se wrong to use dhcpcd and resolved together (in this case the latter as a consumer) and you don't seem to have a competitive service enabled.
I don't even think that's the problem of any connection losses or that the DNSSEC messages indicate anything.

drill -D badsig.go.dnscheck.tools # no IP resolved
drill -D go.dnscheck.tools # A and RRSIG
drill -D google.com # A record only

When the network drops out, download this file (into /dev/null)

wget -nv --show-progress -O /dev/null "http://speedtest.frankfurt.linode.com/1GB-frankfurt.bin"

You could still disable resolved and see whether that changed anything.

Any chance this is actually not a LAN/wifi issue but a WAN/ISP one? Do other hosts in the same LAN perform fine? Any chance to use a wired connection?

When it comes to "youtube videos" specifically

pipewire.socket                          | sockets.target.wants
pulseaudio.socket                        | sockets.target.wants

Nope. => https://archlinux.org/packages/extra/x8 … ire-pulse/

If you actually have spurious network drop-outs, I'd first look at (disable)

tlp.service                              | multi-user.target.wants

There's nothing suspicious in the posted journal segments at all.

jones · 2024-08-16 18:19:44

First, regarding tlp:

$ cat /etc/tlp.conf | grep WIFI_PWR
WIFI_PWR_ON_AC=off
#WIFI_PWR_ON_BAT=on
WIFI_PWR_ON_BAT=off

Then regarding the 3 commands:

$ drill -D badsig.go.dnscheck.tools # no IP resolved
;; ->>HEADER<<- opcode: QUERY, rcode: SERVFAIL, id: 33604
;; flags: qr rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 
;; QUESTION SECTION:
;; badsig.go.dnscheck.tools.	IN	A

;; ANSWER SECTION:

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 328 msec
;; EDNS: version 0; flags: do ; udp: 512
;; SERVER: 192.168.2.1
;; WHEN: Fri Aug 16 20:08:16 2024
;; MSG SIZE  rcvd: 53
$ drill -D go.dnscheck.tools # A and RRSIG
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 2440
;; flags: qr rd ra ad ; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 
;; QUESTION SECTION:
;; go.dnscheck.tools.	IN	A

;; ANSWER SECTION:
go.dnscheck.tools.	1	IN	A	116.203.95.251
go.dnscheck.tools.	1	IN	RRSIG	A 13 3 1 20240816190844 20240816170843 55908 go.dnscheck.tools. AQ1QvteNxmWk6Ir+KZpQMyy4Cq6a61i7lqyC4ZHoRokFU4Tys47BndhOVI8yLWJPkG2NtSer1g3typYnDjZCsg==

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 163 msec
;; EDNS: version 0; flags: do ; udp: 512
;; SERVER: 192.168.2.1
;; WHEN: Fri Aug 16 20:08:45 2024
;; MSG SIZE  rcvd: 175
$ drill -D google.com # A record only
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 60836
;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 
;; QUESTION SECTION:
;; google.com.	IN	A

;; ANSWER SECTION:
google.com.	45	IN	A	172.217.18.14

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 5 msec
;; EDNS: version 0; flags: do ; udp: 512
;; SERVER: 192.168.2.1
;; WHEN: Fri Aug 16 20:09:02 2024
;; MSG SIZE  rcvd: 55

And:

$ wget -nv --show-progress -O /dev/null "http://speedtest.frankfurt.linode.com/1GB-frankfurt.bin"
wget: Host-Adresse »speedtest.frankfurt.linode.com« kann nicht aufgelöst werden

which translates to
host address speedtest....com cannot be resolved

Observations:
I can visit translate.google.com, but cannot really use it.
I can visit https://www.youtube.com/watch?v=DYpq7azYwng but the video does not load. And in the auto-suggestions below the video on the right, it shows video titles, but black thumbnails.
Edit: And apparently I can make a post here. Weird.

What is going on???

Last edited by jones (2024-08-16 18:20:25)

jones · 2024-08-16 18:26:49

Hm, after a few minutes, it is all going ok again... please don't trace my SERVER ip, thanks.

seth · 2024-08-16 18:29:43

All the drills have the expected results, response coming from 192.168.2.1 (your speedport router) but then you can't resolve speedtest.frankfurt.linode.com
Next time this happens check

drill speedtest.frankfurt.linode.com
drill @8.8.8.8 speedtest.frankfurt.linode.com
drill -D speedtest.frankfurt.linode.com
ping -C3 192.168.2.1

jones · 2024-08-16 18:51:50

Ok I will.

(Kind of sad that my irony was not picked up)

seth · 2024-08-16 19:50:39

Irony doesn't work on the internet, but in case you're worried, you didn't reveal any publically routable IP.
I'm btw. pretty sure it's your ISP, the question is whether its the connection or their underdimensioned DNS servers.
In the latter case (asking 8.8.8.8/google works but the surrounding drills asking 192.168.2.1 don't) you could just configure an alternative DNS as default.

jones · 2024-08-25 18:38:44

And like clockwork, a week later I cannot reach https://de.wikipedia.org or https://downforeveryoneorjustme.com/ or https://wiki.archlinux.org
So:

$ drill speedtest.frankfurt.linode.com
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 47966
;; flags: qr rd ra ; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 
;; QUESTION SECTION:
;; speedtest.frankfurt.linode.com.	IN	A

;; ANSWER SECTION:
speedtest.frankfurt.linode.com.	1638	IN	CNAME	speedtest-1.fra1.de.prod.linode.com.
speedtest-1.fra1.de.prod.linode.com.	1638	IN	A	139.162.130.8

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 34 msec
;; SERVER: 192.168.2.1
;; WHEN: Sun Aug 25 20:35:17 2024
;; MSG SIZE  rcvd: 103

and

$ drill @8.8.8.8 speedtest.frankfurt.linode.com
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 20687
;; flags: qr rd ra ; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 
;; QUESTION SECTION:
;; speedtest.frankfurt.linode.com.	IN	A

;; ANSWER SECTION:
speedtest.frankfurt.linode.com.	765	IN	CNAME	speedtest-1.fra1.de.prod.linode.com.
speedtest-1.fra1.de.prod.linode.com.	921	IN	A	139.162.130.8

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 9 msec
;; SERVER: 8.8.8.8
;; WHEN: Sun Aug 25 20:35:21 2024
;; MSG SIZE  rcvd: 103

and

$ drill -D speedtest.frankfurt.linode.com
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 59011
;; flags: qr rd ra ; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 
;; QUESTION SECTION:
;; speedtest.frankfurt.linode.com.	IN	A

;; ANSWER SECTION:
speedtest.frankfurt.linode.com.	1628	IN	CNAME	speedtest-1.fra1.de.prod.linode.com.
speedtest-1.fra1.de.prod.linode.com.	1628	IN	A	139.162.130.8

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 4 msec
;; EDNS: version 0; flags: do ; udp: 512
;; SERVER: 192.168.2.1
;; WHEN: Sun Aug 25 20:35:27 2024
;; MSG SIZE  rcvd: 114

and

 $ ping -c 3 192.168.2.1
PING 192.168.2.1 (192.168.2.1) 56(84) Bytes an Daten.
64 Bytes von 192.168.2.1: icmp_seq=1 ttl=64 Zeit=1.31 ms
64 Bytes von 192.168.2.1: icmp_seq=2 ttl=64 Zeit=1.88 ms
64 Bytes von 192.168.2.1: icmp_seq=3 ttl=64 Zeit=2.29 ms

--- 192.168.2.1 ping-Statistik ---
3 Pakete übertragen, 3 empfangen, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 1.306/1.827/2.292/0.404 ms

Pretty sure you mean ping -c 3 right? Because your variant throws an error.

Last edited by jones (2024-08-25 18:39:49)

seth · 2024-08-25 19:17:44

Pretty sure you mean ping -c 3 right?

Yes, sorry - but there's absolutely no issue w/ resolving that host (incl from the LAN DNS), was speedtest.frankfurt.linode.com affected as well? Or was the problem already gone at the time?

It's actually a 9 day interval (7/16/25) - does your router reboot at that frequency or something like that?

jones · 2024-08-25 19:27:47

After performing the commands in my latest post and then making that post from my laptop, I am now unable to refresh any site in a Firefox or visit any address in Chromium.

I am now logged in via my phone (on my normal wifi network) because... drum roll .. my Thunderbird on my laptop showed me that I got a new mail, which was a notification about your post. (???)

I swear I am not making this up.

Regarding the automatic reboot by my router (Telekom's speedport), I do not believe that happens. All the lights are green (= ok) and I kept browsing on my phone.

Regarding pinging speedtest.frankfurt.lin...., I did not try that.

Last edited by jones (2024-08-25 19:29:58)

seth · 2024-08-25 19:34:53

Can you still reach https://193.99.144.80/ (heise.de) or https://192.168.2.1/ (your router)?
Have you tried to restart the browser?
Do you use https://wiki.archlinux.org/title/Firefox/Privacy#Disable/enforce_'Trusted_Recursive_Resolver' or generally DNS over http or anything special in your browser?
Can you "curl -Lv de.wikipedia.org > /dev/null" (the output is transaction data, the actual page goes into /dev/null)

jones · 2024-08-25 19:47:08

Aaaagh. Just fyi, seems like my laptop, wpa_supplicant and/or router, the magical stars up in the sky or whatever are nice to each other again since 30 seconds or so. So I will answer the rest as if it was 35 seconds ago when I ran all the commands included below.

seth wrote:

Can you still reach https://193.99.144.80/ (heise.de) or https://192.168.2.1/ (your router)?

Well I was able to ping them with ping -c 3 ...
But not by visiting the sites in either Chromium or FF.

Have you tried to restart the browser?

Yes, did not change anything.

Do you use https://wiki.archlinux.org/title/Firefox/Privacy#Disable/enforce_'Trusted_Recursive_Resolver'

or generally DNS over http or anything special in your browser?

Well I had set "network.dns.disableIPv6" to _true_ but it is now set to default (=false).
That was it.

Can you "curl -Lv de.wikipedia.org > /dev/null" (the output is transaction data, the actual page goes into /dev/null)

No, see:

$ curl -Lv de.wikipedia.org > /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* Could not resolve host: de.wikipedia.org
* shutting down connection #0
curl: (6) Could not resolve host: de.wikipedia.org

Last edited by jones (2024-08-25 19:48:38)

jones · 2024-08-25 19:47:47

Thank you very much for your patience and effort, Seth.

seth · 2024-08-25 19:55:00

resolvectl status # are you using resolved and how?
resolvectl query de.wikipedia.org # does this fail - next week ;)
drill de.wikipedia.org # but this succeed?

jones · 2024-08-25 20:42:50

C&p-ed the commands, will do run them next time (:()

jones · 2024-09-02 21:46:01

Well, here we go again. Basically 3 mins before I intend to power off my PC for today, the usual symptons happen.

$ resolvectl status
Global
           Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=allow-downgrade/supported
    resolv.conf mode: stub
  Current DNS Server: 9.9.9.9#dns.quad9.net
Fallback DNS Servers: 1.1.1.1#cloudflare-dns.com 9.9.9.9#dns.quad9.net 8.8.8.8#dns.google 2606:4700:4700::1111#cloudflare-dns.com
                      2620:fe::9#dns.quad9.net 2001:4860:4860::8888#dns.google

Link 2 (enp0s31f6)
    Current Scopes: none
         Protocols: -DefaultRoute +LLMNR +mDNS -DNSOverTLS DNSSEC=allow-downgrade/supported

Link 3 (wlp61s0)
    Current Scopes: LLMNR/IPv4 mDNS/IPv4
         Protocols: -DefaultRoute +LLMNR +mDNS -DNSOverTLS DNSSEC=allow-downgrade/supported

Link 4 (enp9s0u1u4u4u3)
    Current Scopes: none
         Protocols: -DefaultRoute +LLMNR +mDNS -DNSOverTLS DNSSEC=allow-downgrade/supported

and

$ resolvectl query de.wikipedia.org
de.wikipedia.org: resolve call failed: DNSSEC validation failed: no-signature

and

$ drill de.wikipedia.org
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 48032
;; flags: qr rd ra ; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 
;; QUESTION SECTION:
;; de.wikipedia.org.	IN	A

;; ANSWER SECTION:
de.wikipedia.org.	38364	IN	CNAME	dyna.wikimedia.org.
dyna.wikimedia.org.	134	IN	A	185.15.59.224

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 5 msec
;; SERVER: 192.168.2.1
;; WHEN: Mon Sep  2 23:44:35 2024
;; MSG SIZE  rcvd: 79

seth · 2024-09-02 21:54:47

Drill still works, querying your gateway for the IP via DNS, but resolvectl (most likely the preferred resolver unless your moved dns up in your nsswitch.conf) has fallen over to quad9 and that somehow doesn't respond.
If the situation is ongoing, try

ping -c3 9.9.9.9
ping -c3 185.15.59.224
drill @9.9.9.9 de.wikipedia.org

Do you somehow block 9.9.9.9?

Edit:
https://wiki.archlinux.org/title/System … ved#DNSSEC - see the warning
https://wiki.archlinux.org/title/System … d#Fallback
There's btw. no reason to use resolved if you are (I assume) behind a caching LAN DNS

The frequency seems to hold, this isn't somehow accidental. Something™ happens every ~9 days either on the system or your network.
Are there any resolved/NM related messages in the system journal preceeding the incident?

Last edited by seth (2024-09-02 22:01:33)

jones · 2024-09-08 01:15:19

That ominous and famous pattern of a period of 9 days just broke.

Do you somehow block 9.9.9.9?

Hm, I am 99% sure I did not.

03:11 john@ArchLinuxT480s [~] $ ping -c 3 google.de
PING google.de (142.250.186.35) 56(84) Bytes an Daten.
64 Bytes von 142.250.186.35: icmp_seq=1 ttl=118 Zeit=8.46 ms
64 Bytes von 142.250.186.35: icmp_seq=2 ttl=118 Zeit=10.5 ms
64 Bytes von 142.250.186.35: icmp_seq=3 ttl=118 Zeit=10.7 ms

--- google.de ping-Statistik ---
3 Pakete übertragen, 3 empfangen, 0% packet loss, time 2004ms
rtt min/avg/max/mdev = 8.464/9.904/10.737/1.022 ms

and

03:11 john@ArchLinuxT480s [~] $ ping -c3 9.9.9.9
PING 9.9.9.9 (9.9.9.9) 56(84) Bytes an Daten.
64 Bytes von 9.9.9.9: icmp_seq=1 ttl=60 Zeit=7.08 ms
64 Bytes von 9.9.9.9: icmp_seq=2 ttl=60 Zeit=8.07 ms
64 Bytes von 9.9.9.9: icmp_seq=3 ttl=60 Zeit=7.43 ms

--- 9.9.9.9 ping-Statistik ---
3 Pakete übertragen, 3 empfangen, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 7.080/7.524/8.068/0.409 ms
03:12 john@ArchLinuxT480s [~] $ ping -c3 185.15.59.224
PING 185.15.59.224 (185.15.59.224) 56(84) Bytes an Daten.
64 Bytes von 185.15.59.224: icmp_seq=1 ttl=59 Zeit=11.3 ms
64 Bytes von 185.15.59.224: icmp_seq=2 ttl=59 Zeit=10.9 ms
64 Bytes von 185.15.59.224: icmp_seq=3 ttl=59 Zeit=11.5 ms

--- 185.15.59.224 ping-Statistik ---
3 Pakete übertragen, 3 empfangen, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 10.888/11.231/11.517/0.260 ms

and

03:12 john@ArchLinuxT480s [~] $ drill @9.9.9.9 de.wikipedia.org
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 3488
;; flags: qr rd ra ; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 
;; QUESTION SECTION:
;; de.wikipedia.org.	IN	A

;; ANSWER SECTION:
de.wikipedia.org.	15268	IN	CNAME	dyna.wikimedia.org.
dyna.wikimedia.org.	219	IN	A	185.15.59.224

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 8 msec
;; SERVER: 9.9.9.9
;; WHEN: Sun Sep  8 03:12:34 2024
;; MSG SIZE  rcvd: 79

seth wrote:

Are there any resolved/NM related messages in the system journal preceeding the incident?

No.

mithrial · 2024-09-08 06:07:53

It's weird that resolvectl shows 9.9.9.9 as current DNS. It should not, right? It should show the router's IP. Are you sure you don't have a drop-in configuration?
Is /etc/resolv.conf the correct symlink to the stub resolver?

How are you managing the network? I don't see NetworkManager or systemd-networkd.

As a workaround, at least in Firefox, you could enable DoH but that's not a solution.

seth · 2024-09-08 06:30:36

(We'd expect the problem to re-appear for the 10th to 12th September.)
There's no network error in any of the outputs in #20.
But I guess "resolvectl query de.wikipedia.org" still fails and (even if it has recovered) you're again on a DNS other than your gateway according to "resolvectl status"?

@mithrial, Quad9 is the second fallback DNS

I suspect what happens is that the router temporarily fails, resolved falls over to one of the fallback servers and that that causes "DNSSEC validation failed: no-signature" in libresolv (for some reason, possibly because the ISP router acts like a MitM)
https://wiki.archlinux.org/title/System … ved#DNSSEC

Edit: or beause of a bug in systemd, we've not seen a bogus DNSSEC from any drill.

Last edited by seth (2024-09-08 06:36:21)

jones · 2024-09-08 16:10:32

And here I am again.
I ran the commands a few hours ago, when I had the problem again.
As usual, it happened during normal browsing (IIRC I edited a sheet in google drive). My laptop lost connection around 14:45 or so while my smartphone just continued to work super fine.
But I only noticed when I tried to browse to tagesschau.de and then youtube.com.

And I was able to re-fresh this very page once but after writing up the first draft of this post (which took roughly 2 mins), I couldn't submit anymore. (why that was, I am clueless)

But I guess "resolvectl query de.wikipedia.org" still fails and (even if it has recovered) you're again on a DNS other than your gateway according to "resolvectl status"?

Yes.
I was a bit out & about doing sports in the meantime but kept the output in geany so here it follows:

15:01 john@ArchLinuxT480s [~] $ resolvectl query de.wikipedia.org
de.wikipedia.org: resolve call failed: DNSSEC validation failed: no-signature

and

15:01 john@ArchLinuxT480s [~] $ drill de.wikipedia.org 
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 45712
;; flags: qr rd ra ; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 
;; QUESTION SECTION:
;; de.wikipedia.org.	IN	A

;; ANSWER SECTION:
de.wikipedia.org.	20059	IN	CNAME	dyna.wikimedia.org.
dyna.wikimedia.org.	201	IN	A	185.15.59.224

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 2 msec
;; SERVER: 192.168.2.1
;; WHEN: Sun Sep  8 15:01:48 2024
;; MSG SIZE  rcvd: 82

and

15:01 john@ArchLinuxT480s [~] $ ping -c3 9.9.9.9
PING 9.9.9.9 (9.9.9.9) 56(84) Bytes an Daten.
64 Bytes von 9.9.9.9: icmp_seq=1 ttl=60 Zeit=9.26 ms
64 Bytes von 9.9.9.9: icmp_seq=2 ttl=60 Zeit=9.52 ms
64 Bytes von 9.9.9.9: icmp_seq=3 ttl=60 Zeit=9.82 ms

--- 9.9.9.9 ping-Statistik ---
3 Pakete übertragen, 3 empfangen, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 9.255/9.533/9.823/0.232 ms

and

15:01 john@ArchLinuxT480s [~] $ resolvectl status
Global
           Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=allow-downgrade/supported
    resolv.conf mode: stub
  Current DNS Server: 9.9.9.9#dns.quad9.net
Fallback DNS Servers: 1.1.1.1#cloudflare-dns.com 9.9.9.9#dns.quad9.net 8.8.8.8#dns.google 2606:4700:4700::1111#cloudflare-dns.com 2620:fe::9#dns.quad9.net
                      2001:4860:4860::8888#dns.google

Link 2 (enp0s31f6)
    Current Scopes: none
         Protocols: -DefaultRoute +LLMNR +mDNS -DNSOverTLS DNSSEC=allow-downgrade/supported

Link 3 (wlp61s0)
    Current Scopes: LLMNR/IPv4 mDNS/IPv4
         Protocols: -DefaultRoute +LLMNR +mDNS -DNSOverTLS DNSSEC=allow-downgrade/supported

Link 4 (enp9s0u1u4u4u3)
    Current Scopes: none
         Protocols: -DefaultRoute +LLMNR +mDNS -DNSOverTLS DNSSEC=allow-downgrade/supported

Last edited by jones (2024-09-08 16:11:28)

seth · 2024-09-08 19:55:46

I suspect what happens is that the router temporarily fails, resolved falls over to one of the fallback servers and that that causes "DNSSEC validation failed: no-signature" in libresolv

Either prevent resolved from falling fack to other DNS servers, disable DNSSEC (as the wiki points out: it's not properly implemented in resovled) or just don't use resolved
https://wiki.archlinux.org/title/System … d#Fallback

jones · 2024-09-08 21:51:00

seth wrote:

Either prevent resolved from falling fack to other DNS servers,

Ok, I did that.

$ sudo mkdir /etc/systemd/resolved.conf.d/
$ sudo touch /etc/systemd/resolved.conf.d/fallback_dns.conf
$ sudoedit /etc/systemd/resolved.conf.d/fallback_dns.conf
$ cat /etc/systemd/resolved.conf.d/fallback_dns.conf
[Resolve]
FallbackDNS=

Hope it helps. Wish me luck.

disable DNSSEC (as the wiki points out: it's not properly implemented in resovled) or

Regarding the experimental implementation of DNSSEC in systemd-resolved, I would argue that this part on the wiki is outdated. It could be updated, however I am not 100 % with what exactly. As the linked discussion on the github issue shows there has been some back and forth (even with personnel consequences).
The issue was fixed: https://github.com/systemd/systemd/issu … 1868352485
Then the second last comment shows that commits have been made: https://github.com/systemd/systemd/issu … 1868497102

Thank you very much for your time, seth. (x100)

mithrial wrote:

How are you managing the network? I don't see NetworkManager or systemd-networkd.

Sorry for the belated reply. I use wpa_supplicant.

Last edited by jones (2024-09-08 21:51:44)

Arch Linux

#1 2024-08-07 20:03:38

Wifi connection drops - DNSSEC validation failed

#2 2024-08-07 20:26:39

Re: Wifi connection drops - DNSSEC validation failed

#3 2024-08-07 21:02:38

Re: Wifi connection drops - DNSSEC validation failed

#4 2024-08-07 21:26:50

Re: Wifi connection drops - DNSSEC validation failed

#5 2024-08-16 18:19:44

Re: Wifi connection drops - DNSSEC validation failed

#6 2024-08-16 18:26:49

Re: Wifi connection drops - DNSSEC validation failed

#7 2024-08-16 18:29:43

Re: Wifi connection drops - DNSSEC validation failed

#8 2024-08-16 18:51:50

Re: Wifi connection drops - DNSSEC validation failed

#9 2024-08-16 19:50:39

Re: Wifi connection drops - DNSSEC validation failed

#10 2024-08-25 18:38:44

Re: Wifi connection drops - DNSSEC validation failed

#11 2024-08-25 19:17:44

Re: Wifi connection drops - DNSSEC validation failed

#12 2024-08-25 19:27:47

Re: Wifi connection drops - DNSSEC validation failed

#13 2024-08-25 19:34:53

Re: Wifi connection drops - DNSSEC validation failed

#14 2024-08-25 19:47:08

Re: Wifi connection drops - DNSSEC validation failed

#15 2024-08-25 19:47:47

Re: Wifi connection drops - DNSSEC validation failed

#16 2024-08-25 19:55:00

Re: Wifi connection drops - DNSSEC validation failed

#17 2024-08-25 20:42:50

Re: Wifi connection drops - DNSSEC validation failed

#18 2024-09-02 21:46:01

Re: Wifi connection drops - DNSSEC validation failed

#19 2024-09-02 21:54:47

Re: Wifi connection drops - DNSSEC validation failed

#20 2024-09-08 01:15:19

Re: Wifi connection drops - DNSSEC validation failed

#21 2024-09-08 06:07:53

Re: Wifi connection drops - DNSSEC validation failed

#22 2024-09-08 06:30:36

Re: Wifi connection drops - DNSSEC validation failed

#23 2024-09-08 16:10:32

Re: Wifi connection drops - DNSSEC validation failed

#24 2024-09-08 19:55:46

Re: Wifi connection drops - DNSSEC validation failed

#25 2024-09-08 21:51:00

Re: Wifi connection drops - DNSSEC validation failed

Board footer