Was ist DNSSEC und wie funktioniert es?

DNSSEC (DNS Security Extensions) versieht DNS-Einträge mit digitalen Signaturen, damit Resolver prüfen können, dass eine Antwort wirklich vom Inhaber der Domain stammt und unterwegs nicht verändert wurde. Es verschlüsselt nichts; es beweist die Echtheit über eine Vertrauenskette, die an der DNS-Root beginnt.

Gewöhnliches DNS kann eine echte Antwort nicht von einer gefälschten unterscheiden. DNSSEC, standardisiert in den RFCs 4033, 4034 und 4035, schließt diese Lücke. Dieser Ratgeber erklärt die beteiligten Eintragstypen, die Funktionsweise der Validierung und die Fehler, die signierte Domains am häufigsten lahmlegen.

Das Problem, das DNSSEC löst

Ein rekursiver Resolver akzeptiert die erste Antwort, die zu seiner Anfrage passt. Ein Angreifer, der eine gefälschte Antwort einschleusen kann, sei es auf dem Netzwerkpfad oder indem er bei einem Cache-Poisoning-Angriff das Rennen gegen den echten Server gewinnt, kann die Nutzer dieses Resolvers auf eine IP-Adresse seiner Wahl umleiten. Alle, die sich diesen Resolver teilen, erhalten dann die gefälschte Antwort, bis der zwischengespeicherte Eintrag abläuft.

DNSSEC macht Fälschungen erkennbar. Jede Gruppe von Einträgen wird mit dem privaten Schlüssel der Zone signiert, und der passende öffentliche Schlüssel wird im DNS veröffentlicht. Ein validierender Resolver prüft die Signatur und weist alles zurück, was sich nicht verifizieren lässt. Wenn Sie zuerst etwas über Resolver und autoritative Server auffrischen möchten, lesen Sie was DNS ist und wie es funktioniert.

DNSSEC-Eintragstypen

Eintrag	Speicherort	Zweck
`DNSKEY`	Signierte Zone	Öffentliche Schlüssel zur Prüfung der Signaturen der Zone
`RRSIG`	Signierte Zone	Eine Signatur über eine Eintragsgruppe (zum Beispiel alle A-Einträge eines Namens), mit Beginn und Ende der Gültigkeit
`DS`	Übergeordnete Zone	Delegation Signer: ein Hash des Key-Signing-Keys der untergeordneten Zone, der Eltern- und Kindzone verknüpft
`NSEC`	Signierte Zone	Beweist, dass ein Name oder Eintragstyp nicht existiert, indem er den nächsten vorhandenen Namen in sortierter Reihenfolge nennt
`NSEC3`	Signierte Zone	Wie NSEC, aber mit gehashten Namen (RFC 5155), was das Auflisten aller Namen der Zone erschwert
`CDS` / `CDNSKEY`	Signierte Zone	Teilt der übergeordneten Zone mit, welchen DS-Eintrag sie veröffentlichen soll, und ermöglicht automatische Aktualisierungen (RFC 7344)

Unser Ratgeber zu den DNS-Eintragstypen behandelt die gewöhnlichen Einträge wie A, MX und TXT, die diese Signaturen schützen.

Warum der Nachweis der Nichtexistenz nötig ist

Ohne NSEC oder NSEC3 könnte ein Angreifer eine NXDOMAIN-Antwort („Dieser Name existiert nicht“) fälschen, die keine eigene Signatur tragen kann, weil es keinen Eintrag zum Signieren gibt. NSEC-Einträge geben dem Resolver eine signierte Aussage, dass zwischen zwei Namen nichts existiert, sodass sich auch eine Verneinung überprüfen lässt.

Key-Signing-Keys und Zone-Signing-Keys

Die meisten Zonen verwenden zwei Arten von Schlüsseln, die beide als DNSKEY-Einträge veröffentlicht werden:

