Wie debugge ich DNS-Fehler?

[Krik]

Ich habe das Skript von einer KI entsprechend ändern lassen:

#!/bin/bash

LOGFILE="dns_errors.log"
TMPDIR=$(mktemp -d)
touch "$LOGFILE"

cleanup() {
    rm -rf "$TMPDIR"
}
trap cleanup EXIT

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

    dig +time=1 +tries=1 @127.0.0.53 computerbase.de > "$TMPDIR/out1.txt" &
    dig +time=1 +tries=1 @10.0.1.1 computerbase.de > "$TMPDIR/out2.txt" &
    wait

    COMBINED_OUTPUT=$(cat "$TMPDIR/out1.txt" "$TMPDIR/out2.txt")
    if echo "$COMBINED_OUTPUT" | grep -q "status: SERVFAIL"; then
        echo "$(date '+%Y-%m-%d %H:%M:%S') - Fehler:" >> "$LOGFILE"
        echo "127.0.0.53:" >> "$LOGFILE"
        cat "$TMPDIR/out1.txt" >> "$LOGFILE"
        echo "10.0.1.1:" >> "$LOGFILE"
        cat "$TMPDIR/out2.txt" >> "$LOGFILE"
        echo "---" >> "$LOGFILE"
    fi

    sleep 1
done

Ich bin schwer gespannt, ob das irgendwas auffängt.

Danke, @dideldei! Das hat mir wieder etwas Hoffnung gegeben.

 

[dideldei]

Dein code ist zu eng (grep -q "status: SERVFAIL" beispielsweise, weil hier die timeouts & refused nicht hervorgehoben werden)
Ich verweise noch einmal auf post #38.

Wenn du dir das per ai anzeigen lässt, fehlt hier die Inhaltsangabe, aus welchem Kontext kreiert wird.

 

[Krik]

Ich wollte verhindern, einfach von der Menge der Meldungen überrollt zu werden.

 

[dideldei]

Wir nutzen jede Meldung für eine Auswertung und dafür ist der Log da. Vorher eine Einschätzung zugeben, ob die Meldung relevant ist, können wir uns nicht leisten und kann zu Sackgassen führen.

 

[Krik]

[krik@krix ~]$ dig @127.0.0.53 youtube.com

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

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

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Thu Apr 30 13:56:24 CEST 2026
;; MSG SIZE  rcvd: 40

[krik@krix ~]$ dig @10.0.1.1 youtube.com

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

;; QUESTION SECTION:
;youtube.com.                   IN      A

;; Query time: 28 msec
;; SERVER: 10.0.1.1#53(10.0.1.1) (UDP)
;; WHEN: Thu Apr 30 13:56:35 CEST 2026
;; MSG SIZE  rcvd: 29

Das Skript, das computerbase.de permanent abfragt, zeigte keine Auffälligkeit. Journactl hat ungefähr passend zum Zeitpunkt das ausgeworfen. Davor wurde stundenlang nichts geloggt:

Apr 30 13:58:35 krix NetworkManager[866]: ((../NetworkManager/src/libnm-systemd-core/src/libsystemd/sd-event/sd-event.c:4458)): assertion '<dropped>' failed
Apr 30 13:58:35 krix NetworkManager[866]: <info>  [1777550315.4594] manager: NetworkManager state is now CONNECTED_SITE
Apr 30 13:59:38 krix NetworkManager[866]: <info>  [1777550378.5367] manager: NetworkManager state is now CONNECTED_GLOBAL

Ich habe in dieser kurzen Zeit auch ein Popup von KDE bekommen, dass meine Netzwerkverbindung eingeschränkt ist.

 

[dideldei]

Das sieht interessant aus. Der Log deutet darauf hin, dass der Pfad zum Resolver nicht mehr alleine die Ursache ist.

.1 und .53 fallen aus, bei youtube.com Servfail.

D. h. Adguard kann selbst die Ursache sein.

Als

dig @10.0.1.1 youtube.com

verwendet worden ist, kannst du im Querylog schauen, was dort steht?, also im AdGuard selbst.
Gern sonst separat ausführen + Querylog in Adguard.

 

[Krik]

kannst du im Querylog schauen, was dort steht?, also im AdGuard selbst.

Gar nichts hinsichtlich Youtube.

