Die häufigste Verwirrung über DNSSEC besteht darin, es als „DNS-Verschlüsselung“ zu beschreiben. Teams, die von dieser falschen Prämisse ausgehen, kommen zu zwei gleichermaßen falschen Schlussfolgerungen: Entweder verwerfen sie die Funktion, weil „wir bereits TLS haben“, oder sie aktivieren sie, ohne die betriebliche Abhängigkeit zu verstehen, die sie gerade eingeführt haben. DNSSEC signiert DNS-Antworten zum Nachweis der Authentizität – es verschlüsselt nichts. Der Angriff, den es stoppt, die Folge einer schlecht verwalteten Konfiguration und das, was es einfach nicht abdeckt, sind drei verschiedene Themen, die eine gesonderte Behandlung verdienen.
Was DNSSEC eigentlich macht
Wenn ein rekursiver Resolver einen autorisierenden Server abfragt und eine Antwort erhält, gibt es im herkömmlichen DNS keinen Mechanismus, um zu überprüfen, ob diese Antwort legitim ist. Der von Dan Kaminsky im Jahr 2008 beschriebene Cache-Poisoning-Angriff – und spätere Varianten – nutzt genau dies aus: Ein Angreifer schleust falsche Datensätze in den Cache eines Resolvers ein und leitet den Datenverkehr ohne Wissen des Domaininhabers an IPs unter seiner Kontrolle um. Benutzer fragen den kompromittierten Resolver ab, erhalten eine bösartige IP mit einer scheinbar normalen Antwort und fahren fort. TLS allein löst dieses Problem nicht: Wenn der Benutzer zu einem Server weitergeleitet wurde, der über ein gültiges Zertifikat für die Domäne verfügt – beispielsweise über DV in einer anderen Zertifizierungsstelle erhalten – erscheint die HTTPS-Kette intakt, selbst wenn das Ziel betrügerisch ist.
DNSSEC löst das Problem auf der DNS-Ebene vor jeder TCP-Verbindung. Jede DNS-Antwort enthält RRSIG-Einträge – kryptografische Signaturen, die mit dem privaten Schlüssel der Zone generiert werden. Der Resolver, der die DNSSEC-Validierung unterstützt, überprüft die Signatur mithilfe des in der Zone veröffentlichten öffentlichen Schlüssels (DNSKEY-Eintrag) und überprüft, ob dieser öffentliche Schlüssel legitim ist, indem er den DS-Eintrag in der übergeordneten Zone überprüft – die Vertrauenskette geht von der Wurzel ab, durchläuft die TLD-Zone (.com, .com.br) und kommt in Ihrer Zone an. Ein Datensatz mit einer ungültigen oder fehlenden Signatur in einer Zone, die DNSSEC-Unterstützung deklariert, führt zu SERVFAIL: Der Resolver lehnt die Antwort ab, anstatt potenziell manipulierte Daten weiterzugeben.
Was DNSSEC nicht abdeckt
DNSSEC verschlüsselt keine DNS-Abfragen. Ein Beobachter im Netzwerk kann weiterhin sehen, welche Domains Sie abfragen – dafür gibt es DNS over HTTPS (DoH) und DNS over TLS (DoT), separate Protokolle, die den Transport verschlüsseln. DNSSEC schützt auch nicht den Inhalt Ihres Dienstes, schwächt DDoS gegen Ihre autorisierenden Server nicht ab und verhindert nicht Typosquatting oder Phishing auf Domains, die einfach wie Ihre aussehen. Die Garantie ist eng und spezifisch: DNS-Antworten für Ihre Zone kommen bei korrekter Signatur ohne Manipulation beim Resolver an.
Aktivierung auf Cloudflare
Der technische Prozess in Cloudflare ist einfach: Eine Schaltfläche im DNS-Bereich der Zone generiert das Schlüsselpaar, beginnt mit der Signierung aller Datensätze in der Zone und beginnt automatisch mit der Bereitstellung von RRSIG-Datensätzen. Die Funktion ist in allen Plänen verfügbar, auch im kostenlosen. Als Nächstes bestimmen Sie, ob DNSSEC funktioniert oder die Produktion unterbricht.
Nach der Aktivierung im Dashboard zeigt Cloudflare den DS-Eintrag an, den Sie bei Ihrem Registrar registrieren müssen. Dieser DS-Eintrag, der vom Registrar in der TLD-Zone veröffentlicht wird, ist der Link, der die Vertrauensstellung der TLD mit Ihrer Zone verbindet – ohne ihn ist die Vertrauenskette unvollständig und DNSSEC-validierte Resolver behandeln Ihre Zone als nicht signiert und nicht ungültig. Der DS-Registrierungsprozess variiert je nach Registrar: Einige verfügen über eine grafische Oberfläche auf dem Bedienfeld, andere erfordern die manuelle Eingabe der Felder – Schlüsseltag, Algorithmus, Digest-Typ und Digest. Cloudflare zeigt alle diese formatierten Werte an, nachdem Sie DNSSEC aktiviert haben.
Das Schlüsselrotationsproblem
Das Betriebsrisiko von DNSSEC liegt nicht in der Aktivierung, sondern in der Wartung. Cloudflare rotiert die DNSSEC-Schlüssel der Zone regelmäßig. In diesem Fall muss der beim Registrar registrierte DS-Eintrag aktualisiert werden, um den neuen Schlüssel widerzuspiegeln. Wenn der Registrar die automatische DS-Aktualisierung über API unterstützt – wie es bei Cloudflare Registrar, Amazon Route 53 im registrierten Domänenmodus und Namecheap mit aktivierter API der Fall ist – erfolgt die Rotation ohne manuelles Eingreifen. Wenn der Registrar dies nicht unterstützt, sendet Cloudflare Ihnen eine Warnung und Sie haben ein Zeitfenster für die manuelle Aktualisierung.
Das Fehlen dieses Fensters hat eine direkte Konsequenz: Der DS im Register zeigt auf einen Schlüssel, den die Zone nicht mehr verwendet. DNSSEC-validierte Resolver beginnen mit dem Empfang von RRSIG, das mit einem anderen Schlüssel als dem veröffentlichten DS signiert ist, kommen zu dem Schluss, dass eine Manipulation stattgefunden hat, und geben bei jeder Abfrage an Ihre Domain SERVFAIL zurück. Aus Sicht des Benutzers wird die Domäne einfach nicht mehr aufgelöst. Der Fix erfordert die Aktualisierung des DS im Registrar und das Warten auf die Verbreitung der TTL der TLD-Zone – was oft lange dauert und in der Größenordnung von Stunden liegt, da Sie diese TTL nicht kontrollieren.
Sicher aktivieren: Was Sie vorher und nachher überprüfen sollten
Bevor Sie DNSSEC aktivieren, bestätigen Sie, dass Ihr Registrar DS-Einträge für die betreffende Domain akzeptiert. Für .com.br-Domänen unterstützt Registro.br jetzt DNSSEC, die bisherige Unterstützung war jedoch inkonsistent – es lohnt sich, direkt im Dashboard zu überprüfen, ob die DS-Option für Ihre spezifische Domäne verfügbar ist, bevor Sie sie auf Cloudflare aktivieren. Wenn Sie Cloudflare aktivieren, ohne den DS beim Registrar registrieren zu können, bleibt die Zone zwar signiert, jedoch ohne die vollständige Vertrauenskette, was keinen zusätzlichen Schutz bietet und außerdem einen Zustand erzeugt, der bei zukünftigen Diagnosen zu Verwirrung führen kann.
Testen Sie nach der Aktivierung und Registrierung des DS die Validierung mit Tools wie dnssec-analyzer.verisignlabs.com oder dnsviz.net, bevor Sie den Vorgang als abgeschlossen betrachten. Diese Tools zeigen jedes Glied in der Vertrauenskette und identifizieren ungültige, abgelaufene oder fehlende RRSIG-Datensätze. Richten Sie Benachrichtigungen für die Schlüsselrotation ein – das Dashboard von Cloudflare bietet E-Mail-Benachrichtigungen – und dokumentieren Sie den DS-Aktualisierungsprozess in Ihrem DNS-Betriebs-Runbook. Eine schlecht verwaltete Rotation um drei Uhr morgens, bei der die Hauptdomäne des Unternehmens SERVFAIL zurückgibt, ist die Art von Vorfall, der im Runbook stehen sollte, bevor er passiert, nicht danach.
Erwägen Sie die parallele Aktivierung von CAA-Datensätzen. CAA gibt an, welche Zertifizierungsstellen berechtigt sind, Zertifikate für die Domain auszustellen, und Cloudflare unterstützt den Registrierungstyp ohne Einschränkungen. In Kombination mit DNSSEC schließt CAA eine zweite Angriffsfläche: Selbst wenn es einem Angreifer gelingt, eine CA über eine andere Schwachstelle auszutricksen, schränkt der CAA-Eintrag ein, welche CAs an die Domäne ausgeben können.
Lesen Sie auch
- DNS-Proxy vs. nur DNS: Was ändert sich und wann macht jeder Modus Sinn
- Cloudflare DNS: Netzwerkinfrastruktur, die weit über die Namensauflösung hinausgeht
- Cloudflare Load Balancing und Geo Steering: Wenn DNS zu einer intelligenten Verkehrsschicht wird
- Cloudflare Email Routing: E-Mails auf Ihrer Domain empfangen – und was nicht enthalten ist
- Cloudflare WAF: Was der verwaltete Schutz tatsächlich blockiert und was er durchlässt
- WAF + Ratenbegrenzung + Bot-Management: das Edge-Schutz-Trifecta
