WebCheck

DNSSEC für Deine Domain: Vertrauenskette, DS-Eintrag und sicherer Anbieterwechsel

DNSSEC signiert die DNS-Antworten Deiner Domain, damit niemand Deine Besucher unbemerkt auf einen fremden Server lenkt. Einschalten lässt es sich schnell. Danach muss der DS-Eintrag beim Registrar dauerhaft zum Schlüssel der Zone passen.

Stand: 05.11.2026

Gefälschte DNS-Antworten

Wer www.beispiel.de aufruft, fragt zuerst einen Resolver nach der IP-Adresse, meist den des Internetanbieters. Ob die Antwort echt ist, kann klassisches DNS nicht feststellen. Schiebt ein Angreifer dem Resolver eine passende Fälschung unter, merkt der sie sich, und alle seine Nutzer landen bis zum Ablauf der TTL auf dem Server des Angreifers. Der Angriff heißt Cache Poisoning.

DNSSEC (RFC 4033, 4034 und 4035) versieht die Einträge einer Zone mit Signaturen. Ein prüfender, also validierender Resolver rechnet sie nach und verwirft jede Antwort, die nicht passt. Der Besucher bekommt dann eine Fehlermeldung statt einer falschen Adresse.

Grenzen von DNSSEC

DNSSEC verschlüsselt nichts, und die Verbindung zur Website sichert weiterhin TLS. Der Schutz reicht außerdem nur bis zum prüfenden Resolver. Laptops und Smartphones überlassen ihm die Prüfung und übernehmen sein Urteil, das AD-Bit in der Antwort. Im WLAN eines Hotels kann ein Angreifer auf diesem letzten Stück weiter fälschen. Und wessen Resolver gar nicht prüft, der hat von Deinen Signaturen nichts.

Eine Übernahme Deines Kontos beim Registrar fängt DNSSEC ebenfalls nicht ab, denn wer dort die Nameserver umstellt, löscht den DS-Eintrag gleich mit. Sichere das Konto mit einem zweiten Faktor ab.

Die Vertrauenskette

Eine signierte Zone veröffentlicht ihre Schlüssel als DNSKEY-Einträge, die Signaturen stehen als RRSIG neben den Daten. Damit ein Resolver dem Schlüssel traut, muss die übergeordnete Zone ihn bestätigen. Für beispiel.de steht deshalb in der Zone .de ein DS-Eintrag mit dem Hashwert Deines Schlüssels. Der DS-Eintrag für .de liegt in der Wurzelzone, und deren Schlüssel ist in jedem prüfenden Resolver fest hinterlegt.

beispiel.de.      86400  IN  DS      31406 13 2 4A1F0C7E...   ; in der Zone .de
beispiel.de.      3600   IN  DNSKEY  257 3 13 mdsswUyr...     ; KSK
beispiel.de.      3600   IN  DNSKEY  256 3 13 oJMRESz5...     ; ZSK
www.beispiel.de.  3600   IN  A       203.0.113.10
www.beispiel.de.  3600   IN  RRSIG   A 13 3 3600 ...

Der Key Signing Key (KSK, Flag 257) signiert nur die Schlüssel, auf ihn verweist der DS-Eintrag. Der Zone Signing Key (ZSK, Flag 256) signiert alles andere. Den ZSK tauscht der Anbieter, ohne dass es außerhalb der Zone jemand merkt. Ein neuer KSK braucht einen neuen DS-Eintrag.

Welcher Algorithmus

Welche Algorithmen empfohlen sind, legt seit RFC 9904 (November 2025) eine Liste der IANA fest. Sie löst RFC 8624 ab.

Nr. Algorithmus Zum Signieren
13 ECDSA P-256 mit SHA-256 empfohlen, kurze Signaturen
15 Ed25519 empfohlen, aber noch nicht von jedem Resolver geprüft
8 RSA mit SHA-256 empfohlen, deutlich größere Antworten
5, 7 RSA mit SHA-1 verboten (RFC 9905)

Für eine neue Zone ist 13 die übliche Wahl. Wer noch mit 5 oder 7 signiert, sollte umstellen, denn prüfende Resolver behandeln solche Zonen als unsigniert. In den DS-Eintrag gehört Hashtyp 2 (SHA-256).

DNSSEC einschalten

