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 (20. April 2026)

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.

 

[dideldei]

Der Resolved macht das Problem erstmal nur sichtbar aber während des Fehlers blieb ja 10.0.1.1 erreichbar aber die Anfrage von PC an Adguard kam nicht an. Wenn du noch nächstes mal ein Ausfall hast, teste mal

dig @127.0.0.53 computerbase.de
dig @10.0.1.1 computerbase.de

Wenn 127 fehlschlägt, liegs am Resolved Pfad, wenn 10 fehlschlägt, liegt das Problem woanders (dns-server, routing etc).

 

[Krik]

Der Ausfall dauerte nur Sekunden. Ich bin mir daher nicht sicher, ob der zweite Befehl einfach nur zu spät kam oder ob das der echte Zustand beim Ausfall war.

127 ist fehlgeschlagen, 10 funktionierte.

[krik@krix ~]$ dig @127.0.0.53 computerbase.de

; <<>> DiG 9.20.22 <<>> @127.0.0.53 computerbase.de
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 10926
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

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

;; Query time: 12 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Tue Apr 21 23:36:50 CEST 2026
;; MSG SIZE  rcvd: 44

[krik@krix ~]$ dig @10.0.1.1 computerbase.de

; <<>> DiG 9.20.22 <<>> @10.0.1.1 computerbase.de
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53458
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;computerbase.de.               IN      A

;; ANSWER SECTION:
computerbase.de.        3591    IN      A       212.83.33.137

;; Query time: 11 msec
;; SERVER: 10.0.1.1#53(10.0.1.1) (UDP)
;; WHEN: Tue Apr 21 23:36:59 CEST 2026
;; MSG SIZE  rcvd: 60

---

Nachtrag:
Ich nehme an, die config files werden nun wichtig:

/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. Local configuration
# should be created by either modifying this file (or a copy of it placed in
# /etc/ if the original file is shipped in /usr/), or by creating "drop-ins" in
# the /etc/systemd/resolved.conf.d/ directory. The latter is generally
# recommended. Defaults can be restored by simply deleting the main
# configuration file and all drop-ins located in /etc/.
#
# Use 'systemd-analyze cat-config systemd/resolved.conf' to display the full config.
#
# See resolved.conf(5) for details.

[Resolve]
# Some examples of DNS servers which may be used for DNS= and FallbackDNS=:
# Cloudflare: 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
# Google:     8.8.8.8#dns.google 8.8.4.4#dns.google 2001:4860:4860::8888#dns.google 2001:4860:4860::8844#dns.google
# Quad9:      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
#
# Using DNS= configures global DNS servers and does not suppress link-specific
# configuration. Parallel requests will be sent to per-link DNS servers
# configured automatically by systemd-networkd.service(8), NetworkManager(8), or
# similar management services, or configured manually via resolvectl(1). See
# resolved.conf(5) and systemd-resolved(8) for more details.
#DNS=
#FallbackDNS=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
#Domains=
#DNSSEC=no
#DNSOverTLS=no
#MulticastDNS=yes
#LLMNR=yes
#Cache=yes
#CacheFromLocalhost=no
#DNSStubListener=yes
#DNSStubListenerExtra=
#ReadEtcHosts=yes
#ResolveUnicastSingleLabel=no
#StaleRetentionSec=0
#RefuseRecordTypes=

Ein /etc/systemd/resolved.conf.d/-Verzeichnis existiert nicht.
systemd-analyze cat-config systemd/resolved.conf gibt den Inhalt der oben gezeigten config file zurück.

/etc/resolv.conf

# Generated by NetworkManager
nameserver 127.0.0.53
options edns0 trust-ad

/run/systemd/resolve/stub-resolv.conf

# This is /run/systemd/resolve/stub-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 to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# 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.

nameserver 127.0.0.53
options edns0 trust-ad
search .

/etc/NetworkManager/system-connections/LAN-Verbindung.nmconnection - Meine aktive LAN-Konfiguration

[connection]
id=LAN-Verbindung
uuid=70528303-1850-43de-9804-42f458c79eee
type=ethernet
metered=2

[ethernet]
auto-negotiate=true
mac-address=<snip>

[ipv4]
dns=10.0.1.1;
ignore-auto-dns=true
may-fail=false
method=auto

[ipv6]
addr-gen-mode=stable-privacy
method=disabled

[proxy]

Vielleicht auch interessant:

[krik@krix ~]$ sudo resolvectl statistics
[sudo] Passwort für krik: 
Transactions                                     
                       Current Transactions:    0
                         Total Transactions: 1839
                                                 
Cache                                            
                         Current Cache Size:   31
                                 Cache Hits:  984
                               Cache Misses:  912
                                                 
Failure Transactions                             
                             Total Timeouts:   46
         Total Timeouts (Stale Data Served):    0
                    Total Failure Responses:   32
Total Failure Responses (Stale Data Served):    0
                                                 
DNSSEC Verdicts                                  
                                     Secure:    0
                                   Insecure:    0
                                      Bogus:    0
                              Indeterminate:    0

Ich weiß nicht, welchen Zeitraum diese Statistik abdeckt.

 

[dideldei]

Für die Leerung des caches und gespeicherten Features.

sudo resolvectl flush-caches
sudo resolvectl reset-server-features

zumindest ist das jetzt einzugrenzen, dass es nicht Adguard ist, sondern lokal am Resolver.

Zum Zeitpunkt, ja das stimmt aber die Spur wird sichtbarer.

 

[Krik]

Ok, ich hab den Cache geleert.

