So sieht die Meldung aus
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 41234Häufige Ursachen
- 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
- Abfrage mit DNSSEC-Daten
dig beispiel.de A +dnssec - Gleiche Abfrage ohne Validierung – klappt sie, liegt es an DNSSEC
dig beispiel.de A +cd - DS-Record bei der übergeordneten Zone abfragen
dig +short DS beispiel.de @a.nic.de - DNSKEY direkt beim autoritativen Server abfragen
dig +short DNSKEY beispiel.de @ns1.beispiel-dns.de - Validierungskette mit Begründung anzeigen
delv beispiel.de A
Lösung
- 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.
- Nach der Korrektur Resolver-Cache leeren, z. B.
unbound-control flush_zone beispiel.de.
Häufige Fragen
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.
Wie lange dauert es nach dem Fix?
So lange wie die TTL des DS-Records bzw. der negativen Antworten im Cache – oft eine bis 24 Stunden.