Zone-Signing-Key (ZSK), DNSKEY-Flags 256: signiert die gewöhnlichen Eintragsgruppen der Zone. Er lässt sich oft wechseln, ohne dass jemand anderes beteiligt ist.
Key-Signing-Key (KSK), DNSKEY-Flags 257: signiert nur die DNSKEY-Eintragsgruppe. Sein Hash steht im DS-Eintrag bei der übergeordneten Zone, weshalb ein Wechsel eine Aktualisierung beim Registrar erfordert.

Durch die Aufteilung der Rollen bleiben routinemäßige Schlüsselwechsel bei Ihrem DNS-Anbieter, während nur der seltenere KSK-Wechsel die übergeordnete Zone berührt. Manche Setups verwenden stattdessen einen einzigen kombinierten Signaturschlüssel, was einfacher und bei modernen Algorithmen mit elliptischen Kurven wie Algorithmus 13 (ECDSA P-256 mit SHA-256) üblich ist.

Die Vertrauenskette

Eine Signatur hilft nur, wenn der Resolver dem Schlüssel vertraut, der sie erzeugt hat. DNSSEC baut dieses Vertrauen Schritt für Schritt ab der Root auf, die 2010 signiert wurde. Validierende Resolver werden mit dem KSK der Root-Zone als eingebautem Trust Anchor (Vertrauensanker) ausgeliefert. Um www.example.com zu validieren, geht ein Resolver so vor:

Er verifiziert mit dem Root-Trust-Anchor die DNSKEY-Gruppe der Root.
Er verifiziert den signierten DS-Eintrag für com in der Root-Zone und prüft dann, ob er zum KSK in der DNSKEY-Gruppe von com passt.
Er verifiziert den signierten DS-Eintrag für example.com in der Zone com und prüft dann, ob er zum von example.com veröffentlichten KSK passt.
Er verifiziert mit der DNSKEY-Gruppe von example.com den RRSIG über die A-Einträge von www.example.com.

Wenn jedes Glied verifiziert ist, gilt die Antwort als secure (sicher). Hat die übergeordnete Zone keinen DS-Eintrag für eine Zone, ist die Zone insecure (unsigniert), und die Antwort wird normal ausgeliefert. Existiert ein DS, aber die Signaturen lassen sich nicht verifizieren, ist die Antwort bogus (ungültig).

So sieht die Validierung aus: AD und SERVFAIL

Wenn ein validierender Resolver eine Antwort erfolgreich verifiziert, setzt er in der Antwort das Flag AD (Authenticated Data). Mit dig können Sie es sehen:

$ dig +dnssec www.example.com A @1.1.1.1

;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
www.example.com.  300  IN  A      192.0.2.10
www.example.com.  300  IN  RRSIG  A 13 3 300 20261101000000 20261011000000 12345 example.com. (signature data)

Schlägt die Validierung fehl, gibt der Resolver die möglicherweise gefälschten Daten nicht zurück. Er liefert SERVFAIL, was für Nutzer genauso aussieht wie eine nicht existierende Website oder ein DNS-Ausfall. Um zu bestätigen, dass DNSSEC die Ursache ist, wiederholen Sie die Abfrage mit deaktivierter Prüfung:

dig www.example.com A           # status: SERVFAIL
dig +cd www.example.com A       # status: NOERROR, answer returned

Wenn die Abfrage mit +cd (Checking Disabled) erfolgreich ist und die normale fehlschlägt, ist das DNSSEC der Zone defekt. Unser DNSSEC-Check führt diese Prüfungen für Sie aus und zeigt den Status von DS, DNSKEY und Signatur.

Typische Ursachen für DNSSEC-Ausfälle

DNS-Anbieter wechseln, ohne den DS-Eintrag zu entfernen

Das ist der klassische Fehler. Der DS-Eintrag bei der Registry verweist noch auf den KSK des alten Anbieters. Nach dem Wechsel der Nameserver liefert der neue Anbieter die Zone entweder unsigniert aus oder signiert sie mit anderen Schlüsseln. Validierende Resolver finden einen DS ohne passenden Schlüssel, stufen die Zone als bogus ein, und jede Abfrage liefert SERVFAIL.