Hat jemand eine Idee, wonach ich jetzt schauen sollte? Für mich sehen die conf-Dateien alle ok aus.
In dmesg ist zum Zeitpunkt des Ausfalls nichts auffälliges zu erkennen.

 

[Krik]

[krik@krix ~]$ dig @127.0.0.1 gh.de
;; communications error to 127.0.0.1#53: connection refused
;; communications error to 127.0.0.1#53: connection refused
;; communications error to 127.0.0.1#53: connection refused

; <<>> DiG 9.20.22 <<>> @127.0.0.1 gh.de
; (1 server found)
;; global options: +cmd
;; no servers could be reached

2 Sekunden später ging es wieder. Keine Ahnung wie, warum und weshalb.

Hat jemand eine Idee, was ich hier noch machen kann? Ich bin schon lange am Ende meines Lateins.

---

Nachtrag:
ich habe noch etwas gefunden:

[krik@krix ~]$ journalctl -u systemd-resolved -f
Apr 29 08:24:32 krix systemd-resolved[658]: 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
Apr 29 08:24:32 krix systemd-resolved[658]: Using system hostname 'krix'.
Apr 29 08:24:32 krix systemd[1]: Started Network Name Resolution.
Apr 29 08:24:32 krix systemd-resolved[658]: Switching to fallback DNS server 9.9.9.9#dns.quad9.net.
Apr 29 08:24:38 krix systemd-resolved[658]: enp9s0: Bus client set default route setting: yes
Apr 29 08:24:38 krix systemd-resolved[658]: enp9s0: Bus client set DNS server list to: 10.0.1.1
Apr 29 08:24:41 krix systemd-resolved[658]: Detected conflict on krix.local IN A 10.0.0.1
Apr 29 08:24:41 krix systemd-resolved[658]: Hostname conflict, changing published hostname from 'krix' to 'krix7'.
Apr 29 08:24:48 krix systemd-resolved[658]: Using degraded feature set UDP instead of UDP+EDNS0 for DNS server 10.0.1.1.
Apr 29 09:54:43 krix systemd-resolved[658]: Grace period over, resuming full feature set (UDP+EDNS0) for DNS server 10.0.1.1.

Mir ist nicht klar, was hier passiert bzw. warum das so passiert. Woher kommt der Namenskonflikt? Dieser PC ist der Einzige mit diesem Namen.
Und warum switched er von UDP+EDNS0 auf UPD, wenn es später ja doch funktioniert?

 

[dideldei]

Den Test kann ich mit 127.0.0.1 nicht nachvollziehen. Der Resolved liegt auf 127.0.0.53.

Das Problem bei der Suche ist, dass wir nur aus den Logs schlauer werden.

Meine Idee wäre es ein Loop einzuführen, weil das Zeitfenster zu klein ist.

while true; do
  echo "===== $(date '+%F %T') ====="
  dig +time=1 +tries=1 @127.0.0.53 computerbase.de &
  dig +time=1 +tries=1 @10.0.1.1 computerbase.de &
  wait
  sleep 1
done | tee ~/dns-test.log

Gleichzeitig im terminal offen lassen:

journalctl -b -f -u systemd-resolved -u NetworkManager

Und warten, bis der Fehler wieder auftaucht.

 

[Krik]

Der Resolved liegt auf 127.0.0.53.

Stimmt! O Mann! Ich schau schon so lange auf den Kram, dass ich solche Fehler nicht mehr sehe.

Meine Idee wäre es ein Loop einzuführen, weil das Zeitfenster zu klein ist.

So was habe ich auch probiert:

#!/bin/bash

LOGFILE="dns_errors.log"
touch "$LOGFILE"


while true; do
    echo "$(date '+%Y-%m-%d %H:%M:%S') - performing dns check"

    OUTPUT=$(dig @127.0.0.53 computerbase.de)
    if ! echo "$OUTPUT" | grep -q "status: NOERROR"; then
        echo "$(date '+%Y-%m-%d %H:%M:%S') - dig @127.0.0.53 computerbase.de:" >> "$LOGFILE"
        echo "$OUTPUT" >> "$LOGFILE"
        echo "---" >> "$LOGFILE"
    fi

    OUTPUT=$(dig @10.0.1.1 computerbase.de)
    if ! echo "$OUTPUT" | grep -q "status: NOERROR"; then
        echo "$(date '+%Y-%m-%d %H:%M:%S') - dig @10.0.1.1 computerbase.de:" >> "$LOGFILE"
        echo "$OUTPUT" >> "$LOGFILE"
        echo "---" >> "$LOGFILE"
    fi

    sleep 5
done

Nach einem ganzen Tag stand nichts in der Log.

Ich werde hier noch irre. Ich habe keinen Ansatz. Immer wenn ich denke, "ok, über diesen neuen Weg finde ich die Ursache," finde ich da nichts! Aber auch gar nichts! 🤬

Ich überlege schon, ob nicht einfach das System neu installiere in der Hoffnung, dass dadurch der Fehler verschwindet. Ich habe allerdings die Befürchtung, dass es nichts bringt, weil ich nicht weiß, was die Ursache ist. ☹️

 

[dideldei]

Dein loop hat sleep 5 drin - das ist für dein Szenario nicht passend, weil der Fehler dann auch wieder untertauchen kann. Und der Loop testet nicht gleichzeitig.

Und an einem Tag den Test zu beenden, ist nicht zielführend. Denn der Fehler tauchte auch wieder auf - nach deinem Test.

Siehe Post #38.