DNS-Security: DNSSEC und CAA-Records praktisch einsetzen

1. DNS-Spoofing und Cache-Poisoning: Das Angriffsszenario hinter DNSSEC

Das klassische DNS-Protokoll wurde ohne kryptographische Absicherung entworfen: Eine DNS-Antwort enthält keinerlei Signatur, die belegt, dass sie tatsächlich vom autoritativen Nameserver stammt und unterwegs nicht verändert wurde. Ein Angreifer, der eine gefälschte Antwort einschleusen kann, etwa durch das Erraten der Transaktions-ID einer laufenden Anfrage, kann einen Resolver dazu bringen, eine falsche IP-Adresse für eine Domain zu cachen, ein Angriff, der als Cache-Poisoning bekannt wurde und durch die Kaminsky-Schwachstelle von 2008 breite Aufmerksamkeit erlangte.

Gelingt ein solcher Angriff, leitet der betroffene Resolver alle nachfolgenden Anfragen für die betroffene Domain auf eine vom Angreifer kontrollierte Adresse um, oft über Stunden oder Tage, solange die vergiftete Antwort im Cache verbleibt. Nutzer, die eigentlich mironsoft.de aufrufen wollen, landen unbemerkt auf einer vom Angreifer betriebenen Kopie der Seite, die Zugangsdaten abgreift oder Schadsoftware ausliefert, ohne dass im Browser ein sichtbares Warnsignal erscheint, solange kein TLS-Zertifikatsfehler auftritt.

2. Wie DNSSEC funktioniert: Signaturen und Vertrauenskette

DNSSEC ergänzt DNS-Antworten um kryptographische Signaturen, die in zusätzlichen Resource-Records wie RRSIG, DNSKEY und DS gespeichert werden. Jede Zone signiert ihre eigenen Einträge mit einem privaten Schlüssel, während der öffentliche Schlüssel über einen DS-Record bei der übergeordneten Zone hinterlegt wird, etwa der DS-Record für mironsoft.de bei der .de-Zone. Ein validierender Resolver kann so die Signatur jeder Antwort prüfen und eine ununterbrochene Vertrauenskette von der Root-Zone bis zur eigenen Domain nachvollziehen.

Diese Vertrauenskette bedeutet: Jede Fälschung einer Antwort würde die kryptographische Signatur ungültig machen, sodass ein validierender Resolver die manipulierte Antwort verwirft, statt sie zu cachen. DNSSEC verhindert damit gezielt Cache-Poisoning und Spoofing, liefert aber keine Verschlüsselung: DNS-Antworten bleiben weiterhin im Klartext lesbar, DNSSEC garantiert ausschließlich Authentizität und Integrität der Antwort, nicht deren Vertraulichkeit.

# DNSSEC-Status einer Domain prüfen
dig mironsoft.de DNSKEY +dnssec +short

# Vollständige Validierungskette anzeigen
delv mironsoft.de
# ; fully validated

# DS-Record beim Registrar hinterlegen (Beispielwerte)
# mironsoft.de. IN DS 12345 13 2 A94B58...D3F2

3. DNSSEC praktisch einrichten: DS-Record und Schlüsselrotation

Die Einrichtung beginnt beim DNS-Hosting-Provider, der DNSSEC für die Zone aktiviert und dabei automatisch ein Schlüsselpaar generiert, bestehend aus einem Key Signing Key für die DNSKEY-Records selbst und einem Zone Signing Key für die übrigen Records der Zone. Der öffentliche Teil des Key Signing Key wird als DS-Record beim Registrar hinterlegt, der ihn wiederum an die übergeordnete TLD-Zone weiterreicht, wodurch die Vertrauenskette geschlossen wird.

Schlüsselrotation gehört zum laufenden Betrieb dazu: Der Zone Signing Key sollte in regelmäßigen Abständen erneuert werden, während der Key Signing Key seltener, aber kontrolliert rotiert wird, da eine Aenderung hier zwingend eine Aktualisierung des DS-Records beim Registrar erfordert. Die meisten modernen DNS-Provider automatisieren diese Rotation vollständig, was das Risiko menschlicher Fehler deutlich reduziert gegenüber einer manuellen Schlüsselverwaltung.

4. CAA-Records: Kontrolle darüber, wer Zertifikate ausstellen darf

Ein CAA-Record, Certification Authority Authorization, legt auf DNS-Ebene fest, welche Zertifizierungsstellen überhaupt berechtigt sind, ein TLS-Zertifikat für die jeweilige Domain auszustellen. Seit 2017 sind alle dem CA/Browser-Forum angeschlossenen Zertifizierungsstellen verpflichtet, vor jeder Zertifikatsausstellung den CAA-Record der Zieldomain zu prüfen und die Ausstellung zu verweigern, wenn die anfragende Stelle nicht explizit gelistet ist.

Ohne CAA-Record kann grundsätzlich jede öffentlich vertrauenswürdige Zertifizierungsstelle ein Zertifikat für eine Domain ausstellen, sofern die Domainvalidierung erfolgreich verläuft. Das erhöht die Angriffsfläche, weil ein Angreifer, der kurzzeitig Kontrolle über die Domainvalidierung erlangt, etwa durch eine DNS- oder E-Mail-Schwachstelle, bei praktisch jeder beliebigen Zertifizierungsstelle ein gültiges Zertifikat beantragen kann. CAA-Records reduzieren diese Angriffsfläche auf die explizit erlaubten Aussteller.

5. CAA praktisch konfigurieren: issue, issuewild und iodef

