DNSSEC: DNS-Antworten authentifizieren

Im Jahr 2008 veröffentlichte der Forscher Dan Kaminsky Einzelheiten zu einem kritischen Angriff auf DNS-Resolver. Der Angriff nutzte das kleine 16-Bit-Transaktions-ID-Feld in DNS-Antworten aus. Indem ein Angreifer einen Resolver mit gefälschten Antworten und zufälligen Transaktions-IDs überflutete, konnte er statistisch gesehen erfolgreich die legitime Transaktions-ID erraten, bevor die echte Antwort eintraf. Ein vergifteter Cache leitet alle Benutzer dieses Resolvers wochenlang auf vom Angreifer kontrollierte Server um, bis der Cache abläuft.

DNSSEC (DNS Security Extensions) ergänzt DNS-Antworten um eine kryptografische Authentifizierung. Jedem Resource-Record-Set in einer mit DNSSEC signierten Zone ist eine digitale Signatur zugeordnet. Validierende Resolver überprüfen diese Signaturen, bevor sie Records akzeptieren. Eine gefälschte oder veränderte Antwort hat eine ungültige Signatur und wird abgewiesen. DNSSEC schützt vor Cache-Poisoning und dem Fälschen von Antworten, verschlüsselt DNS-Abfragen jedoch nicht.

DNSSEC verwendet pro Zone eine Hierarchie aus zwei Schlüsseln. Der Zone Signing Key (ZSK) wird zum täglichen Signieren einzelner DNS-Record-Sets verwendet. Der Key Signing Key (KSK) signiert ausschließlich das DNSKEY-Record-Set, das die öffentlichen Schlüssel von ZSK und KSK enthält. Der ZSK kann häufig, etwa monatlich, ausgetauscht werden, während der KSK seltener, etwa jährlich, geändert wird, da der Hash des KSK in der übergeordneten Zone registriert werden muss und der Austausch operativ komplex ist.

Jedes signierte DNS-Record-Set, auch RRset genannt, besitzt einen entsprechenden RRSIG-Record, der die kryptografische Signatur über dieses RRset enthält. Wenn ein Resolver einen DNS-Record anfordert, enthält die Antwort sowohl den Record als auch dessen RRSIG. Der Resolver überprüft den RRSIG mithilfe des öffentlichen Schlüssels der Zone. Die Signatur umfasst den Inhalt, den Typ, die Klasse und die Ablaufzeit des Records und verhindert dadurch sowohl Änderungen als auch das erneute Abspielen alter, noch gültiger Signaturen.

Die Vertrauenskette in DNSSEC wird durch Delegation-Signer-(DS-)Records aufgebaut. Wenn eine Zone an eine untergeordnete Zone delegiert, veröffentlicht die übergeordnete Zone einen DS-Record, der einen Hash des KSK der untergeordneten Zone enthält. Ein Resolver, der der übergeordneten Zone vertraut, kann prüfen, ob der KSK-Hash der untergeordneten Zone mit dem DS-Record übereinstimmt, und dadurch Vertrauen in die Signaturen der untergeordneten Zone herstellen. Diese Kette erstreckt sich von der DNS-Root-Zone über die TLDs bis zu den einzelnen Domainzonen.

Jede mit DNSSEC signierte Zone veröffentlicht ihre öffentlichen Signaturschlüssel in DNSKEY-Records. Typischerweise gibt es zwei DNSKEY-Records: einen für den ZSK und einen für den KSK. Der Hash des öffentlichen KSK wird als DS-Record in der übergeordneten Zone registriert und verankert so das Vertrauen in die Zone bei ihrer übergeordneten Zone. Der Hash des KSK der Root-Zone ist als endgültiger Vertrauensanker, der Root Zone Trust Anchor, in validierenden Resolvern fest hinterlegt.

