DNSSEC erklärt: So werden DNS-Antworten authentifiziert

DNS Security Extensions, kurz DNSSEC, ergänzen DNS-Daten um eine kryptografische Authentifizierung. Sie helfen einem validierenden Resolver zu prüfen, dass eine Antwort zur vorgesehenen Zone gehört und unterwegs nicht verändert wurde. DNSSEC verschlüsselt keine DNS-Abfragen, verbirgt nicht die angefragte Domain und macht auch keine Website sicher. Es liefert eine Kette aus Signaturen und Schlüsseln, mit der ein Resolver signierte Daten bis zu einer vertrauenswürdigen Root zurückverfolgen kann. Ist die Kette korrekt konfiguriert, erhält der Resolver einen stärkeren Beleg für die Echtheit der Antwort; ist sie unterbrochen, kann die Validierung dazu führen, dass sonst normale Lookups fehlschlagen.

Die Records einer DNSSEC-Kette

Eine signierte Zone veröffentlicht DNSKEY-Records mit öffentlichen Schlüsseln, die zur Validierung von Signaturen dienen. RRSIG-Records tragen Signaturen für Record-Sets, und DS-Records in der übergeordneten Zone verbinden den Schlüssel einer untergeordneten Zone mit der Vertrauenskette der übergeordneten. NSEC- oder NSEC3-Daten können eine authentifizierte Nichtexistenz belegen, wenn ein Name oder Record nicht existiert. Betreiber verlassen sich in der Regel darauf, dass ihr DNS-Anbieter oder Registrar diese Werte erzeugt und pflegt, doch die Zuständigkeiten können aufgeteilt sein: Die untergeordnete Zone wird vom DNS-Host signiert, während der DS-Record der übergeordneten Zone über den Registrar veröffentlicht wird. Eine Abweichung zwischen beiden ist eine häufige Ursache für Validierungsprobleme.

Ein validierender Resolver folgt der Vertrauenskette von einem konfigurierten Vertrauensanker, üblicherweise der Root, durch über- und untergeordnete Zonen. Er prüft, ob die Signaturen gültig sind und die Records zu den Schlüsseln und Delegierungsdaten passen. Normale Nutzer bekommen diese Schritte nie zu sehen, doch die Wirkung zeigt sich im Ergebnis: Eine gültige signierte Antwort wird akzeptiert, eine unterbrochene Signaturkette kann dagegen SERVFAIL auslösen. Ein nicht validierender Resolver liefert womöglich einen Wert, den ein validierender Resolver ablehnt – deshalb können DNSSEC-Fehler netzwerkspezifisch wirken. Aufschlussreicher, als anzunehmen, der Hostname habe schlicht keine Records, ist es, Resolver zu vergleichen und den Validierungsstatus zu prüfen.

Wie DNSSEC-Fehler entstehen

Typische Fehlerfälle sind ein veralteter DS-Record, der nach einem Wechsel des DNS-Anbieters beim Registrar verbleibt, veröffentlichte Schlüssel, die nicht zur signierten Zone passen, abgelaufene Signaturen, weil das Signieren eingestellt wurde, oder eine geänderte Delegierung ohne Abstimmung zwischen übergeordneter und untergeordneter Zone. Eine DNSSEC-Einführung oder ein Schlüsselwechsel sollte dem dokumentierten Verfahren des Anbieters folgen und von einem unabhängigen validierenden Resolver aus verifiziert werden. Ist DNSSEC deaktiviert, können veraltete DS-Daten schädlicher sein als gar kein DS-Record, weil Validatoren weiterhin eine Kette erwarten, die die untergeordnete Zone nicht mehr liefert. Betrachten Sie Registrar und DNS-Host als verbundene Teile eines einzigen Prozesses.

• Fragen Sie nach, ob der DNS-Anbieter die Zone signiert und die Schlüsselrotation verwaltet.
• Bestätigen Sie, dass der DS-Wert beim Registrar den aktuellen Anweisungen des Anbieters entspricht.
• Testen Sie nach dem Aktivieren, Deaktivieren oder Migrieren von DNSSEC über einen validierenden Resolver.
• Planen Sie Schlüsseländerungen sorgfältig und halten Sie einen Rollback-Pfad bereit.
• Verwechseln Sie DNSSEC-Authentifizierung nicht mit verschlüsseltem DNS-Transport.

Einen Validierungsfehler eingrenzen

Liefert eine Domain bei validierenden Resolvern SERVFAIL, prüfen Sie die DNSSEC-Kette, bevor Sie unabhängige A- oder MX-Records ändern. Bestätigen Sie DNSKEY und Signaturen der autoritativen Zone und vergleichen Sie dann den DS-Record der übergeordneten Zone. Achten Sie auf die Gültigkeitszeiträume der Signaturen und auf kürzliche Änderungen beim Anbieter. Ein allgemeiner Domain-zu-IP-Lookup sagt Ihnen womöglich, dass die Auflösung fehlschlug, erklärt aber nicht zwingend, welches DNSSEC-Glied defekt ist; für diese tiefer gehende Frage brauchen Sie eine DNSSEC-fähige Diagnose. Halten Sie Resolver, Validierungsergebnis und Abfragezeit in einer Notiz fest, damit der Anbieter einen reproduzierbaren Fall untersuchen kann.

DNSSEC stärkt die Authentizität der Daten, doch betriebliche Sorgfalt bleibt wichtig. Es kann die Kompromittierung des Kontos eines Domain-Inhabers nicht verhindern und einen falschen Record nicht richtig machen; es authentifiziert die veröffentlichten Daten gemäß den konfigurierten Schlüsseln. Grundlagen finden Sie unter DNS-Auflösung erklärt und DNS-Record-Typen. Aktivieren Sie DNSSEC, wenn Sie die Kette pflegen und über Verlängerungen und Migrationen hinweg überwachen können, statt es als einmaligen Schalter zu betrachten, dessen Korrektheit sich auf unbestimmte Zeit voraussetzen ließe.

Schlüsselwechsel als koordinierte Änderung behandeln

Ein DNSSEC-Schlüsselwechsel ändert kryptografisches Material, auf das sich validierende Resolver verlassen. Die genaue sichere Abfolge hängt vom signierenden Anbieter ab und davon, ob der Wechsel verwaltet oder manuell erfolgt. Folgen Sie dem dokumentierten Verfahren, damit sich alte und neue Schlüssel wie erforderlich überlappen, die Signaturen gültig bleiben und die DS-Daten der übergeordneten Zone in der richtigen Phase zu den veröffentlichten Schlüsseln passen. Kopieren Sie keinen DS-Wert aus dem Screenshot eines veralteten Dashboards und löschen Sie ihn nicht, nur weil ein unabhängiger Lookup in ein Timeout lief. Verifizieren Sie nach einem Wechsel mit mehr als einem DNSSEC-validierenden Resolver und bewahren Sie die Ereignisprotokolle des Anbieters auf. Schlägt die Validierung fehl, halten Sie Domain, Resolver, Antwortcode und Zeitpunkt fest und prüfen Sie Signaturen und DS-Verknüpfung, bevor Sie Anwendungs-Records anfassen. Ein kontrollierter Wechsel mit Überwachung ist weit sicherer als ein Notfallversuch, die Kette zu reparieren, nachdem Browser und Mailsysteme bereits ausfallen.