--- id: "dnssec" kind: "glossary-term" title: "DNSSEC" language: "de" category: "DNS und technische Grundlagen" updated: "2026-10-10T23:12:43Z" canonical: "https://tldlog.com/de/glossar/dnssec/" translations: en: "https://tldlog.com/glossary/dnssec/" es: "https://tldlog.com/es/glosario/dnssec/" fr: "https://tldlog.com/fr/glossaire/dnssec/" it: "https://tldlog.com/it/glossario/dnssec/" pt-BR: "https://tldlog.com/pt/glossario/dnssec/" ru: "https://tldlog.com/ru/glossariy/dnssec/" zh-Hans: "https://tldlog.com/zh/cihui/dnssec/" --- # DNSSEC Domain Name System Security Extensions Erweiterungen des DNS, die DNS-Antworten digitale Signaturen hinzufügen. Mit den Signaturen kann ein Resolver (der Server, der Namen für Nutzer nachschlägt) prüfen, ob eine Antwort echt ist und unterwegs nicht verändert wurde. Inhaber aktivieren DNSSEC über ihren DNS-Anbieter und ihren Registrar. DNSSEC ergänzt die Antworten des Domain Name System um digitale Signaturen, sodass ein Computer prüfen kann, ob eine Antwort vom Inhaber einer Domain stammt und unterwegs nicht verändert wurde. Es verbirgt nichts und verhindert nicht jeden Angriff. Um es einzuschalten, müssen DNS-Anbieter, Registrar und Registry zusammenarbeiten. ## Wovor DNSSEC schützt, einfach erklärt Wenn jemand example.com aufruft, schlägt ein Resolver die Adresse nach. Ohne DNSSEC kann ein Angreifer, der dem Resolver eine gefälschte Antwort unterschiebt, Besucher auf den falschen Server lenken. Mit DNSSEC prüft ein validierender Resolver die Signatur und weist die Fälschung zurück. RFC 4033 (März 2005) legt fest, was DNSSEC leistet: den Nachweis von Herkunft und Unversehrtheit der DNS-Daten. Es bietet keine Vertraulichkeit, die Antworten bleiben also lesbar, und keinen Schutz vor Denial-of-Service-Angriffen. Es deckt nur DNS-Antworten ab, nicht Phishing oder die Übernahme eines Registrar-Kontos. RFC 9364 (Februar 2023) bezeichnet DNSSEC als Best Current Practice für die Authentifizierung von DNS-Daten; ob es für eine Domain genutzt wird, entscheidet der Inhaber. ## Wie die Vertrauenskette von der Root bis zur eigenen Domain funktioniert Ein validierender Resolver beginnt bei einem Schlüssel, dem er bereits vertraut: dem Vertrauensanker (Trust Anchor), also dem Key Signing Key der Root-Zone, den die IANA veröffentlicht. Von dort folgt er einer Kette: 1. Die Root-Zone enthält einen signierten DS-Record für .com. 2. Dieser DS-Record passt zu einem Schlüssel in der .com-Zone, mit dem der Resolver die Records von .com prüfen kann, einschließlich des DS-Records für example.com. 3. Dieser DS-Record passt zum Schlüssel von example.com, mit dem die eigenen Records der Domain geprüft werden. Eine signierte Zone, für die die übergeordnete Zone keinen DS-Record enthält, ist eine „Sicherheitsinsel“ (Island of Security): Sie lässt sich nicht von der Root aus validieren. Eine Antwort ist sicher (secure), wenn jede Signatur stimmt, unsicher (insecure), wenn ein signierter Nachweis zeigt, dass die übergeordnete Zone keinen DS-Record für die Zone enthält, und fehlerhaft (bogus), wenn erwartete Signaturen fehlen, abgelaufen oder unbrauchbar sind (RFC 4033). Bei einer fehlerhaften Antwort liefert der Resolver normalerweise einen Fehler, SERVFAIL (RFC 4035). ## Schlüssel und Records: KSK, ZSK, DNSKEY, DS und RRSIG - **DNSKEY**-Records veröffentlichen die öffentlichen Schlüssel einer Zone. - **RRSIG**-Records enthalten die Signaturen, jede nur zwischen einem Anfangs- und einem Ablaufdatum gültig. - **DS**-Records stehen in der übergeordneten Zone und enthalten einen Key Tag, eine Algorithmusnummer und einen Hashwert (Digest) des Schlüssels der untergeordneten Zone. - Der **KSK** signiert nur die Schlüsselmenge der Zone, und der DS-Record der übergeordneten Zone verweist auf ihn. Der **ZSK** signiert alles Übrige. RFC 6781 (Dezember 2012) merkt an, dass Validatoren beide Schlüsselarten gleich behandeln: Die Aufteilung ist betrieblicher Natur, und manche Zonen nutzen einen Schlüssel für beide Rollen. Der Nachweis, dass ein Name nicht existiert, braucht eigene Records. NSEC nennt den nächsten existierenden Namen, wodurch jeder die ganze Zone auflisten kann („Zone Walking“). NSEC3 (RFC 5155) bildet zuerst Hashwerte der Namen, verrät aber immer noch Einzelheiten wie die Größe der Zone. ## DNSSEC einschalten: was Registrar, Registry und DNS-Anbieter jeweils tun 1. Der DNS-Anbieter signiert die Zone und veröffentlicht DNSKEY- und RRSIG-Records. 2. Die DS-Daten oder die Schlüsseldaten gehen an den Registrar. 3. Der Registrar sendet sie per EPP mit der Erweiterung secDNS (RFC 5910, Mai 2010) an die Registry, entweder als DS-Daten oder als Schlüsseldaten, aus denen die Registry den DS-Record erzeugt. 4. Die Registry veröffentlicht den DS-Record in der TLD-Zone. Ist der Registrar zugleich DNS-Anbieter, sind die Schritte 1 bis 3 oft eine einzige Einstellung. Für gTLDs verpflichtet das Registrar Accreditation Agreement von 2013 Registrare, Anträge auf Hinzufügen, Entfernen oder Ändern von Schlüsselmaterial an Registrys, die DNSSEC unterstützen, nach RFC 5910 weiterzuleiten. Das Base Registry Agreement (gebilligt am 21. Januar 2024, Stand Oktober 2026 aktuell) verpflichtet gTLD-Registrys, ihre Zonen zu signieren und Schlüsselmaterial von untergeordneten Domains anzunehmen. Für ccTLDs gelten andere Regeln: beim Registrar oder bei der Registry nachfragen. Es gibt auch einen automatisierten Weg: Der DNS-Anbieter veröffentlicht CDS- und CDNSKEY-Records, die angeben, wie der DS-Record lauten soll, und manche Registrys und Registrare suchen danach. RFC 8078 (März 2017) führte ein Signal zum Abschalten von DNSSEC ein; RFC 9615 (Juli 2024) erlaubt der übergeordneten Zone, diese Records kryptografisch zu prüfen, bevor sie DNSSEC einschaltet. ## Was schiefgehen kann: abgelaufene Signaturen, Schlüsselwechsel und Wechsel des DNS-Anbieters - **Abgelaufene Signaturen.** RRSIG-Records, die nicht rechtzeitig erneuert werden, machen Antworten fehlerhaft (bogus). - **Ein DS-Record ohne passenden Schlüssel.** RFC 6781 nennt das „security lameness“: Die Domain fällt für jeden validierenden Resolver aus, und die Korrektur braucht Zeit, bis sie sich durchsetzt. Ein KSK-Wechsel braucht deshalb den neuen DS-Record in der übergeordneten Zone, bevor der alte Schlüssel entfernt wird. - **Wechsel des DNS-Anbieters.** Der bisherige Betreiber kontrolliert die Schlüssel. Die beste Methode ist ein abgestimmter Schlüsselwechsel (Key Rollover). Wirkt der bisherige Betreiber nicht mit, wird der DS-Record entfernt, die Nameserver werden gewechselt, und sobald sich das durchgesetzt hat, wird der neue DS-Record hinzugefügt. Dazwischen ist die Domain unsigniert, was RFC 8078 Validierungsfehlern vorzieht. Kurze TTLs helfen. Fehler zeigen sich als SERVFAIL für Nutzer validierender Resolver, während die Domain für alle anderen weiter funktionieren kann. An der Root plant die ICANN, Stand 9. Oktober 2026, den Root-KSK am 11. Oktober 2026 zu ersetzen: KSK-2024 (Key Tag 38696) löst KSK-2017 (Key Tag 20326) ab, der am 11. Januar 2027 widerrufen und am 22. März 2027 entfernt werden soll. Das betrifft die Betreiber validierender Resolver, die den neuen Vertrauensanker brauchen, nicht die Domaininhaber. ## DNSSEC und verschlüsseltes DNS: der Unterschied DNSSEC signiert die Daten, sodass jeder Resolver sie prüfen kann, aber alles bleibt lesbar. DNS over TLS (DoT) und DNS over HTTPS (DoH) verschlüsseln die Verbindung zwischen dem Gerät eines Nutzers und dem Resolver, was die Privatsphäre schützt, beweisen aber nicht, dass die Daten vom Inhaber der Zone stammen. Beides ergänzt sich. ## Quellen - [RFC 4033: DNS Security Introduction and Requirements](https://www.rfc-editor.org/rfc/rfc4033.txt) - [RFC 6781: DNSSEC Operational Practices, Version 2](https://www.rfc-editor.org/rfc/rfc6781.txt) - [RFC 5910: Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)](https://www.rfc-editor.org/rfc/rfc5910.txt) - [DNSSEC Trust Anchors and Rollovers](https://www.iana.org/dnssec/files) - [ICANN Announces Next Major Internet Security Update](https://www.icann.org/resources/press-material/release-2026-05-20-en) ## verwandte begriffe - [DS-Record](https://tldlog.com/de/glossar/ds-record/) - [DNSKEY-Record](https://tldlog.com/de/glossar/dnskey-record/) - [Resolver](https://tldlog.com/de/glossar/resolver/) - [DNS](https://tldlog.com/de/glossar/dns/)