DNSSEC: Was signierte DNS-Antworten wirklich schützen

Das Problem: Eine Antwort ist noch kein Beweis

Das klassische Domain Name System verteilt Informationen hierarchisch, liefert einem Resolver aber allein keinen kryptografischen Beweis dafür, dass eine Antwort tatsächlich vom zuständigen Zonenbetreiber stammt und unverändert angekommen ist. Genau an dieser Stelle setzt DNSSEC an: Die Erweiterungen fügen DNS-Daten Ursprungsauthentifizierung und Integritätsschutz hinzu.[1]

Ein validierender Resolver kann dadurch erkennen, ob signierte Resource Records auf dem Weg manipuliert wurden. Er kann außerdem authentisierte Aussagen darüber prüfen, dass ein bestimmter Name oder Record-Typ nicht existiert.[1]

Eine Vertrauenskette statt eines einzelnen Schlüssels

DNSSEC signiert nicht jede Anfrage spontan. Der Betreiber einer Zone veröffentlicht DNSKEY-Einträge und Signaturen in Form von RRSIG-Records. Die übergeordnete Zone verweist mit einem DS-Eintrag auf den Schlüssel der untergeordneten Zone. Ein Resolver folgt dieser Kette bis zu einem bereits vertrauten Ausgangspunkt.[2]

Wichtig ist die lückenlose Delegation. Eine signierte Zone ohne korrekt veröffentlichten DS-Eintrag erzeugt keine vollständige Vertrauenskette. Umgekehrt können abgelaufene Signaturen, falsche Schlüsselwechsel oder fehlerhafte Zeitangaben dazu führen, dass ein validierender Resolver eine Domain bewusst nicht mehr auflöst.

Was DNSSEC leistet

Der Kernnutzen ist präzise: DNSSEC macht die Herkunft und Unverändertheit signierter DNS-Daten überprüfbar. RFC 9364 bezeichnet den Einsatz der DNSSEC-Protokolle für diese Ursprungsauthentifizierung als Best Current Practice.[3]

Das erschwert Angriffe, bei denen manipulierte DNS-Antworten einen Nutzer unbemerkt zu einem falschen Ziel lenken sollen. Die Validierung findet typischerweise beim rekursiven Resolver statt; Anwendungen erhalten anschließend entweder eine gültige Antwort oder einen Fehler, wenn die kryptografische Prüfung scheitert.

Was DNSSEC ausdrücklich nicht leistet

DNSSEC verschlüsselt DNS-Anfragen und -Antworten nicht. Beobachter können die abgefragten Namen weiterhin sehen, sofern nicht zusätzlich ein verschlüsselter Transport wie DNS over TLS oder DNS over HTTPS verwendet wird. Auch die Verbindung zur aufgelösten IP-Adresse wird durch DNSSEC nicht geschützt.[1]

HTTPS bleibt deshalb unverzichtbar: TLS authentisiert den angesprochenen Dienst und schützt die übertragenen Inhalte. DNSSEC und TLS lösen unterschiedliche Aufgaben. Eine korrekt signierte DNS-Antwort sagt nicht, dass eine Webseite vertrauenswürdig ist; sie sagt nur, dass die Antwort zur signierten Zone passt.

Warum der Betrieb Aufmerksamkeit braucht

Mit DNSSEC entstehen zeitliche und organisatorische Abhängigkeiten. Signaturen besitzen Gültigkeitszeiträume, Schlüssel müssen kontrolliert ausgetauscht und DS-Einträge beim Registrar passend zur Zone gepflegt werden. RFC 4033 weist ausdrücklich auf diese neuen zeitlichen Abhängigkeiten hin.[1]

Eine belastbare Einführung braucht deshalb mehr als einen Schalter im DNS-Panel. Betreiber sollten die Vertrauenskette von außen prüfen, Ablaufzeiten überwachen und Schlüsselwechsel dokumentieren. Änderungen sollten zuerst mit einem validierenden Resolver getestet werden, bevor alte Schlüssel oder Signaturen entfernt werden.

Eine praktische Prüfliste

1. Unterstützen DNS-Provider und Registrar DNSSEC vollständig?
2. Ist der DS-Eintrag in der übergeordneten Zone veröffentlicht?
3. Lässt sich die Kette bis zum Vertrauensanker validieren?
4. Werden RRSIG-Ablaufzeiten überwacht?
5. Existiert ein dokumentierter Ablauf für Schlüsselwechsel?
6. Bleiben HTTPS und Zertifikatsüberwachung unabhängig davon aktiv?

DNSSEC ist damit weder Allheilmittel noch überflüssige Komplexität. Richtig betrieben schließt es eine konkrete Vertrauenslücke im DNS. Sein Wert entsteht gerade dadurch, dass sein Schutzbereich klar begrenzt und überprüfbar ist.