Warum DNSSEC für die Domain-Sicherheit unerlässlich ist

DNS wurde in den 1980er-Jahren für ein kooperatives Netz entworfen und vertraut Antworten grundsätzlich. Ein Resolver, der auf seine Frage eine plausible Antwort erhält, akzeptiert sie in der Regel, speichert sie im Cache und gibt sie an alle weiter, die danach fragen. Genau diese Offenheit nutzen Angreifer aus. DNSSEC (Domain Name System Security Extensions) behebt diese grundlegende Schwäche, indem Resolver prüfen können, ob eine Antwort tatsächlich vom Zoneninhaber stammt und unterwegs nicht verändert wurde. Dieser Artikel erklärt, welches Problem DNSSEC löst, wie die Vertrauenskette funktioniert und wie Sie DNSSEC aktivieren, ohne Ihre Domain lahmzulegen.

Wenn die Namensauflösung für Sie neu ist, lesen Sie zuerst unseren Leitfaden Wie DNS funktioniert; Eintragstypen wie A, MX und TXT behandeln wir in den Grundlagen der DNS-Einträge.

Das Problem: DNS-Antworten lassen sich fälschen

Eine klassische DNS-Abfrage ist ein kleines UDP-Paket. Der Resolver ordnet die Antwort anhand weniger Felder zu, etwa der Abfrage-ID und des Quellports. Kann ein Angreifer diese Werte erraten, das Rennen gewinnen oder sitzt er auf dem Netzwerkpfad, kann er eine gefälschte Antwort einschleusen. Das bekannteste Beispiel ist die 2008 von Dan Kaminsky veröffentlichte Cache-Poisoning-Technik. Sie zeigte, dass selbst ein Angreifer außerhalb des Pfades unter passenden Bedingungen den Cache eines Resolvers für eine ganze Domain innerhalb von Sekunden vergiften konnte.

Die Randomisierung des Quellports hat solche Angriffe deutlich erschwert, aber nicht unmöglich gemacht. Weitere Bedrohungen bestehen fort:

• Manipulation auf dem Pfad über kompromittierte Router, feindliche WLANs oder betrügerische Infrastruktur.
• Kompromittierte Resolver, bei denen ein vergifteter Cache viele Nutzer gleichzeitig auf eine gefälschte Website schickt.
• Umgeleitete E-Mails durch gefälschte MX-Einträge, wodurch Nachrichten ohne konsequente Verschlüsselung abgefangen werden können.

Verschlüsselung wie DNS over HTTPS schützt die Verbindung zwischen Ihnen und Ihrem Resolver, beweist aber nicht, dass dessen Antwort echt ist. Genau das leistet DNSSEC.

Was DNSSEC leistet – und was nicht

DNSSEC bietet Herkunftsauthentifizierung und Datenintegrität. Ein validierender Resolver kann bestätigen, dass ein Satz von Einträgen mit dem Schlüssel der Zone signiert wurde und sich seitdem nicht verändert hat. Außerdem gibt es den authentifizierten Nachweis der Nichtexistenz, sodass ein Angreifer keine gefälschte Antwort „Diesen Namen gibt es nicht“ unterschieben kann.

Ebenso wichtig ist, was DNSSEC nicht leistet:

• Es verschlüsselt nicht: Abfragen und Antworten bleiben für jeden auf dem Pfad lesbar.
• Es schützt nicht vor einem gekaperten Registrar-Konto. Ändert jemand dort Ihre Nameserver und Ihren DS-Eintrag, validieren auch die gefälschten Daten.
• Es sichert nicht die Website selbst; HTTPS und ein gültiges Zertifikat bleiben nötig.

Die neuen Eintragstypen

So funktioniert die Vertrauenskette

Ein validierender Resolver braucht nur einen einzigen Schlüssel, dem er vorab vertraut: den Key Signing Key der Root-Zone, hinterlegt als Vertrauensanker (Trust Anchor). Von dort folgt er einer Kette:

1. Der DNSKEY-Satz der Root wird mit dem Vertrauensanker geprüft.
2. Die Root-Zone enthält einen signierten DS-Eintrag für com. Der Resolver prüft die RRSIG dieses DS mit dem Root-Schlüssel.
3. Der Resolver holt den DNSKEY-Satz von com und stellt fest, dass einer der Schlüssel zum DS-Hash passt.
4. Das Muster wiederholt sich: com veröffentlicht einen signierten DS für example.com, der zu einem DNSKEY in Ihrer Zone passen muss.
5. Schließlich prüft Ihr DNSKEY die RRSIG der angefragten Antwort, etwa des A-Eintrags von www.example.com.

Stimmt jedes Glied, setzt der Resolver das AD-Flag (Authenticated Data). Scheitert ein Glied, verwirft ein validierender Resolver die Antwort und liefert SERVFAIL. Gibt es in der Elternzone keinen DS-Eintrag, gilt die Zone schlicht als unsigniert (insecure) und wird normal aufgelöst.

KSK und ZSK

Die meisten Zonen nutzen Schlüssel in zwei Rollen:

• Der Key Signing Key (KSK) signiert nur den DNSKEY-Satz. Sein Hash ist das, was Sie als DS-Eintrag bei der Elternzone hinterlegen; ein Wechsel erfordert daher eine Aktualisierung beim Registrar.
• Der Zone Signing Key (ZSK) signiert alle übrigen Einträge. Er lässt sich häufig und vollständig innerhalb Ihrer Zone wechseln, ohne die Elternzone zu berühren.