Der DNS-Anbieter signiert die Zone, der Registrar reicht den DS-Eintrag bei der Registry ein. Bei .de übermittelt er stattdessen den öffentlichen Schlüssel, und DENIC bildet den DS-Eintrag selbst. Liegen Domain und DNS beim selben Anbieter, ist das oft ein einziger Schalter. Sonst bleibt ein Handgriff. Cloudflare etwa zeigt nach dem Einschalten Key Tag, Algorithmus, Digest und öffentlichen Schlüssel an, und diese Werte trägst Du beim Registrar ein.

Mit CDS-Einträgen (RFC 7344, RFC 8078) kündigt die Zone selbst an, welcher DS-Eintrag gelten soll. Registries wie die von .ch und .cz übernehmen das automatisch.

Wenn der DS-Eintrag nicht mehr passt

Passt der DS-Eintrag zu keinem Schlüssel der Zone, ist sie „bogus“. Prüfende Resolver antworten nur noch mit SERVFAIL, und für ihre Nutzer sind Website und Mail weg. Wer ohne Prüfung auflöst, merkt nichts. Bei der Fehlersuche hört man deshalb gern „bei mir geht es doch“. Typische Auslöser:

  • Wechsel des DNS-Anbieters, während beim Registrar noch der alte DS-Eintrag steht
  • DNSSEC beim Anbieter abgeschaltet, den DS-Eintrag aber vergessen
  • neuer KSK ohne neuen DS-Eintrag
  • abgelaufene Signaturen, weil ein selbst betriebener Nameserver nicht mehr neu signiert

Am Abend des 5. Mai 2026 traf es die ganze Endung .de. Ein Schlüsselwechsel bei DENIC erzeugte ungültige Signaturen, und über prüfende Resolver ließ sich stundenlang kein .de-Name auflösen.

Anbieterwechsel in der richtigen Reihenfolge

  1. DS-Eintrag beim Registrar entfernen. Die Zone beim alten Anbieter bleibt signiert.
  2. Einen Tag warten, so lange gilt der DS-Eintrag bei .de und .com.
  3. Zone beim neuen Anbieter anlegen, Einträge vergleichen, Nameserver beim Registrar umstellen.
  4. Wieder warten, bis die alten Nameserver aus den Caches sind: bei .de einen Tag, bei .com zwei.
  5. DNSSEC beim neuen Anbieter einschalten und den neuen DS-Eintrag hinterlegen.
  6. Erst dann die Zone beim alten Anbieter löschen.

Bis Schritt 5 ist die Domain ungeschützt, aber erreichbar. Ganz ohne Lücke geht es nur mit Multi-Signer (RFC 8901), und das müssen beide Anbieter beherrschen.

Nachprüfen mit dig, delv und DNSViz

dig +dnssec beispiel.de SOA @9.9.9.9
dig +cd beispiel.de SOA @9.9.9.9
delv beispiel.de

Steht bei den Flags der ersten Antwort ad, hat der Resolver die Signatur geprüft. Kommt dort SERVFAIL, beim zweiten Aufruf mit abgeschalteter Prüfung aber eine Antwort, ist die Signatur kaputt. delv aus dem BIND-Paket prüft selbst. Am anschaulichsten ist DNSViz (dnsviz.net) mit einer Grafik der ganzen Kette.

Was DNSSEC möglich macht

Erst signiert taugt DNS für Angaben, an denen Sicherheit hängt. Per DANE hinterlegst Du in einem TLSA-Eintrag den Fingerabdruck Deines Zertifikats, und Mailserver prüfen ihn beim Versand untereinander (RFC 7672). Und seit dem 15. März 2026 müssen Zertifizierungsstellen DNSSEC prüfen, wo es eingerichtet ist. Unterdrückt ein Angreifer Deinen CAA-Eintrag, merkt die CA das. Eine kaputte Zone verhindert damit aber auch Dein nächstes Zertifikat.

DNSSEC prüfen

ZwoWebCheck fragt einen prüfenden Resolver nach der registrierten Domain, bei shop.beispiel.de also nach beispiel.de. Als signiert zählt die Zone nur, wenn die Kette bis zur Wurzel steht. Fehlt der DS-Eintrag, meldet der Bericht deshalb, dass die Zone nicht durchgehend abgesichert ist, auch wenn Dein Anbieter schon signiert. Scheitert die Anfrage nur mit Prüfung, meldet der Bericht eine kaputte Signatur als kritisch.