Die Zeiten im Adguard-Log sind um 2 Stunden zeitversetzt, weil Librewolf UTC+0 statt UTC+2 an die Seite meldet.
Der Ausfall war ca. um 13:56 bis 13:59 →11:56 bis 11:59 im Adguard.

Ich schließe daraus, dass Adguard die DNS-Abfragen zu Youtube in dem fraglichen Zeitraum gar nicht empfangen hat. Während dessen lief nämlich noch die sekündliche Abfrage von computerbase.de ohne zu murren durch und wurde auch geloggt. Ich habe das jedoch hier rausgefiltert. (2x dig pro Sekunde = 120 Abfragen pro Minute → einfach zu viel, um das hier zu posten)

 

[dideldei]

Das macht die Sache aber widersprüchlich.

Wenn bei „dig @10.0.1.1 youtube.com“ nichts im Querylog steht, wo ist denn Adguard? Weil Servfail angegeben worden ist. Die Frage ist, ob bei Adguard überhaupt was angekommem ist oder läuft da ein anderer Dienst.

Führe mal im Adguard Host aus:

sudo ss -lntup | grep ':53'

Und kannst du YouTube im loop aufnehmen?

Magst du mal dein Aufbau kurz beziffern?, vl übersehen wir was in der Kette. Seit dem der Resolved nicht mehr alleine die Ursache sein kann, sind wir zu weit abgebogen. Der Upstream von Adguard kann den Servfail auch auslösen.

sudo tcpdump -ni any 'host x.x.x.x and port 53'

Bei x die IP vom PC angeben.

Schönen 1. Mai Dir.

 

[Krik]

Wenn bei „dig @10.0.1.1 youtube.com“ nichts im Querylog steht, wo ist denn Adguard?

Reden wir hier aneinander vorbei? Bei Adguard wurde diese Abfrage nicht geloggt. Alle anderen Abfragen im selben Zeitraum im LAN hingegen wurden von Adguard geloggt.

sudo ss -lntup | grep ':53' auf dem Host von Docker:

udp   UNCONN 0      0                                  0.0.0.0:53727      0.0.0.0:*    users:(("dnsmasq",pid=1196,fd=13))                                                                                                        
udp   UNCONN 0      0                                  0.0.0.0:5353       0.0.0.0:*    users:(("avahi-daemon",pid=2554,fd=12))                                                                                                    
udp   UNCONN 0      0                              192.100.1.1:53         0.0.0.0:*    users:(("dnsmasq",pid=1385,fd=7))                                                                                                          
udp   UNCONN 0      0                              192.100.0.1:53         0.0.0.0:*    users:(("dnsmasq",pid=1346,fd=7))                                                                                                          
udp   UNCONN 0      0                                127.0.0.1:53         0.0.0.0:*    users:(("dnsmasq",pid=1196,fd=4))                                                                                                          
udp   UNCONN 0      0                                     [::]:5353          [::]:*    users:(("avahi-daemon",pid=2554,fd=13))                                                                                                    
udp   UNCONN 0      0                                    [::1]:53            [::]:*    users:(("dnsmasq",pid=1196,fd=6))                                                                                                          
tcp   LISTEN 0      32                               127.0.0.1:53         0.0.0.0:*    users:(("dnsmasq",pid=1196,fd=5))                                                                                                          
tcp   LISTEN 0      32                             192.100.0.1:53         0.0.0.0:*    users:(("dnsmasq",pid=1346,fd=8))                                                                                                          
tcp   LISTEN 0      32                             192.100.1.1:53         0.0.0.0:*    users:(("dnsmasq",pid=1385,fd=8))                                                                                                          
tcp   LISTEN 0      32                                   [::1]:53            [::]:*    users:(("dnsmasq",pid=1196,fd=7))

Adguard läuft im macvlan-Netzwerk, daher glaube ich nicht, dass dieser Befehl auf dem Docker-Host etwas bringt. Innerhalb des Adguard-Containers funktioniert er leider nicht. ss gibt es in der Umgebung nicht.

sudo tcpdump -ni any 'host x.x.x.x and port 53'
Auf welchem System soll ich das ausführen und wie viel willst du sehen? Es läuft ja endlos.

Youtube ist jetzt im Skript mit drin.

Mein Netzwerk sieht so aus:

