Wenn Sie eine URL in Ihren Browser eingeben, übersetzt das Domain Name System (DNS) den Domainnamen in eine IP-Adresse. Dieser Vorgang — die Namensauflösung — geschieht bei jedem Seitenaufruf, jeder E-Mail-Zustellung und jedem API-Call. Das Problem: DNS wurde in den 1980er-Jahren ohne Authentifizierungsmechanismen entworfen. Jede DNS-Antwort wird akzeptiert, solange sie formal korrekt ist. Ob sie tatsächlich vom zuständigen Nameserver stammt oder von einem Angreifer eingeschleust wurde, prüft das Protokoll nicht.
Diese Designschwäche hat konkrete Konsequenzen. Bei einem Cache-Poisoning-Angriff schiebt ein Angreifer manipulierte DNS-Antworten in den Cache eines Resolvers. Alle nachfolgenden Anfragen werden dann auf eine vom Angreifer kontrollierte IP-Adresse umgeleitet — ohne dass der Nutzer oder der Betreiber der Domain etwas bemerkt. Der Kaminsky-Angriff von 2008 hat gezeigt, wie effizient sich diese Schwäche ausnutzen lässt und DNS Cache Poisoning zu einer realen, skalierbaren Bedrohung gemacht.
Was DNSSEC löst — und was nicht
DNSSEC (Domain Name Security Extensions) erweitert das DNS-Protokoll um kryptografische Signaturen. Jeder DNS-Eintrag wird mit einem privaten Schlüssel signiert, und validierende Resolver können mit dem zugehörigen öffentlichen Schlüssel prüfen, ob die Antwort authentisch ist und während der Übertragung nicht verändert wurde. Manipulierte oder gefälschte Antworten werden erkannt und verworfen.
Dabei ist es wichtig zu verstehen, was DNSSEC nicht leistet. DNSSEC verschlüsselt keinen DNS-Verkehr — die Anfragen und Antworten bleiben im Klartext sichtbar. Für die Vertraulichkeit der DNS-Kommunikation gibt es separate Technologien wie DNS over HTTPS (DoH) und DNS over TLS (DoT). DNSSEC schützt ausschließlich die Integrität und Authentizität der DNS-Daten. Es verhindert, dass ein Angreifer gefälschte Antworten einschleust, aber nicht, dass er den DNS-Verkehr mitlesen kann.
| Schutzziel | DNSSEC | DoH / DoT |
|---|---|---|
| Integrität (Daten nicht verändert) | Ja | Nein (nicht das Ziel) |
| Authentizität (Antwort vom richtigen Server) | Ja | Nein (nicht das Ziel) |
| Vertraulichkeit (Daten nicht einsehbar) | Nein | Ja |
| Verfügbarkeit (Schutz vor DDoS) | Nein | Nein |
Der Business Case für CISOs
Für Sicherheitsverantwortliche stellt sich die Frage: Warum sollte die Implementierung von DNSSEC Priorität haben? Die Antwort liegt in der Rolle von DNS als Fundament nahezu aller Netzwerkdienste. Ohne DNSSEC kann ein Angreifer den E-Mail-Verkehr umleiten (MX-Record-Manipulation), Nutzer auf Phishing-Seiten weiterleiten (A-Record-Spoofing) oder TLS-Zertifikate über manipulierte DNS-Validierung erschleichen.
Aus regulatorischer Sicht adressiert DNSSEC mehrere Anforderungen. Das BSI empfiehlt in der Veröffentlichung BSI-CS 121 „Umsetzung von DNSSEC" (2015, nach wie vor die aktuelle BSI-Referenz zum Thema) die Signierung eigener Zonen und die Validierung von DNSSEC-Signaturen auf Resolver-Seite. Der BSI Grundschutz behandelt DNS-Absicherung im Baustein APP.3.6. Die NIS2-Richtlinie fordert von betroffenen Unternehmen ein angemessenes Niveau der Netz- und Informationssicherheit, wozu die Absicherung der DNS-Infrastruktur gehört.
Beide Seiten müssen mitspielen
DNSSEC funktioniert nur, wenn beide Seiten der Kommunikation ihren Teil beitragen. Auf Seiten des Domaininhabers müssen die DNS-Zonen signiert werden — entweder durch den DNS-Serverbetreiber selbst oder durch den Registrar, sofern dieser DNSSEC als Dienstleistung anbietet. Auf Seiten der Nutzer muss der DNS-Resolver DNSSEC-Signaturen validieren. Eine signierte Zone, die nur von nicht-validierenden Resolvern abgefragt wird, bringt keinen Sicherheitsgewinn. Umgekehrt kann ein validierender Resolver eine unsignierte Zone nicht schützen.
In der Praxis bedeutet das: Selbst wenn Sie Ihre eigenen Zonen signieren, hängt der Schutz Ihrer Nutzer davon ab, ob deren Internet-Provider einen validierenden Resolver betreibt. Große öffentliche Resolver wie 1.1.1.1 (Cloudflare) und 8.8.8.8 (Google) validieren standardmäßig. Viele ISP-Resolver in Deutschland tun dies ebenfalls — aber nicht alle.
Wer kümmert sich um die Schlüssel?
Eine zentrale Frage vor der Implementierung ist die Aufteilung der Verantwortlichkeiten. Wenn Ihr Domainregistrar die DNS-Verwaltung übernimmt, kann er auch die DNSSEC-Schlüsselerzeugung, die Signierung der Zonendaten und den regelmäßigen Schlüsselwechsel als Dienstleistung anbieten. In der Praxis bietet jedoch nicht jeder Registrar diese Leistung an — und die Qualität variiert erheblich.
Wenn Sie Ihre DNS-Server selbst betreiben, liegt die vollständige Verantwortung für Schlüsselerzeugung, Signierung und Key Rollover bei Ihnen. Den öffentlichen Teil Ihres Schlüssels (den DS-Record) müssen Sie über Ihren Registrar in der übergeordneten TLD-Zone veröffentlichen. Kapitel 3 beschreibt diesen Prozess im Detail, und Kapitel 5 zeigt die Konfiguration für BIND und Unbound unter Linux.
Testen Sie den aktuellen DNSSEC-Status Ihrer Domain mit unserem kostenlosen DNSSEC-Check — so sehen Sie auf einen Blick, ob Ihre Zone bereits signiert ist und die Chain of Trust korrekt konfiguriert wurde.