DNSSEC-Fehler: SERVFAIL, eine Domain lässt sich nicht auflösen
Eine Domain gibt SERVFAIL, der Rest läuft? Oft schlägt die DNSSEC-Validierung fehl – abgelaufene Signatur oder falsche Uhrzeit. So prüfst du es.
Aufwand:
ca. 15 Min.
Voraussetzung:
Terminal, dig, delv
Das Symptom
Alles lädt, nur eine bestimmte Seite nicht. Kein Timeout, kein „Server nicht
gefunden“ im gewohnten Sinn – der Browser meldet schlicht, die Adresse lasse
sich nicht auflösen. Ein dig auf die Domain liefert kühl status: SERVFAIL.
Von einem anderen Anschluss aus geht dieselbe Seite manchmal problemlos.
Die „Layer 8“-Wahrheit
SERVFAIL heißt nicht „diese Domain gibt es nicht“ – das wäre NXDOMAIN. Es heißt
„ich habe eine Antwort bekommen, aber ich traue ihr nicht“. Bei DNSSEC prüft der
Resolver die kryptografische Signatur jeder Zone gegen eine Vertrauenskette bis
zur Root. Passt etwas nicht – eine abgelaufene Signatur, ein misslungener
Schlüsselwechsel beim Betreiber –, verwirft er die Antwort komplett, statt dir
etwas möglicherweise Gefälschtes unterzuschieben. Genau dafür ist DNSSEC da. Der
häufigste hausgemachte Sonderfall sitzt aber auf deiner Seite: eine falsch
gehende Uhr. Läuft die Systemzeit weit daneben, hält der Resolver eine
tadellose, noch gültige Signatur für abgelaufen und blockt. Bevor du also DNSSEC
verfluchst oder abschaltest, wirf einen Blick auf die Uhrzeit – manchmal ist der
Fehler keine Verschlüsselung, sondern ein Kalender, der falsch tickt.
Die echte, verifizierte Lösung
1000 % faktenbasiert. Jeder Befehl ist real, jeder Pfad existiert. Schritt für Schritt:
1.
Prüfen, ob es wirklich DNSSEC ist
Frag die Domain einmal normal und einmal mit deaktivierter Prüfung ab (+cd steht für 'checking disabled'). Kommt mit +cd eine Adresse, ohne aber SERVFAIL, ist die DNSSEC-Validierung der Grund:
dig example.com
dig +cd example.com
2.
Die Validierung im Detail nachvollziehen
delv führt die vollständige DNSSEC-Prüfung durch und benennt im Klartext, an welcher Stelle die Vertrauenskette reißt (etwa 'RRSIG expired' oder ein nicht passender Schlüssel):
delv example.com
3.
Systemzeit kontrollieren
Signaturen haben einen festen Gültigkeitszeitraum. Geht deine Uhr falsch, wertet der Resolver eine gültige Signatur als abgelaufen. Zeit und Synchronisationsstatus prüfen:
timedatectl status
4.
Ursache einordnen
Liefert +cd eine Adresse und die Uhr stimmt, liegt der Fehler in der Zone des Domain-Betreibers – abgelaufene Signatur oder fehlerhafter Schlüsselwechsel. Dann hilft nur, den Betreiber zu informieren und zu warten. Die Validierung bleibt aktiv; sie tut genau ihren Job.
Häufige Fragen (FAQ)
?Warum lädt genau eine Domain nicht, während alle anderen funktionieren?
Weil der Fehler nicht am Netz, sondern an der Signatur dieser einen Zone liegt. Bei DNSSEC prüft der Resolver, ob die DNS-Antwort kryptografisch korrekt signiert ist. Stimmt die Signatur nicht – etwa weil sie abgelaufen ist oder die Schlüssel nicht zusammenpassen –, verwirft der Resolver die Antwort und liefert SERVFAIL statt einer IP-Adresse. Alle sauber signierten Domains bleiben davon unberührt.
?Ist das mein Fehler oder der des Domain-Betreibers?
Meist der des Betreibers: eine abgelaufene Signatur oder ein misslungener Schlüsselwechsel in seiner Zone. Es kann aber auch bei dir liegen – wenn die Uhr deines Geräts stark falsch geht, hält der Resolver eine noch gültige Signatur für abgelaufen und bricht ab. Deshalb lohnt der Blick auf die Systemzeit.
?Kann ich DNSSEC einfach abschalten, damit die Seite lädt?
Technisch ja, sinnvoll nein. DNSSEC schützt dich vor untergeschobenen, gefälschten DNS-Antworten. Ein SERVFAIL ist genau der Schutz, der greift. Die Validierung dauerhaft zu deaktivieren löst das Symptom auf Kosten der Sicherheit. Besser den Betreiber informieren oder abwarten, bis die Zone repariert ist.
Belege
Diese Seite ist gegen die folgenden Primärquellen geprüft – Hersteller, Standard oder Gesetzestext. Wer es nicht glaubt, muss es nicht: Da steht, wo es nachzulesen ist.
Das Netzwerk ist verbunden, doch nichts lädt per Namen? Oft ist der DNS-Server des Anbieters gestört — ein zuverlässiger Ersatz-DNS bringt das Web zurück.
Liegen mehrere HTTPS-Namen auf einer IP, entscheidet die SNI-Erweiterung, welches Zertifikat kommt. Fehlt sie, liefert der Server das Standardzertifikat.