→ Einige Geräte habe ich ausgelassen, z. B. Drucker. Diese hängen alle am Switch.
→ "Statisch via FB" bedeutet, dass diese Computer immer die gleiche IP von der Fritzbox bekommen.
→ Der DHCP der Fritzbox meldet allen Geräten, dass 10.0.1.1 der Standard-DNS ist.
→ Das 2. NAS ist die meiste Zeit aus und schaltet sich nur ein, wenn es ein Backup vom 1. NAS ziehen soll.
→ Alles hängt im gleichen Netz: 10.0.0.0/8


Ich wünsche auch dir einen schönen 1. Mai.

 

[dideldei]

Stimmt, auf den macvlan bringt ss nichts.

Nimm -c, dann verkürzt er und auf Krik den Befehl ausführen

sudo tcpdump -ni enp9s0 -vv -c 20 'host 10.0.1.1 and port 53'

Dann in einem zweiten Terminal

dig @10.0.1.1 youtube.com

Wir haben nicht einander vorbei geredet. Mit dem Ergebnis bekommen wir heraus, ob das Problem vor Adguard ist. Und es ist in dem Fall ungewöhnlich, dass im Query Log nichts vom dig auftaucht, darum jetzt tcpump.

 

[Krik]

Soll ich das länger laufen lassen oder zusammen mit dem anderen Skript laufen lassen? Ich verstehe nicht ganz, was ich hier machen soll.

 

[Krik]

Ich habe mit dem Skript bisher keine weiteren Fortschritte gemacht. Es zeichnet nie Fehler auf. Ich habe keine Ahnung warum.

Jetzt ganz neu:

10.0.3.1 ist ein Docker-Container in dem Komga läuft. Der Ping zu der IP funktionierte.

Ich schließe daraus, dass das Problem gar nicht bei der DNS-Auflösung besteht, sondern letzteres nur ein Symptom ist.
Ist möglicherweise doch die Netzwerkkarte defekt? Den Verdacht habe ich schon länger, vor allem weil WoL nicht funktioniert.

 

[dideldei]

Soll ich das länger laufen lassen oder zusammen mit dem anderen Skript laufen lassen? Ich verstehe nicht ganz, was ich hier machen soll.

Ohne Fehler läuft das senden und empfangen auf 10.0.1.1:53 und er hat im status noerror, statt servfail. Nur war der Fehler nicht dort aktiv und dieser Mitschnitt wäre wichtig, was passiert bei servfail. (Dieses Detail hilft, Adguard und Resolved in getrennte Pfade zu sehen)

Die Idee stand dahinter, auszuschließen, ob es der Resolved ist oder ob das Problem in Adguard ist. Da im Querylog auch nicht gelistet war, ist allerdings immer noch fraglich.

Der Verdacht auf DNS ist im Posting #45 geringer, weil es dort servfail und noerror gab. Und deine KDE Meldung deutet auch auf eine eingeschränkte Konnektivität hin -> Netzwerkmanager.

Das nicht erreichen auf 10.0.3.1. schließt erstmal DNS aus, weil es nicht nötig ist. Also würde ich langsam auf ein fehlerhaftes Netzwerkmanagement (Treiber auch möglich) tendieren, wenn nicht sogar der Docker Macvlan selbst, weil ein 2. Container davon ebenfalls betroffen ist.

Du hattest nicht zufällig geprüft, warum du ihn nicht erreichen konntest?

nc -vz 10.0.3.1 + Port
curl -v http://10.0.3.1:Port/

Es wäre tatsächlich tragisch, wenn es das NIC selbst ist - können wir das irgendwie auf die schnelle ausschließen - ansonsten kann das noch spannend werden.

 

[Krik]

Zu welchem Paket gehört nc? Bei mir ist das nicht installiert.

Du hattest nicht zufällig geprüft, warum du ihn nicht erreichen konntest?

Das Problem ist, dass diese Fehler ohne Muster auftreten und oft innerhalb von Sekunden wieder verschwinden.
Heute war es richtig schlimm. Gefühlt passierte der Rotz im Minutentakt. Ich hatte in einer Stunde mehr Fehler erlebt als in der gesamten letzten Woche. Und jetzt ist seit Stunden wieder Ruhe. 🤷‍♂️

