DNSRatgeber

DNSSEC: wie signierte DNS-Antworten Fälschungen erkennbar machen

DNSSEC ergänzt das DNS um digitale Signaturen. Ein validierender Resolver kann damit prüfen, ob eine Antwort wirklich aus der zuständigen Zone stammt und unterwegs nicht verändert wurde. Verschlüsselt wird dabei nichts, und eine fehlerhafte Signatur macht die Domain für validierende Resolver unerreichbar.

Serverschränke im dunklen Rechenzentrum, auf einer Metallplatte spiegelt sich ein warmes Licht in Form eines Schlosses
Bild: KI-generiert

Die Grundlagen des DNS stammen aus dem Jahr 1987 [10]. Eine Antwort auf die Frage "Welche IP-Adresse hat www.beispiel.de?" trägt deshalb von Haus aus keinen Nachweis, woher sie kommt. Wer eine gefälschte Antwort schneller oder geschickter einschleust als der echte Nameserver, kann Besucher auf einen fremden Server lenken. DNSSEC, die DNS Security Extensions, schließt diese Lücke mit digitalen Signaturen. Die maßgeblichen Standards RFC 4033, 4034 und 4035 erschienen im März 2005 [1, 2].

Was DNSSEC schützt und was nicht

DNSSEC sorgt für zwei Dinge: Ein Resolver kann feststellen, dass eine Antwort von der Zone stammt, die für den Namen zuständig ist, und dass die Daten unterwegs nicht verändert wurden. Dazu kommt ein signierter Nachweis, dass ein Name oder ein Eintragstyp nicht existiert [1]. Damit lässt sich etwa eine gefälschte Antwort "diese Domain gibt es nicht" erkennen.

Vertraulich macht DNSSEC die Abfragen dagegen nicht. RFC 4033 sagt ausdrücklich, dass die Erweiterungen weder Verschlüsselung noch Zugriffskontrolle bieten und auch nicht vor Überlastungsangriffen schützen [1]. Wer im WLAN mitliest, sieht weiterhin, welche Namen dein Gerät abfragt. Dafür gibt es DNS over HTTPS und DNS over TLS. Die DENIC weist außerdem darauf hin, dass DNSSEC nur garantiert, dass die Daten unverändert ankommen. Ob die hinterlegten Daten stimmen oder seriös sind, prüft es nicht [6].

Die neuen Einträge im Überblick

DNSSEC führt vier Eintragstypen ein [1, 2]. Das Verfahren NSEC3 für den Nichtexistenz-Nachweis kam 2008 hinzu [13]. Sie stehen in derselben Zone wie die gewohnten DNS-Einträge und werden meist automatisch vom Nameserver oder vom Provider erzeugt.

EintragAufgabe
DNSKEYenthält einen öffentlichen Schlüssel der Zone
RRSIGdie Signatur über eine Gruppe gleichartiger Einträge, etwa alle A-Einträge eines Namens
DS (Delegation Signer)steht in der übergeordneten Zone und enthält eine Prüfsumme (Digest) eines Schlüssels der untergeordneten Zone
NSEC und NSEC3belegen signiert, dass ein Name oder Eintragstyp nicht existiert

Der DS-Eintrag ist das Bindeglied zwischen zwei Zonen. Er speichert das Schlüsselkennzeichen (Key Tag), die Nummer des Algorithmus und den Digest des DNSKEY, auf den er zeigt. Hat ein Resolver den DS-Eintrag geprüft, kann er damit auch den Schlüssel der darunterliegenden Zone als echt ansehen [2].

Die Vertrauenskette von der Wurzel bis zur Domain

Ein validierender Resolver vertraut zunächst nur einem einzigen Schlüssel, dem Vertrauensanker der Root-Zone. Von dort hangelt er sich nach unten: Die Root-Zone enthält einen signierten DS-Eintrag für .de [5], die .de-Zone einen signierten DS-Eintrag für beispiel.de, und die Zone beispiel.de signiert ihre eigenen Einträge mit dem Schlüssel, auf den dieser DS-Eintrag zeigt. Die DENIC beschreibt diese Chain of Trust als Kette, die an der DNS-Wurzel beginnt und bis zur einzelnen Domain reicht [6].

Eine Metallkette hängt an einer alten Baumwurzel, die Glieder werden nach unten heller, Morgenlicht im Wald
Bild: KI-generiert

Am Ende ordnet der Resolver jede Antwort einem von vier Zuständen zu [1]:

  • sicher (secure): Kette vollständig, alle Signaturen gültig
  • unsicher (insecure): Die Kette belegt signiert, dass ab einer Stelle kein DS-Eintrag existiert. Die Zone ist also schlicht nicht signiert.
  • fehlerhaft (bogus): Die Zone müsste signiert sein, aber die Prüfung scheitert, etwa an fehlenden oder abgelaufenen Signaturen oder einem nicht unterstützten Algorithmus.
  • unbestimmt (indeterminate): Es gibt keinen Vertrauensanker für diesen Teil des Namensraums.