Die DNSSEC-Validierung beginnt bei der Root-Zone, deren KSK-Vertrauensanker in Resolvern fest hinterlegt ist. Der DNSKEY der Root-Zone wird verwendet, um dessen RRSIG zu überprüfen, der wiederum die DS-Records für TLDs wie .com authentifiziert. Der DNSKEY der .com-Zone überprüft deren RRSIG für die DS-Records einzelner Domains. Diese Kette kryptografischer Überprüfungen erstreckt sich von der Root bis zur abgefragten Domain und stellt sicher, dass jede Verbindung authentifiziert ist.

Wenn ein DNSSEC-validierender Resolver eine Antwort empfängt, führt er die vollständige Überprüfung der Vertrauenskette durch. Er ruft DNSKEY-Records ab, überprüft RRSIG-Signaturen, verfolgt DS-Records bis zum Root-Anchor zurück und kontrolliert die Ablaufzeiten der Signaturen. Wenn die Validierung fehlschlägt, gibt der Resolver einen SERVFAIL-Fehler zurück, anstatt die möglicherweise gefälschten Records auszuliefern. Die meisten großen öffentlichen Resolver, darunter Cloudflares 1.1.1.1 und Googles 8.8.8.8, führen eine DNSSEC-Validierung durch.

Die Einführung von DNSSEC verlief trotz der Sicherheitsvorteile langsam. Der Schlüsselaustausch erfordert eine Abstimmung zwischen Zonenbetreibern und übergeordneten Registries. Ein Fehler beim KSK-Rollover kann die gesamte Zone unerreichbar machen. Der KSK-Rollover der ICANN-Root-Zone im Jahr 2019 erforderte eine jahrelange Vorbereitung. Durch die Signaturen nimmt die Größe der Zone erheblich zu. Betreiber müssen eine automatisierte Schlüsselrotation und Überwachung implementieren. Diese operativen Komplexitäten haben dazu geführt, dass viele kleinere Domainbetreiber DNSSEC vermeiden.

Eine häufige Fehlannahme ist, dass DNSSEC den Datenschutz bei DNS-Abfragen gewährleistet. Das ist nicht der Fall. DNSSEC authentifiziert nur Antworten; Abfragen und Antworten werden weiterhin als unverschlüsselte UDP-Pakete über Port 53 übertragen. Jeder, der den Netzwerkverkehr überwacht, kann weiterhin jeden abgefragten Domainnamen sehen. DNS-over-TLS (DoT) und DNS-over-HTTPS (DoH) schützen die Privatsphäre bei Abfragen, indem sie den DNS-Datenverkehr verschlüsseln. DNSSEC und DoH/DoT ergänzen sich: Das eine gewährleistet Authentizität, das andere Vertraulichkeit.

Im Jahr 2024 waren etwa 90 Prozent der DNS-Root-Zone und der großen TLDs mit DNSSEC signiert. Allerdings sind nur etwa 20 bis 30 Prozent der einzelnen Domainnamen signiert. Die Unterstützung der DNSSEC-Validierung durch Browser und Anwendungen ist uneinheitlich. Der Sicherheitsvorteil von DNSSEC ist am größten in Verbindung mit DANE (DNS-Based Authentication of Named Entities), das DNSSEC verwendet, um Fingerabdrücke von TLS-Zertifikaten zu veröffentlichen, und Clients ermöglicht, Zertifikate zu überprüfen, ohne sich ausschließlich auf CAs zu verlassen.

Wie stellt ein DNSSEC-validierender Resolver ausgehend von einem leeren Zustand Vertrauen in die DNS-Records einer Domain her?

DNSSEC ergänzt DNS-Antworten um kryptografische Signaturen, um Cache-Poisoning und das Fälschen von Antworten zu verhindern. ZSKs signieren Record-Sets, KSKs signieren DNSKEY-Records, und DS-Records verknüpfen das Vertrauen zwischen übergeordneten und untergeordneten Zonen. Die Validierung beginnt beim fest hinterlegten Root Zone Trust Anchor. DNSSEC verschlüsselt den DNS-Datenverkehr nicht; DoH und DoT schützen die Privatsphäre, während DNSSEC die Authentizität gewährleistet. Die operative Komplexität, einschließlich des KSK-Rollovers, hat die breite Einführung verlangsamt.