Die Direktive issue erlaubt einer benannten Zertifizierungsstelle die Ausstellung regulärer Zertifikate, während issuewild speziell Wildcard-Zertifikate steuert und unabhängig von issue gesetzt werden kann. Wird issuewild auf ein Semikolon ohne Wert gesetzt, verbietet das jede Wildcard-Ausstellung vollständig, selbst für ansonsten erlaubte Zertifizierungsstellen, was für die meisten Domains eine sinnvolle zusätzliche Einschränkung ist, wenn keine Wildcard-Zertifikate im Einsatz sind.

Die Direktive iodef ermöglicht das Hinterlegen einer Kontaktadresse, an die Zertifizierungsstellen eine Meldung senden können, wenn eine Ausstellungsanfrage gegen den CAA-Record verstößt. Diese Meldungen liefern ein frühes Warnsignal für versuchte Fehlausstellungen und sollten an eine überwachte Adresse gehen, nicht an ein Postfach, das ohnehin niemand regelmäßig prüft.

6. Was DNSSEC nicht leistet: Grenzen und Missverständnisse

DNSSEC schützt ausschließlich die Integrität und Authentizität von DNS-Antworten, nicht die Vertraulichkeit der Anfrage selbst. Wer mithört, welche Domains ein Nutzer auflöst, kann das trotz DNSSEC weiterhin tun, da die Antworten im Klartext übertragen werden. Wer Vertraulichkeit benötigt, muss zusätzlich auf DNS-over-TLS oder DNS-over-HTTPS setzen, die ein anderes Problem lösen und DNSSEC nicht ersetzen, sondern ergänzen.

Außerdem schützt DNSSEC nur die DNS-Ebene selbst, nicht nachgelagerte Schritte wie die TLS-Verbindung zum aufgelösten Server oder eine kompromittierte Anwendung. Ein Angreifer, der bereits Zugriff auf den Server selbst hat, wird durch DNSSEC nicht aufgehalten, da die DNS-Antwort in diesem Fall korrekt und unverändert ist, das Ziel dahinter aber bereits kompromittiert wurde.

7. Was CAA nicht leistet: Grenzen der Zertifikatskontrolle

CAA-Records schützen nur vor Fehlausstellungen durch Zertifizierungsstellen, die sich an die CA/Browser-Forum-Regeln halten und den Record tatsächlich prüfen. Eine bösartige oder kompromittierte Zertifizierungsstelle, die die Prüfung bewusst ignoriert, wird durch einen CAA-Record technisch nicht aufgehalten, auch wenn ein solcher Regelverstoß inzwischen schwerwiegende Konsequenzen für die Zertifizierungsstelle selbst nach sich zieht, bis hin zum Vertrauensentzug durch große Browser-Hersteller.

Bereits ausgestellte Zertifikate bleiben von einem nachträglich gesetzten CAA-Record unberührt: Der Record wirkt ausschließlich zum Zeitpunkt einer neuen Ausstellung oder Verlängerung, nicht rückwirkend. Wer den Verdacht hat, dass bereits ein unautorisiertes Zertifikat existiert, muss dieses aktiv über Certificate-Transparency-Logs aufspüren und gegebenenfalls den Widerruf bei der ausstellenden Stelle beantragen, CAA allein löst dieses Problem nicht.

8. Häufige Fehlkonfigurationen und wie DNSSEC-Breakage entsteht

Der gravierendste Fehler bei DNSSEC ist eine unterbrochene Vertrauenskette, umgangssprachlich DNSSEC-Breakage genannt: Stimmt der beim Registrar hinterlegte DS-Record nicht mehr mit dem aktuellen Key Signing Key der Zone überein, etwa nach einer unvollständigen Schlüsselrotation oder einem Providerwechsel ohne Aktualisierung des DS-Records, verwirft jeder validierende Resolver sämtliche Antworten der Zone als ungültig. Die Domain wird dadurch für alle Nutzer hinter validierenden Resolvern faktisch unerreichbar, ein deutlich schwerwiegenderer Ausfall als ein fehlendes DNSSEC überhaupt.

Bei CAA-Records liegt der häufigste Fehler in einer zu restriktiven oder veralteten Konfiguration, die die tatsächlich genutzte Zertifizierungsstelle nicht mehr enthält, etwa nach einem Wechsel von einer kommerziellen CA zu Let's Encrypt ohne Anpassung des CAA-Records. Die nächste Zertifikatserneuerung schlägt dann fehl, oft erst bemerkt, wenn das alte Zertifikat bereits abläuft, weshalb CAA-Records bei jedem CA-Wechsel als fester Schritt in der Migrations-Checkliste stehen sollten.

9. DNSSEC und CAA als sich ergänzende Bausteine einer DNS-Sicherheitsstrategie

DNSSEC und CAA adressieren unterschiedliche Phasen derselben Vertrauenskette: DNSSEC sichert ab, dass eine DNS-Antwort tatsächlich vom autoritativen Server stammt und nicht unterwegs gefälscht wurde, während CAA absichert, wer überhaupt Zertifikate für die Domain ausstellen darf, sobald eine Zertifizierungsstelle die Domainvalidierung durchführt. Beide Maßnahmen zusammen erschweren einem Angreifer sowohl das Fälschen von DNS-Antworten als auch das Erschleichen eines gültigen Zertifikats erheblich.

Keine der beiden Maßnahmen ersetzt die andere, und keine ersetzt weitere Bausteine wie HTTP Strict Transport Security oder ein sauberes Monitoring der ausgestellten Zertifikate über Certificate-Transparency-Logs. Wer DNSSEC und CAA gemeinsam einsetzt und beide regelmäßig auf Konsistenz prüft, schließt zwei der praktisch relevantesten DNS-basierten Angriffsvektoren, ohne dabei den restlichen Sicherheits-Stack zu vernachlässigen.

10. Zusammenfassung

11. FAQ: DNSSEC und CAA-Records: Das Wichtigste auf einen Blick