Auffällig ist für mich, dass nur der PC diese Probleme hat. Und diese Probleme traten erst dann auf, als ich ihn in Betrieb genommen habe. Adguard lief vorher schon und das problemlos. Alle andere Geräte im Netzwerk zeigen das Problem nicht. Auch das Steam Deck, das früher die 10.0.0.1 getragen hat, hatte diese Probleme nicht.

Ich habe leider keine zweite Netzwerkkarte oder einen WLAN-Stick da, sonst hätte ich die/den mal schnell ausprobiert. So bleibt mir nur, die onboard-NIC als Verursacher anzusehen und das Mainboard zu reklamieren. Da habe ich irgendwie gar keine Lust drauf, weil das den PC möglicherweise für Wochen außer Gefecht setzt.

 

[qiller]

Zu welchem Paket gehört nc?

Kenn nc nur als Abk. für netcat.

Edit: Nagut, gaaanz früher mal stand nc auch für Norton Commander^^.

 

[dideldei]

Zu welchem Paket gehört nc? Bei mir ist das nicht installiert.

(...)

meisten "openbsd-netcat" - es gibt sicher noch andere Varianten aber am einfachsten:

sudo pacman -S openbsd-netcat

Zum Thema selbst: Die Denic Störung kommt zeitlich ungünstig und alles was dort passiert ist unbrauchbar.

Du kannst weiterhin die Mitschnitte laufen lassen und wenn ein Nicht-Erreichen wieder auftritt, analysiere die Adresse inkl. Port, wie oben beschrieben.

Zum Thema, dass es nur auf den PC auftaucht, kannst du auch den Treiber und den Kernel prüfen oder ändern. Die Nic bleibt aber noch auf der Abschussliste, solang es nicht ausgeschlossen ist.

Bezug noch einmal auf die eingeschränkte Konnektivität KDE. Wechsel auf ein anderen Port ( am Router) und Kabel tauschen, wenn möglich, um das aus zuschließen, dass das Problem innerhalb des PC's bleibt.

sudo pacman -S ethtool
sudo ethtool --show-eee enp9s0
sudo ethtool --set-eee enp9s0 eee off

HIer deaktivierst du den Stromparmodus, falls er im Low Power Modus geht, was auch zu Aussetzern führen kann

Grenzt sich der Fehler immer noch in unter einer Minute ein? Weil der Vergleich mit dig war wirklich sehr kurz, um ihn zu fassen.

@qiller Warum war der Norten Commander so schlecht im Verstecken?
Weil er immer sofort in zwei Panels aufgeflogen ist.

 

[norKoeri]

Ich schließe daraus, dass das Problem gar nicht bei der DNS-Auflösung besteht, sondern letzteres nur ein Symptom ist.

Dir wurde bereits empfohlen, auf dem Computer die App Wireshark mitlaufen zu lassen. Was ist daraus geworden?

Ich habe leider keine zweite Netzwerkkarte oder einen WLAN-Stick da, sonst hätte ich die/den mal schnell ausprobiert.

Alternativ könntest Du Dir für keine 10€ jeweils einen konfigurierbaren Switch und/oder einen USB-Ethernet-Adapter holen. Auf dem Switch dann Port-Mirroring aktivieren und so mittels zweiten Computer + Wireshark passiv mitlesen. Mit dem USB-Ethernet-Adapter die Hypothese mit der Netzwerk-Karte ausschließen.

 

[Krik]

Zum Thema selbst: Die Denic Störung kommt zeitlich ungünstig und alles was dort passiert ist unbrauchbar.

Jepp, leider.
Der Vorfall hat mich aber dazu gebracht, direkt wieder 9.9.9.9 statt 10.0.1.1 als DNS einzutragen. Seit dem gibt es keine Probleme mehr. Auch ein "eingeschränkte Konnektivität"-Popup war seit dem nicht mehr zu sehen.

Ich überlege mittlerweile, ob es einfach nur irgendeine Inkompatibilität zwischen dem PC und Adguard gibt. Das muss aber eine sehr seltene Konstellation sein, die solche Probleme verursacht und ehrlich gesagt, kann ich mir das so nicht vorstellen. Millionen Leute setzen die Software und den NIC ein und da bin ich der Einzige, bei dem es holpert?

