DNS Troubleshooting: nslookup, dig, DoH

Häufigste DNS-Probleme

• Domain-Registrierung abgelaufen - das gesamte DNS funktioniert nicht mehr.
• Falscher A/AAAA-Record - nach einer Server-Migration vergessen zu aktualisieren.
• Fehlendes CNAME / MX - die Website läuft, aber die E-Mail nicht.
• TTL vor einer geplanten Änderung nicht gesenkt - die Caches der Provider liefern noch alte Daten.
• DNSSEC-Fehler - Validatoren lehnen unsignierte oder falsch signierte Records ab.
• Geo-DNS-Störung - ein Resolver aus einer bestimmten Region erhält die falsche Antwort.

nslookup: der einfachste Befehl

Auf allen OS ohne Installation verfügbar. Er verwendet den Standard-DNS-Server des Systems, kann aber als zweites Argument explizit angegeben werden.

$ nslookup epulz.io
Server:    127.0.0.53
Address:   127.0.0.53#53

Non-authoritative answer:
Name:      epulz.io
Address:   87.197.115.180

# Explizit Cloudflare DNS verwenden
$ nslookup epulz.io 1.1.1.1

# Bestimmter Record-Typ
$ nslookup -type=MX gmail.com 8.8.8.8
$ nslookup -type=TXT _dmarc.epulz.io 1.1.1.1

dig: detaillierte DNS-Abfrage für Unix

dig (Domain Information Groper) ist deutlich detaillierter und flexibler. Er ist Teil des Pakets bind-utils oder dnsutils.

$ dig epulz.io

;; QUESTION SECTION:
;epulz.io.                      IN      A

;; ANSWER SECTION:
epulz.io.               300     IN      A       87.197.115.180

;; Query time: 12 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: ...

Schlüsselfelder:

• TTL (300) = Anzahl der Sekunden, die der Resolver die Antwort cachen darf.
• ANSWER SECTION = das eigentliche Ergebnis.
• SERVER = welcher DNS-Resolver geantwortet hat.
• Query time = Dauer der Abfrage - nützlich beim Debuggen von langsamem DNS.

Praktische Befehle

# Kurze Antwort (nur IP)
$ dig +short epulz.io
87.197.115.180

# Alle Records
$ dig epulz.io ANY

# Trace der gesamten DNS-Hierarchie (von Root-Nameservern)
$ dig +trace epulz.io

# Reverse Lookup
$ dig -x 87.197.115.180

# Bestimmter Resolver
$ dig @8.8.8.8 epulz.io
$ dig @1.1.1.1 epulz.io
$ dig @9.9.9.9 epulz.io

# DNSSEC-Validierung
$ dig +dnssec epulz.io

DNS-over-HTTPS (DoH): wenn UDP/53 nicht verfügbar ist

In manchen Netzwerken (Corporate Firewalls, mobile Daten mit Blockierung) ist der traditionelle DNS-Port 53 blockiert. DoH verpackt DNS-Abfragen in HTTPS-Requests, sodass sie überall durchgehen, wo Port 443 funktioniert.

# Cloudflare DoH-Endpoint
$ curl -s "https://cloudflare-dns.com/dns-query?name=epulz.io&type=A" \
       -H "Accept: application/dns-json" | jq

# Google DoH
$ curl -s "https://dns.google/resolve?name=epulz.io&type=MX" | jq

Einen Online-DoH-Client mit übersichtlichem UI haben wir auch unter /tools/dns-lookup - ganz ohne Installation.

Vorgehen bei „Domain funktioniert nicht"

1. Registrierung prüfen. whois yourdomain.com oder über den Registrar. Wenn sie abgelaufen ist, lässt sich nichts anderes reparieren.
2. NS-Records prüfen. dig NS yourdomain.com @8.8.8.8. Werden die für die Domain zuständigen Nameserver zurückgegeben? Stimmen sie mit dem überein, was im Registrar-Panel steht?
3. A-Record prüfen. dig yourdomain.com @8.8.8.8. Wird die richtige IP zurückgegeben?
4. Aus einem externen Netzwerk testen (mobile Daten, VPN, Online-Tool). Sie selbst haben möglicherweise alte Daten gecached.
5. TTL prüfen. Wenn Sie gerade einen Record geändert haben, warten Sie mindestens die ursprüngliche TTL ab (standardmäßig 1 bis 24 Stunden).
6. DNSSEC prüfen. Wenn Sie es verwenden, kann die Signature-Chain beschädigt sein. dig +dnssec yourdomain.com zeigt bei Erfolg das ad-Flag.

DNS-Propagation: wie lange dauert sie?

„DNS-Propagation" ist ein leicht irreführender Begriff. DNS verbreitet sich nicht zu Ihnen - Ihre Resolver laden die Antwort herunter und cachen sie gemäß TTL. Erst nach Ablauf der TTL versuchen sie eine neue Abfrage.

Praktische Konsequenzen:

• Planen Sie eine Migration? Senken Sie die TTL auf 60 bis 300 Sekunden mindestens 48 Stunden im Voraus.
• Die alte IP bleibt bei einigen Clients noch lange nach der Änderung gecached. Schalten Sie den alten Server nicht sofort ab.
• Cloud-Provider (Cloudflare, AWS Route 53) unterstützen kurze TTL-Werte und schnelle Propagation von Änderungen, aber der Endclient muss trotzdem auf die TTL seines eigenen Resolvers warten.

Fazit

DNS ist der Infrastruktur-Klebstoff, den alle als selbstverständlich nehmen - bis er nicht mehr funktioniert. Regelmäßiges Monitoring von DNS-Records (A, NS, MX, deren TTL und DNSSEC-Validierung) deckt das Problem auf, bevor es ein Kunde per Telefon meldet.

Monitoring von DNS und WHOIS-Ablauf

ePulz.io überwacht A/AAAA/MX/NS-Records und Domain-Registrierungsablauf. 7 Tage kostenlos.

Monitoring starten →