In DNSKEY-Einträgen trägt der KSK typischerweise das Flag 257, der ZSK 256. Manche Anbieter verwenden einen einzigen kombinierten Schlüssel (CSK); das funktioniert ebenfalls, nur erfordert dann jeder Schlüsselwechsel ein DS-Update.

Algorithmus 13 und warum er die gängige Wahl ist

Jeder Schlüssel und jede Signatur nennt eine Algorithmusnummer. Algorithmus 8 (RSA/SHA-256) war lange der Standard und wird weiterhin breit unterstützt. Algorithmus 13 (ECDSA mit Kurve P-256 und SHA-256) wird heute in aktuellen Best-Practice-Empfehlungen empfohlen und von vielen großen DNS-Anbietern standardmäßig genutzt – aus mehreren Gründen:

• Deutlich kleinere Schlüssel und Signaturen als RSA bei vergleichbarer Sicherheit, was DNS-Antworten kompakt hält.
• Kleinere Antworten verringern das Risiko von UDP-Fragmentierung und Rückfall auf TCP.
• Breite Unterstützung durch moderne validierende Resolver.

Algorithmus 15 (Ed25519) wird ebenfalls empfohlen, wird aber von manchen älteren Validatoren und Registries weniger einheitlich unterstützt. Der Digest-Typ des DS ist eine eigene Nummer: Üblich ist 2 (SHA-256).

DNSSEC mit dig prüfen

Fordern Sie mit +dnssec die DNSSEC-Daten an und achten Sie auf RRSIG-Einträge und das ad-Flag (Ausgabe gekürzt):

$ dig +dnssec example.com A

;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2
example.com.  300  IN  A      93.184.215.14
example.com.  300  IN  RRSIG  A 13 2 300 20261021000000 20261007000000 12345 example.com. (Signatur)

In der RRSIG steht 13 für den Algorithmus, 12345 für das Key Tag; die beiden Zeitstempel sind Ablauf und Beginn der Signatur. So vergleichen Sie Ihre Schlüssel mit der Elternzone:

$ dig example.com DNSKEY +short
257 3 13 mdsswUyr3DPW132mOi8V9xESWE8jTo0d...
256 3 13 oJMRESz5E4gYzS/q6XDrvU1qMPYIjCWz...

$ dig example.com DS +short
12345 13 2 3490A6806D47F17A34C29E2CE80E8A999FFBE4BE...

Die DS-Zeile enthält Key Tag, Algorithmus, Digest-Typ und Digest. Key Tag und Algorithmus müssen zum KSK (Flag 257) in Ihrem DNSKEY-Satz passen. Online-Analysewerkzeuge wie DNSViz stellen die gesamte Kette grafisch dar und markieren defekte Glieder.

Häufige Fehler und SERVFAIL

Tückisch ist, dass nur validierende Resolver scheitern. Wer einen nicht validierenden Resolver nutzt, sieht Ihre Website ganz normal – ein DNSSEC-Fehler wirkt deshalb wie ein rätselhafter Teilausfall. Hilfreich ist dig +cd (Checking Disabled) gegen einen validierenden Resolver: Klappt die Abfrage mit +cd und scheitert ohne, ist DNSSEC die Ursache.

DNSSEC sicher einführen

1. Unterstützung prüfen. TLD, Registrar und DNS-Anbieter müssen DNSSEC unterstützen. Die meisten großen TLDs sind signiert.
2. Signierung beim DNS-Anbieter aktivieren. Wählen Sie, sofern angeboten, Algorithmus 13 und lassen Sie den Anbieter ZSK-Wechsel automatisch durchführen.
3. DS-Eintrag beim Registrar hinterlegen. Übernehmen Sie Key Tag, Algorithmus, Digest-Typ und Digest exakt. Manche Registrare und Anbieter automatisieren das über CDS/CDNSKEY-Einträge.
4. Überprüfen. Kontrollieren Sie das ad-Flag über einen validierenden Resolver und sehen Sie sich die Kette in einem Analysewerkzeug an.
5. Umzüge planen. Beim Wechsel des DNS-Anbieters übertragen Sie die Schlüssel sauber – oder entfernen den DS, warten den Ablauf der DS-TTL in der Elternzone ab, ziehen um und aktivieren DNSSEC danach erneut.

DNSSEC hängt auch davon ab, dass Ihr Registrar-Konto in Ordnung bleibt, denn dort liegt der DS. Behalten Sie Registrar, Nameserver und Ablaufdatum mit der WHOIS- und RDAP-Abfrage von TLDix im Blick und verfolgen Sie die Verlängerungen Ihres gesamten Portfolios im TLDix-Panel, damit eine ausgelaufene Registrierung niemals die Kette unterbricht.

Lohnt sich DNSSEC?

Für Domains, über die E-Mail, Logins, Zahlungen oder Markenvertrauen laufen, lautet die Antwort in der Regel ja. Bei modernen Anbietern läuft das Signieren weitgehend automatisch, und Algorithmus 13 hält den Mehraufwand gering. Das eigentliche Betriebsrisiko konzentriert sich auf wenige, vorhersehbare Momente, vor allem DS-Änderungen und Anbieterwechsel. Wer diese sorgfältig handhabt, schließt mit DNSSEC still eine Lücke, die es im DNS von Anfang an gab – und schafft die Grundlage für Technologien wie DANE, die auf signierten DNS-Daten aufbauen.