Ob ein Schwenk auf PiHole plus eventuell Unbound besser laufen würde?

Du kannst weiterhin die Mitschnitte laufen lassen

Die haben über viele Tage tatsächlich nicht einen einzigen Ausfall aufgezeichnet. Ich glaube nicht, dass das zu irgendetwas führen wird.

Zum Thema, dass es nur auf den PC auftaucht, kannst du auch den Treiber und den Kernel prüfen oder ändern.

Wie kann ich das machen (also das Prüfen)?

Bezug noch einmal auf die eingeschränkte Konnektivität KDE.

Ich habe jetzt auch für ein paar Tage einen sekündlichen Ping-Test zum Docker-Container laufen lassen. Der hat auch keine Probleme aufgezeigt. Das Problem ist weg, seit ich auf 9.9.9.9 gestellt habe. Ich nehme an, das Popup taucht nur dann auf, wenn der Prozess, der den Internet-Test macht, die Zieladresse nicht auflösen kann. Oder mit anderen Worten: Das könnte auch wieder "nur" ein DNS-Problem sein.

Vorher:

[krik@krix ~]$ sudo ethtool --show-eee enp9s0
EEE settings for enp9s0:
        EEE status: enabled - inactive
        Tx LPI: 5 (us)
        Supported EEE link modes:  100baseT/Full
                                   1000baseT/Full
                                   2500baseT/Full
        Advertised EEE link modes:  100baseT/Full
                                    1000baseT/Full
                                    2500baseT/Full
        Link partner advertised EEE link modes:  Not reported
[krik@krix ~]$
sudo ethtool --set-eee enp9s0 eee off
[krik@krix ~]$ sudo ethtool --show-eee enp9s0
EEE settings for enp9s0:
        EEE status: disabled
        Tx LPI: 0 (us)
        Supported EEE link modes:  100baseT/Full
                                   1000baseT/Full
                                   2500baseT/Full
        Advertised EEE link modes:  100baseT/Full
                                    1000baseT/Full
                                    2500baseT/Full
        Link partner advertised EEE link modes:  Not reported

Ich stelle den DNS wieder auf 10.0.1.1 zurück und schaue, ob das hier etwas gebracht hat.

Grenzt sich der Fehler immer noch in unter einer Minute ein?

Ich glaube, es gibt gelegentlich auch Aussetzer, die über eine Minute dauern, aber definitiv deutlich unter 5 Minuten liegen. Gab es nicht irgendwo in dem ganzen Netzkram einen Standard-Timeout von 90 Sekunden? Es könnte sein, dass der abgewartet wird, aber ich bekomme nur die letzten paar (dutzend) Sekunden mit.

Wireshark (...) Was ist daraus geworden?

Noch nichts. Ich muss den Punkt überlesen haben.

Ich habe mir einen USB-NIC von einem Kumpel besorgt. Bevor ich den anschließe, würde ich gerne abwarten, ob das Deaktivieren des Energiesparmodus mein Problem löst.

---

Den Norton Commander habe ich auf dem PC meines Vaters auch gerne verwendet. Der hat einfach weniger Arbeitsspeicher belegt als Windows 3.1. ^^
Für mich ist der allerdings immer der "Norton Ommander". Das Handbuch in Ringbuchform hatte auf dem Deckblatt einen Schreibfehler. In Schriftgröße 50 oder was das war.


Nachtrag:
Das Ausschalten des Energiesparmodus hat nichts gebracht. Es kam wieder zu einem Ausfall. Ich habe dann wieder auf Quad9 gestellt und alles läuft bisher.
Ich klemme mal den USB-NIC an und lasse alles darüber laufen.

Nachtrag #2:
Ich habe eben den gleichen Fehler beim USB-NIC bekommen. Es hängt also nicht an der Hardware. Ok, super, das Mainboard muss ich also nicht tauschen. Optimismus!

Nachtrag #3:
Mit dem USB-NIC und 10.0.1.1 als DNS-Server:

[krik@krix ~]$ nc -vz duckduckgo.com 80
nc: getaddrinfo for host "duckduckgo.com" port 80: Name or service not known
[krik@krix ~]$ curl duckduckgo.com
curl: (6) Could not resolve host: duckduckgo.com
[krik@krix ~]$ dig @10.0.1.1 duckduckgo.com

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

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