Eine sichere Migration läuft so ab:

Löschen Sie beim Registrar den DS-Eintrag.
Warten Sie, bis der alte DS aus den Caches abgelaufen ist: mindestens die TTL des DS-Eintrags in der übergeordneten Zone, die Sie mit dig example.com DS sehen. Ein bis zwei Tage Wartezeit sind ein üblicher Sicherheitspuffer.
Stellen Sie die Nameserver auf den neuen Anbieter um und warten Sie, bis die alten NS-Einträge abgelaufen sind.
Aktivieren Sie DNSSEC beim neuen Anbieter und veröffentlichen Sie dessen neuen DS-Eintrag beim Registrar.

Manche Anbieter unterstützen ein Multi-Signer-Setup, das die unsignierte Lücke vermeidet, aber es erfordert die Zusammenarbeit beider Anbieter.

Abgelaufene Signaturen

Jeder RRSIG hat ein Ablaufdatum. Wenn der Signierprozess stehen bleibt, zum Beispiel auf einem selbst betriebenen Server, dessen Job zum erneuten Signieren fehlgeschlagen ist, laufen die Signaturen irgendwann ab, und die Zone gilt als bogus.

Zu schnelle Schlüsselwechsel

Wird ein alter Schlüssel entfernt, bevor die Caches den neuen übernommen haben, kommt es bei Resolvern, die noch die alte DNSKEY-Gruppe oder den alten DS-Eintrag halten, zu Ausfällen. Schlüsselwechsel (Rollovers) müssen die beteiligten TTLs berücksichtigen.

So aktivieren Sie DNSSEC für Ihre Domain

Prüfen Sie, ob Ihre TLD DNSSEC unterstützt; die meisten generischen und viele länderspezifische TLDs tun das.
Schalten Sie bei Ihrem DNS-Hosting-Anbieter die DNSSEC-Signierung ein. Er erzeugt die Schlüssel und signiert die Zone.
Kopieren Sie die Angaben des DS-Eintrags (Key-Tag, Algorithmus, Digest-Typ und Digest) in die DNSSEC-Einstellungen Ihres Registrars. Sind Anbieter und Registrar dasselbe Unternehmen, geschieht das oft automatisch, und manche Registries übernehmen CDS-Einträge automatisch.
Prüfen Sie das Ergebnis mit unserem DNSSEC-Check und kontrollieren Sie mit der DNS-Abfrage, dass gewöhnliche Abfragen weiterhin funktionieren.

Häufig gestellte Fragen

Verschlüsselt DNSSEC meine DNS-Anfragen?

Nein. DNSSEC sorgt für Authentizität und Integrität, nicht für Privatsphäre. Anfragen und Antworten bleiben im Netzwerk sichtbar. Für Verschlüsselung sorgen DNS over TLS oder DNS over HTTPS, die DNSSEC ergänzen.

Brauche ich DNSSEC, wenn meine Website HTTPS nutzt?

HTTPS-Zertifikate verhindern bereits, dass eine gefälschte DNS-Antwort unbemerkt Ihre Website imitiert, aber DNSSEC schützt zusätzlich das Mail-Routing, TXT-Einträge zur Verifizierung und weitere Einträge. Außerdem ist es Voraussetzung für DANE, das TLS-Zertifikatsinformationen im DNS veröffentlicht.

Warum funktioniert meine Domain in manchen Netzwerken, in anderen aber nicht?

Wenn DNSSEC defekt ist, liefern nur validierende Resolver SERVFAIL; nicht validierende antworten weiterhin. Dadurch scheint der Ausfall vom Netzwerk abzuhängen.

Wie schalte ich DNSSEC sicher ab?

Entfernen Sie zuerst den DS-Eintrag beim Registrar, warten Sie, bis er aus den Caches abgelaufen ist, und beenden Sie erst dann das Signieren der Zone. In der umgekehrten Reihenfolge kommt es zu einem Ausfall.

Alle Tools