Für die Praxis zählt vor allem der Unterschied zwischen "unsicher" und "fehlerhaft". Eine unsignierte Domain funktioniert wie immer. Eine Domain im Zustand "bogus" dagegen bekommt von einem validierenden Resolver keine Daten, sondern den Fehlercode SERVFAIL (RCODE 2) [1, 3]. Für Nutzer dieses Resolvers sieht das aus, als wäre die Domain nicht vorhanden.

Schlüssel, Rollen und Algorithmen

Viele Zonen arbeiten mit zwei Schlüsselrollen. Der Key Signing Key (KSK) signiert nur die Gruppe der DNSKEY-Einträge der Zone, der Zone Signing Key (ZSK) alle übrigen Einträge. Für die Prüfung selbst ist die Trennung bedeutungslos, sie hat betriebliche Gründe: Der KSK ist über den DS-Eintrag mit der Elternzone verknüpft, sein Wechsel braucht also die Mitwirkung von Registrar und Registry. Den ZSK kann der Zonenbetreiber dagegen allein austauschen [7]. Einen KSK erkennst du am Flag-Wert 257 im DNSKEY-Eintrag, das gesetzte Bit für den Secure Entry Point. Ein reiner ZSK hat den Wert 256 [2, 7].

Zwei unterschiedliche Messingschlüssel und ein Siegelstempel liegen auf einem dunklen Schreibtisch im Lampenlicht
Bild: KI-generiert

Welche Signaturverfahren eingesetzt werden sollen, führt seit RFC 9904 vom November 2025 die IANA in ihren Registern. Die Empfehlungen selbst blieben dabei unverändert [4]. Für das Signieren empfohlen sind unter anderem RSASHA256 (Algorithmus 8), ECDSAP256SHA256 (Algorithmus 13) und ED25519 (Algorithmus 15). RSASHA1 (Algorithmus 5) gilt für neue Signaturen als nicht mehr empfohlen [4].

DNSSEC bei .de-Domains

Die .de-Zone ist seit dem 31.05.2011 im Regelbetrieb signiert. Die DENIC kündigte damals an, dass DNSSEC freiwillig bleibt: Niemand muss seine Domain signieren oder Schlüssel hinterlegen [5]. Die Signierung beauftragst du über deinen Provider [6]. Betreibt der Domaininhaber eigene Nameserver, nimmt der Provider dessen öffentlichen Schlüssel entgegen und leitet ihn an die Registry weiter [8].

Eine Besonderheit von .de: Die DENIC nimmt keinen DS-Eintrag entgegen, sondern den DNSKEY-Eintrag selbst. Den DS-Eintrag erzeugt sie beim Bau der Zone daraus. Bis zu fünf Schlüssel lassen sich je Domain hinterlegen [3]. Vor der Eintragung prüft die DENIC, ob der Schlüssel auf allen autoritativen Nameservern sichtbar ist, ob er die DNSKEY-Gruppe gültig signiert und ob sich eine gültige Kette bis zum SOA-Eintrag der Zone bilden lässt. Fehlt beim Schlüssel das SEP-Bit (Flag 256 statt 257), gibt es eine Warnung [3]. Mit diesen Prüfungen fällt ein Teil der Fehler schon vor der Delegation auf.

Typische Fehler, die eine Domain lahmlegen

Die meisten DNSSEC-Ausfälle entstehen beim Wechsel von Schlüsseln oder Nameservern. Folgende Fälle kommen besonders oft vor:

Eine Technikerin kniet am offenen Serverschrank und hält ein gelöstes Kabel, daneben ein Laptop von hinten
Bild: KI-generiert
  • Abgelaufene Signaturen: Jede RRSIG trägt einen Beginn und ein Ende ihrer Gültigkeit. Nach dem Ende taugt sie nicht mehr zur Prüfung, ganz gleich, welche TTL der Eintrag hat [1]. Wird die Zone nicht regelmäßig neu signiert, kippt sie in den Zustand "bogus".
  • Alter DS-Eintrag nach einem Schlüsselwechsel: Zeigt der DS-Eintrag in der .de-Zone noch auf einen Schlüssel, den die Zone nicht mehr veröffentlicht, reißt die Kette ab.
  • Nameserverwechsel bei aktivem DNSSEC: Der neue Anbieter signiert mit eigenen Schlüsseln, der DS-Eintrag zeigt aber noch auf die alten. Cloudflare verlangt deshalb, DNSSEC beim Registrar abzuschalten, bevor die Nameserver getauscht werden, und warnt, dass die Domain sonst unerreichbar werden kann [9].

