Das Signal richtig lesen
Der Wortlaut der Meldung und der Zeitpunkt im Log sind der Ausgangspunkt. Erst danach lohnt sich die Suche nach der Ursache.
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 41234Mögliche Ursachen eingrenzen
- DS-Record bei der Registry passt nach einem Providerwechsel nicht mehr zum DNSKEY der Zone.
- Abgelaufene RRSIG-Signaturen, weil das automatische Neusignieren ausgefallen ist.
- Lame Delegation: Eingetragene Nameserver sind nicht autoritativ für die Zone oder nicht erreichbar.
- Nameserver antworten fehlerhaft oder blockieren TCP/EDNS (große Antworten).
Prüfen, bevor du etwas änderst
Abfrage mit DNSSEC-Daten
dig beispiel.de A +dnssecGleiche Abfrage ohne Validierung – klappt sie, liegt es an DNSSEC
dig beispiel.de A +cdDS-Record bei der übergeordneten Zone abfragen
dig +short DS beispiel.de @a.nic.deDNSKEY direkt beim autoritativen Server abfragen
dig +short DNSKEY beispiel.de @ns1.beispiel-dns.de
Beheben und erneut testen
- Falschen DS-Record beim Registrar löschen oder durch den passenden ersetzen; die TTL des DS beachten.
- Bei Providerwechsel mit DNSSEC zuerst DS entfernen, TTL abwarten, dann umziehen und neu signieren.
- Automatisches Re-Signing beim DNS-Provider bzw. in BIND/PowerDNS prüfen und reparieren.
- NS-Einträge bei Registry und in der Zone abgleichen.
Danach denselben Vorgang erneut ausführen und das Ergebnis mit der ursprünglichen Fehlermeldung vergleichen.
Für das nächste Ticket festhalten
Notiere die genaue Fehlermeldung, das Ergebnis der Prüfung, die Änderung und den erneuten Test. So kann das Team den nächsten Fall schneller zuordnen.
Warum funktioniert es bei manchen Nutzern und bei anderen nicht?
Nur validierende Resolver (z. B. 1.1.1.1, 8.8.8.8, viele Provider) liefern SERVFAIL. Nicht validierende Resolver geben die Antwort trotzdem aus.
Ausführliche Fehlerseite: DNS SERVFAIL: Ursache finden und beheben