Wie debugge ich DNS-Fehler?

[kartoffelpü]

Ich konnte weder das Internet noch meinen Router (!) erreichen (= er lädt sich tot). Das NAS hingegen habe ich aber aufrufen können.

Hast du versucht, auf Router und NAS per Namen oder IP zuzugreifen?

 

[Krik]

An der Stelle habe ich auf den Router per IP und auf das NAS per Namen zugegriffen. Der Name des NAS ist lokal in der /etc/hosts auf dem PC hinterlegt.

 

[Snakeeater]

Ich habe mir nicht den ganzen Thread durchgelesen, aber es gibt einen bekannten Bug bei systemd-resolved, falls das genutzt wird. Leider kann ich keinen direkten Fix anbieten, habe ein ähnliches Problem und konnte noch nicht genau feststellen wie es zu lösen ist, da das Problem auch nur sporadisch auftritt.

 

[Krik]

[krik@krix ~]$ ping proton.me
ping: proton.me: Der Name oder der Dienst ist nicht bekannt
[krik@krix ~]$ dig proton.me

; <<>> DiG 9.20.22 <<>> proton.me
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 65304
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;proton.me.                     IN      A

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Mon Apr 20 13:06:57 CEST 2026
;; MSG SIZE  rcvd: 38

Wie kann ich das weiter debuggen? Ich weiß nicht, wo genau der Fehler auftritt.
Aktuell ist als DNS-Server wieder mein AdGuard eingestellt.

 

[Piktogramm]

Das Erste wäre ein Ping auf die Adresse, hinter der der DNS-Server sitzt, also bei dir die 10.0.1.1(?) als Test der Grundlegenden Erreichbarkeit sinnvoll.

Weiter spuckt resolvectl status die Konfiguration aus, die resolved gerade nutzt.

resolvectl status                                                                                                                                                               
Global
           Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
    resolv.conf mode: foreign
  Current DNS Server: 192.168.178.1
         DNS Servers: 192.168.178.1 fdf3:2620:: 2a02:2455::
Fallback DNS Servers: 9.9.9.9#dns.quad9.net 2620:fe::9#dns.quad9.net 1.1.1.1#cloudflare-dns.com 2606:4700:4700::1111#cloudflare-dns.com 8.8.8.8#dns.google 2001:4860:4860::8888#dns.google
          DNS Domain: fritz.box

DNS-Queries aus dem Userspace (also sowas wie dig) bringen nix, die fragen entweder den DNS-Cache von resolved oder implementieren DNS und fragen konfigurierte DNS-Server anstatt auf auf die Router Advertisements zu achten.

Wenn die 10.0.1.1 bei dir erreichbar ist, vom resolved übernommen wurde, dann wäre das Nächste zu schauen was der DNS Server in seine Logs schreibt. Alternativ sich mit Wireshark an des entsprechende Netzwerkinterface hängen und schauen was da über den Ether geht.

 

[Krik]

Das Erste wäre ein Ping auf die Adresse, hinter der der DNS-Server sitzt, also bei dir die 10.0.1.1(?) als Test der Grundlegenden Erreichbarkeit sinnvoll.

Alles klar. Beim nächsten Auftreten des Fehlers teste ich das. Einfach ping 1.0.1.1 reicht? Oder besser ein anderes Tool verwenden?

[krik@krix ~]$ resolvectl status
Global
           Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
    resolv.conf mode: foreign
Fallback DNS Servers: 9.9.9.9#dns.quad9.net 2620:fe::9#dns.quad9.net 1.1.1.1#cloudflare-dns.com 2606:4700:4700::1111#cloudflare-dns.com 8.8.8.8#dns.google
                      2001:4860:4860::8888#dns.google

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

Link 2 (enp9s0)
    Current Scopes: DNS LLMNR/IPv4 mDNS/IPv4
         Protocols: +DefaultRoute +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 10.0.1.1
       DNS Servers: 10.0.1.1
     Default Route: yes

Sieht das so richtig aus?

 

[Piktogramm]

Oder lieber ein anderes Tool verwenden?

ping ist ein guter Anfang minimalen Aufwands. Alles andere macht bei der Anwendung und beim Erklären einfach zu viel Arbeit.

ping 1.0.1.1

Könntest du dich bitte entscheiden, ob du die 10.0.1.1 meinst oder die 1.0.1.1 ?!

[krik@krix ~]$ ip a
[...]
2: enp9s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
    altname enXXXXXXXXXXXX
    inet 10.0.0.1/8 brd 10.255.255.255 scope global dynamic noprefixroute enp9s0
       valid_lft 862930sec preferred_lft 862930sec
3: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc htb state DOWN group default qlen 1000
    link/ether 52:54:00:11:dc:b3 brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
       valid_lft forever preferred_lft forever

Ich prangere an, dass bei dir kein IPv6 konfiguriert ist!

Ergänzung (Gestern um 14:43)

Sieht das so richtig aus?

Die Fritzbox schreit ins Netz, dass die 10.0.1.1 DNS Server im lokalem Netz ist, resolved übernimmt es für den Link, der im Netz der Fritzbox hängt. Alles in Butter soweit.

 

[Krik]

Könntest du dich bitte entscheiden, ob du die 10.0.1.1 meinst oder die 1.0.1.1 ?!

'Tschuldige. Es ist die 10.0.1.1.

Ich prangere an, dass bei dir kein IPv6 konfiguriert ist!

Ich habe es deaktiviert. Ich kann es später ja wieder aktivieren, sobald ich den Grund für den gelegentlichen DNS-Ausfall gefunden habe.