;; ANSWER SECTION:
duckduckgo.com.         86      IN      A       40.114.177.156

;; Query time: 38 msec
;; SERVER: 10.0.1.1#53(10.0.1.1) (UDP)
;; WHEN: Thu May 07 12:42:14 CEST 2026
;; MSG SIZE  rcvd: 59

Bis ich bei dig angekommen war, hatte sich das wieder "beruhigt".

Ich muss mir irgendwas basteln, wo ich nur noch eine Adresse einwerfe, die gerade spinnt und er testet dann alles durch (dig, nc, curl, etc. + Wireshark oben drauf).

 

[Krik]

So, in den vorherigen Post habe ich genug gespamt. Sorry.

Ich habe von einer KI ein Skript schreiben lassen, dem ich nur eine Domain mitgeben muss, die er dann durchtestet. Soll ich noch andere Tests einbauen?

#!/bin/bash

# Domain-DNS- und Netzwerktest-Skript
# Parameter: Domain-Name

set -e

if [ $# -ne 1 ]; then
    echo "Usage: $0 <domain-name>"
    exit 1
fi

DOMAIN="$1"
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
LOGFILE="network_test_${DOMAIN}_${TIMESTAMP}.log"
PCAP_FILE="capture_${DOMAIN}_${TIMESTAMP}.pcap"

# Root-Rechte prüfen
if [ "$EUID" -ne 0 ]; then
    echo "Error: This script requires root privileges (sudo)"
    echo "Run: sudo $0 $DOMAIN"
    exit 1
fi

# Wireshark/tshark im Hintergrund starten
echo "[*] Starting packet capture with tshark..."
touch "$PCAP_FILE"
tshark -w "$PCAP_FILE" &
TSHARK_PID=$!
sleep 2

# Cleanup-Funktion
cleanup() {
    echo "[*] Stopping packet capture..."
    kill $TSHARK_PID 2>/dev/null || true
    wait $TSHARK_PID 2>/dev/null || true
    echo "[*] Results saved to:"
    echo "    Log: $LOGFILE"
    echo "    Capture: $PCAP_FILE"
}
trap cleanup EXIT

# Test-Log starten
exec > >(tee -a "$LOGFILE") 2>&1

echo ""
echo "=========================================="
echo "Network Test Report for: $DOMAIN"
echo "Date: $(date)"
echo "=========================================="
echo ""

# DNS-Tests mit verschiedenen Nameservern
echo "[1] DNS Resolution Tests"
echo "------------------------"
echo "Testing with 10.0.1.1 (internal DNS):"
dig @10.0.1.1 "$DOMAIN" 2>&1 || echo "FAILED: No response from 10.0.1.1"
echo ""
echo "Testing with 127.0.0.53 (local systemd-resolved):"
dig @127.0.0.53 "$DOMAIN" 2>&1 || echo "FAILED: No response from 127.0.0.53"
echo ""
echo "Testing with 9.9.9.9 (Quad9 public DNS):"
dig @9.9.9.9 "$DOMAIN" 2>&1 || echo "FAILED: No response from 9.9.9.9"
echo ""

# Ping-Test
echo "[2] ICMP Reachability Test"
echo "--------------------------"
ping -c 4 "$DOMAIN" 2>&1 | tee -a "$LOGFILE" || echo "FAILED: Domain not reachable via ICMP"
echo ""

# nc-Test (TCP Port 80/443)
echo "[3] TCP Port Connectivity Test"
echo "------------------------------"
echo "Testing HTTP (port 80):"
nc -zv -w 5 "$DOMAIN" 80 2>&1 || echo "FAILED: Port 80 unreachable"
echo ""

echo "Testing HTTPS (port 443):"
nc -zv -w 5 "$DOMAIN" 443 2>&1 || echo "FAILED: Port 443 unreachable"
echo ""

echo "=========================================="
echo "Tests completed"
echo "=========================================="

# Berechtigungen und Besitzer für Benutzer 'krik' setzen
echo "[*] Adjusting permissions for user 'krik'..."
chown krik:krik "$LOGFILE" "$PCAP_FILE" 2>/dev/null
chmod 640 "$LOGFILE" "$PCAP_FILE" 2>/dev/null
echo "[*] Files owned by krik and readable."

exit 0