Für den Wechsel zwischen zwei DNS-Betreibern kennt die DENIC zusätzlich ein geregeltes Verfahren, mit dem die Schlüsselverwaltung übergeben wird [6]. Ob dein bisheriger und dein neuer Provider es unterstützen, erfährst du bei ihnen. Die einfachere Variante bleibt der Ablauf in drei Schritten: DNSSEC beim alten Anbieter deaktivieren, abwarten, bis der DS-Eintrag aus der Elternzone verschwunden und seine TTL abgelaufen ist, dann die Nameserver ändern und DNSSEC beim neuen Anbieter wieder einschalten.

So prüfst du, ob eine Domain signiert ist

Ob eine Domain DNSSEC nutzt, zeigt sich an zwei Stellen. In der Elternzone muss für die Domain ein DS-Eintrag stehen, und die Zone selbst muss DNSKEY- und RRSIG-Einträge ausliefern. Mit dem DNS-Check kannst du die Einträge einer Domain abfragen. Bei .de-Domains bietet die DENIC mit NAST (nast.denic.de) zudem eine öffentliche Prüfung der Nameserver an [12]. Welche DNSSEC-Prüfungen dabei laufen, beschreibt die DENIC in ihrer Prüfvorgabe [3].

Ob dein eigener Resolver überhaupt validiert, hängt vom Internetanbieter oder vom eingestellten DNS-Dienst ab. Die DENIC nennt drei mögliche Orte für die Prüfung: den eigenen Rechner, den Internetprovider oder einen DNS-Dienstleister [6]. Wer den Resolver wechseln will, findet die Schritte unter DNS-Server am Gerät oder Router ändern.

Lohnt sich DNSSEC für deine Domain?

Für eine Domain mit Mailserver, Onlineshop oder Kundenlogin ist DNSSEC ein sinnvoller Baustein, weil es gefälschte DNS-Antworten für validierende Resolver erkennbar macht. Einige Verfahren bauen darauf auf, etwa DANE für Mailserver: Der empfangende Server veröffentlicht dabei TLSA-Einträge mit Zertifikatsdaten, und die müssen per DNSSEC validierbar sein [11]. Der Aufwand ist gering, wenn Registrar und DNS-Hoster dasselbe Unternehmen sind und die Signierung automatisch erledigen. Dann reicht oft ein Schalter in der Verwaltungsoberfläche.

Mehr Sorgfalt braucht es, wenn du Nameserver selbst betreibst oder DNS und Registrar getrennt hast. Dann musst du Schlüsselwechsel und Neusignierung im Blick behalten, und jeder Umzug der Zone wird zu einem Vorgang mit mehreren Schritten. Wer das nicht dauerhaft pflegen kann, fährt mit einer unsignierten Zone besser als mit einer, die nach ein paar Monaten durch abgelaufene Signaturen ausfällt. Allgemeine Hinweise zur Absicherung einer Website stehen auf Website-Sicherheit: Updates, Backups und Zugänge.

  1. Gesetz RFC 4033: DNS Security Introduction and Requirements. IETF. Stand März 2005. abgerufen am 29.10.2026
  2. Gesetz RFC 4034: Resource Records for the DNS Security Extensions. IETF. Stand März 2005. abgerufen am 29.10.2026
  3. Organisation DENIC-23, Abschnitt 3: Nameserver Predelegation Check DNSSEC. DENIC eG. Stand ohne Datum. abgerufen am 29.10.2026
  4. Gesetz RFC 9904: DNSSEC Cryptographic Algorithm Recommendation Update Process. IETF. Stand November 2025. abgerufen am 29.10.2026
  5. Organisation Deployment of DNSSEC in the productive zone (Mitteilung an die Liste public-l). DENIC eG. Stand 18.05.2011. abgerufen am 29.10.2026
  6. Organisation DNSSEC. DENIC eG. Stand ohne Datum. abgerufen am 29.10.2026
  7. Gesetz RFC 6781: DNSSEC Operational Practices, Version 2. IETF. Stand Dezember 2012. abgerufen am 29.10.2026
  8. Organisation FAQs zu DNSSEC. DENIC eG. Stand ohne Datum. abgerufen am 29.10.2026
  9. Organisation Set up a primary zone (Full setup). Cloudflare. Stand ohne Datum. abgerufen am 29.10.2026
  10. Gesetz RFC 1034: Domain Names, Concepts and Facilities. IETF. Stand November 1987. abgerufen am 29.10.2026
  11. Gesetz RFC 7672: SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS). IETF. Stand Oktober 2015. abgerufen am 29.10.2026
  12. Organisation Nameserver Check (NAST). DENIC eG. Stand ohne Datum. abgerufen am 29.10.2026
  13. Gesetz RFC 5155: DNS Security (DNSSEC) Hashed Authenticated Denial of Existence. IETF. Stand März 2008. abgerufen am 29.10.2026

Zuletzt geprüft am 29.10.2026, nächste Prüfung spätestens im Oktober 2027. Fehler entdeckt? Schreib uns.

Weitere Artikel