Irgendwie glaube ich schon fast, dass das Mainboard bzw. die On-Board-Netzwerkkarte einen Defekt hat. Ich update zwar immer fleißig das BIOS, aber WOL geht immer noch nicht, obwohl das laut Aussage des Hersteller-Supports permanent aktiv sein sollte. Ist es bei mir aber nicht. Die LEDs leuchten auch nicht, wenn der PC abgeschaltet ist (= also ist Netzwerkkarte auch abgeschaltet).
Vielleicht trügt mich aber auch mein Gefühl. Es ist ja nur ein Gefühl. Mal gucken, was hier noch so rauskommt.

 

[Piktogramm]

Zum WOL kann ich wenig sagen, aber wenn der Netzwerkadapter großartig Probleme hat, sollte das im Log landen.
journalctl -r -p0..4 | grep enp9s0
Also Jorunal aufrufen in umgekehrter Reihenfolge (jüngste zuerst), filtern nach Fehlern kritisch bis runter zu Warnung, grep aufs Interface.

 

[Krik]

Ich finde da keinen Fehler. Die einzige Auffälligkeit ist die gelegentlich fehlende MAC-Adresse des PCs

...
Apr 20 13:08:36 krix kernel: [UFW BLOCK] IN=enp9s0 OUT= MAC=<fritzbox> SRC=10.0.0.254 DST=224.0.0.1 LEN=36 TOS=0x00 PREC=0x00 TTL=1 ID=11294 DF PROTO=2
Apr 20 13:06:41 krix kernel: [UFW BLOCK] IN=enp9s0 OUT= MAC=<fritzbox> SRC=10.0.0.254 DST=224.0.0.252 LEN=51 TOS=0x00 PREC=0x00 TTL=1 ID=61136 PROTO=UDP SPT=5355 DPT=5355 LEN=31
Apr 20 13:06:41 krix kernel: [UFW BLOCK] IN=enp9s0 OUT= MAC= SRC=10.0.0.1 DST=224.0.0.252 LEN=51 TOS=0x00 PREC=0x00 TTL=255 ID=8950 PROTO=UDP SPT=5355 DPT=5355 LEN=31
Apr 20 13:06:41 krix kernel: [UFW BLOCK] IN=enp9s0 OUT= MAC= SRC=10.0.0.1 DST=224.0.0.252 LEN=51 TOS=0x00 PREC=0x00 TTL=255 ID=8752 PROTO=UDP SPT=5355 DPT=5355 LEN=31
Apr 20 13:06:40 krix kernel: [UFW BLOCK] IN=enp9s0 OUT= MAC= SRC=10.0.0.1 DST=224.0.0.252 LEN=51 TOS=0x00 PREC=0x00 TTL=255 ID=8642 PROTO=UDP SPT=5355 DPT=5355 LEN=31
Apr 20 13:06:31 krix kernel: [UFW BLOCK] IN=enp9s0 OUT= MAC=<fritzbox> SRC=10.0.0.254 DST=224.0.0.1 LEN=36 TOS=0x00 PREC=0x00 TTL=1 ID=49686 DF PROTO=2
Apr 20 13:04:26 krix kernel: [UFW BLOCK] IN=enp9s0 OUT= MAC=<fritzbox> SRC=10.0.0.254 DST=224.0.0.1 LEN=36 TOS=0x00 PREC=0x00 TTL=1 ID=30459 DF PROTO=2
...

Ich weiß nicht, warum mein PC keine MAC bei diesen drei Zeilen angibt. Auffällig ist auch, dass der Zeitpunkt ungefähr zum Ausfall des DNS-Services passt. Vielleicht ist das aber auch normales Verhalten, ich weiß es leider nicht.

Die IP-Adressen selber sind unauffällig.
10.0.0.1 - dieser PC
10.0.0.254 - Fritzbox
224.0.0.1 & 224.0.0.252 - Multicast-Adressen

Ich warte dann mal weiter ab, bis die DNS-Auflösung wieder spinnt.
Vielen Dank schon mal bis hier hin, @Piktogramm

 

[Piktogramm]

UDP Broadcast ohne MAC ist legitim.
Past von den Metadaten her ganz gut zu Link-Local Multicast Name Resolution
https://en.wikipedia.org/wiki/Link-Local_Multicast_Name_Resolution

 

[Krik]

Ich habe einen neuen Ausfall erlebt.

→ Meinen DNS (10.0.1.1) konnte ich während dessen erfolgreich vom PC aus anpingen und auch die Weboberfläche erreichen. Dort wurde nicht protokolliert, dass der PC Anfragen machte. Schließen und wieder Öffnen des Browser hat keine Abhilfe gebracht. An dem liegt es also auch nicht.
→ Parallel ist die DNS-Auflösung auf dem Handy bei den gleichen Seiten nicht ausgefallen. Die Anfragen wurden auch in Adguard protokolliert. Das Handy ging ausschließlich über WLAN ins Internet. Das mobile Internet war zu dem Zeitpunkt ausgeschaltet.

Ich schieße daraus, dass der Fehler vollständig auf dem PC liegt.

Ob es am systemd-resolved.service liegt? Beim Ausfall gestern (Post #24) wurden nur diese Zeilen protokolliert:
journalctl -u systemd-resolved

Apr 20 13:06:38 krix systemd-resolved[660]: enp9s0: Bus client set default route setting: no
Apr 20 13:06:38 krix systemd-resolved[660]: enp9s0: Bus client reset DNS server list.
Apr 20 13:06:40 krix systemd-resolved[660]: enp9s0: Bus client set default route setting: yes
Apr 20 13:06:40 krix systemd-resolved[660]: enp9s0: Bus client set DNS server list to: 10.0.1.1

Davor und danach wurde für Stunden kein Eintrag protokolliert.
In dmesg sind nur Daten seit dem letzten Boot zu sehen. Ich muss den nächsten Fehler abwarten und dann schauen, ob etwas aufgezeichnet wird.