DNS-Sicherheit: DNSSEC und CAA richtig einsetzen

Welche Probleme DNSSEC und CAA lösen

DNSSEC schützt Herkunft und Integrität signierter DNS-Datensatzmengen. Ein validierender Resolver kann damit passende Antworten und auch abgesicherte Aussagen über die Nichtexistenz eines Namens oder Datensatztyps prüfen. CAA wirkt an einer anderen Stelle: Es hilft, die zulässige Ausstellung von Zertifikaten einzuschränken. Der Browser behandelt CAA nicht als zusätzliche laufende Zertifikatsprüfung.

Ohne DNSSEC fehlt dieser kryptografische Herkunftsnachweis. Das bedeutet nicht, dass jeder Angreifer beliebig einen DNS-Cache vergiften kann oder dass eine Umleitung automatisch die TLS-Prüfung umgeht. Beim von Cloudflare beschriebenen MyEtherWallet-Vorfall 2018 wurden DNS-Anfragen durch eine BGP-Umleitung fehlgeleitet. Die fremde HTTPS-Seite lieferte ein nicht vertrauenswürdiges Zertifikat; Nutzer mussten die Warnung übergehen. Der Fall zeigt das Zusammenspiel unterschiedlicher Schutzgrenzen, keine Garantie einer einzelnen Maßnahme. Cloudflare-Bericht

Auch eine signierte Zone kann falsche, aber vom berechtigten Schlüssel signierte Daten enthalten, etwa nach einem kompromittierten Administrationskonto. DNSSEC ersetzt deshalb weder Kontoschutz und Delegationspflege noch sicheren Webbetrieb.

DNSSEC: RRsets, Vertrauenskette und Resolver

DNSSEC signiert RRsets: zusammengehörige Datensätze gleichen Namens, Typs und derselben Klasse. Es signiert nicht einfach jedes DNS-Paket. Die wichtigsten Bausteine sind:

Ein Validator folgt den Beziehungen zwischen Datensatz, Signatur, Zonenschlüssel und übergeordneter Delegation bis zu einem Vertrauensanker. Eine registrierbare Domain ist dabei nicht zwangsläufig die Grenze jeder darunter betriebenen DNS-Zone. Delegierte Unterzonen besitzen einen eigenen Übergang. RFC 4033, §§ 3–5, RFC 9364

Für die Bewertung sind vier Zustände hilfreich: secure für erfolgreich validierte Daten, insecure für einen nachvollziehbar nicht abgesicherten Zweig, bogus für gescheiterte erwartete Validierung und indeterminate für fehlende Entscheidungsgrundlage. Ein Resolverfehler allein unterscheidet diese Ursachen nicht vollständig. SERVFAIL kann etwa auf eine kaputte DNSSEC-Kette, aber auch auf andere Auflösungsprobleme hinweisen.

Das AD-Bit ist eine Aussage des Resolvers

Ein AD-Signal teilt mit, dass der antwortende Resolver die relevanten Daten als authentisch beurteilt hat. Wer selbst nicht validiert, darf sich darauf nur mit Vertrauen in den Resolver und den Übertragungsweg stützen. Ein beliebiges UDP-Paket mit gesetztem AD-Bit ist kein unabhängiger kryptografischer Beweis. Das DO-Bit einer Anfrage bittet um DNSSEC-Daten; es validiert sie nicht selbst. RFC 4035, §§ 3.2.3 und 4.9.3

AD bezieht sich auf die betreffende Antwort, nicht auf alle Namen und Dienste einer Domain. Auch eine authentifizierte negative Antwort kann AD tragen. Ein AD-Befund bestätigt daher nicht automatisch die Existenz eines A-Records oder die Erreichbarkeit der Website. Fehlt AD, sind unter anderem eine nicht signierte Antwort, Resolververhalten, Aliasse und eine unvollständig prüfbare Kette auseinanderzuhalten.

DNSSEC verschlüsselt DNS nicht

DNSSEC bietet keine Vertraulichkeit der Abfragen. DNS over HTTPS oder DNS over TLS schützen einen Transportweg, etwa zum gewählten Resolver; sie ersetzen dessen DNSSEC-Validierung und Vertrauenswürdigkeit nicht. Ebenso wenig garantiert DNSSEC Verfügbarkeit oder schützt jedes Registrar-, Hosting- und DNS-Konto. Diese Aufgaben ergänzen sich.

DNSSEC sicher einführen und ändern

Zuständig sind der autoritative DNS-Betreiber für die signierte Zone und meist der Registrar für den DS-Eintrag in der Elternzone. Das können verschiedene Unternehmen und Bedienoberflächen sein. Ermitteln Sie die tatsächlichen Nameserver und Zuständigkeiten, bevor Sie Schalter verändern.

1. Prüfen Sie die Unterstützung für Signierung, Schlüsselverwaltung und DS-Veröffentlichung. Legen Sie Zuständigkeit, Überwachung und Wiederherstellung fest.
2. Bereiten Sie eine konsistent signierte Zone auf den autoritativen Servern vor. Kontrollieren Sie Schlüssel, Signaturen, Zeitsynchronisation und Antworten.
3. Veröffentlichen Sie erst dann die dazu passenden DS-Daten über den zuständigen Weg. Ein falscher oder zu früh gesetzter DS-Eintrag kann Auflösung für validierende Resolver verhindern.
4. Prüfen Sie die Kette aus Sicht vertrauenswürdiger Validatoren. Berücksichtigen Sie vorhandene Caches, TTLs und delegierte Unterzonen.
5. Überwachen Sie Signaturablauf, Schlüsselwechsel und Fehler. Eine einmal erfolgreiche Aktivierung ist kein dauerhafter Betriebsnachweis.

Bei der verbreiteten Trennung signiert ein KSK das DNSKEY-RRset und ein ZSK die übrigen Zonendaten. Kombinierte Schlüsselmodelle sind ebenfalls möglich. Ein KSK-Wechsel kann Anpassungen der übergeordneten DS-Verknüpfung erfordern; der konkrete Ablauf hängt vom Verfahren ab. Pauschale Intervalle wie „ZSK alle ein bis drei Monate, KSK alle ein bis zwei Jahre“ ersetzen keinen abgestimmten Plan. Managed DNS bedeutet auch nicht automatisch, dass der Registrar jeden Übergang korrekt mitvollzieht.

Ein Providerwechsel ist ein eigener Ablauf mit Delegation, Schlüsseln, Signaturen und Cachezeiten. Bei geplanter Abschaltung darf keine noch wirksame DS-Verknüpfung auf bereits unsignierte Daten zeigen. Im einfachen Rückbau muss deshalb zunächst die DS-Verknüpfung entfernt und ihr Auslaufen aus relevanten Caches berücksichtigt werden, bevor die Signierung endet. Ein geplanter Übergang ohne Unterbrechung der Absicherung braucht ein dafür geeignetes Verfahren beider Betreiber. Im Fehlerfall ist das Wiederherstellen der passenden Kette oft der bessere Weg als unkoordiniertes Abschalten. RFC 6781, §§ 4.1–4.4

Algorithmen nach aktuellem Stand wählen

RFC 9904 hat RFC 8624 abgelöst und die maßgeblichen Implementierungs- und Nutzungsempfehlungen in die IANA-Registries verlagert. Beim ausgewerteten Stand sind etwa ECDSA P-256/SHA-256 (13), Ed25519 (15) und RSA/SHA-256 (8) für DNSSEC-Signierung empfohlen. Das ist keine universelle Anweisung, eine funktionierende Zone ohne Migrationsplan auf Algorithmus 13 umzuschalten. Unterstützte Verfahren, Paketgrößen, Betriebswerkzeuge und sichere Übergänge gehören zur Auswahl. Allgemeine Behauptungen über die Defaults aller großen Anbieter oder eine pauschale Ablösung sämtlicher RSA-Verfahren sind dafür keine belastbare Grundlage. RFC 9904, IANA-Registry

CAA: Zulässige Zertifikatsaussteller festlegen

Eine CAA-verarbeitende CA ermittelt vor der Ausstellung das maßgebliche RRset für jeden beantragten Namen. Bei Wildcards beginnt die Prüfung am Namen ohne *.. Die Auflösung berücksichtigt Aliasse und sucht erforderlichenfalls bei übergeordneten Namen weiter. Die Suche endet beim ersten maßgeblichen CAA-RRset; beliebige Listen aller Eltern werden nicht zusammenaddiert. Eine leere Hostabfrage ist deshalb noch kein Beweis, dass keine einschränkende Regel existiert. Ein Abfragefehler ist erst recht kein solcher Beweis. RFC 8659, § 3

Ein Beispiel für eine bewusst gewählte Kombination, keine allgemeine Anbieterempfehlung:

example.com. 3600 IN CAA 0 issue "letsencrypt.org"
example.com. 3600 IN CAA 0 issue "digicert.com"
example.com. 3600 IN CAA 0 issuewild "letsencrypt.org"
example.com. 3600 IN CAA 0 iodef "mailto:security@example.com"

Hier sind für normale Namen die beiden genannten Aussteller vorgesehen; für Wildcards nur Let's Encrypt. Die Angaben müssen zu allen tatsächlich eingesetzten Zertifikatsdiensten passen, auch beim CDN und bei automatischen Erneuerungen. Entfernen Sie nicht versehentlich den Aussteller einer benötigten Reserve- oder Hostinglösung.

issue ";" kann als alleinige passende issue-Regel die Ausstellung untersagen. Es ist aber kein absolutes Veto neben einer anderen passenden issue-Autorisierung: Solche Erlaubnisse sind additiv. Außerdem braucht eine gesonderte issuewild-Regel eine eigene Beurteilung. Eine reine iodef-Konfiguration schränkt die Aussteller nicht ein. Diese Gegenfälle sind wichtiger als die bloße Anzahl gefundener CAA-Einträge. RFC 8659, §§ 4.1–4.5

Gängige dokumentierte Kennungen sind letsencrypt.org, digicert.com, sectigo.com und globalsign.com. Prüfen Sie den konkreten Zertifikatsdienst und eventuelle Parameter anhand seiner aktuellen Dokumentation, statt dessen Produktnamen als CAA-Wert zu raten. Let's Encrypt, DigiCert, Sectigo, GlobalSign

CAA kontrolliert die Ausstellung, widerruft aber keine bereits ausgestellten Zertifikate und ersetzt weder Domainvalidierung noch Schlüsselpflege. Seine Wirkung hängt davon ab, dass der Aussteller die Regeln korrekt verarbeitet. DNSSEC kann auch CAA-Daten absichern, wenn die passende Vertrauenskette und Validierung bestehen. Beide Verfahren sind dennoch unabhängig einsetzbar.

Befunde gezielt nachprüfen

Diese diagnostischen Abfragen sind Beispiele für die eigene Domain:

dig +dnssec www.example.com A
dig example.com DS
dig example.com DNSKEY
dig www.example.com CAA
dig example.com CAA

dig +dnssec ist kein selbstständiger Vollvalidator. Notieren Sie angefragten Namen, Typ, Resolver, Status, AD, Zeitpunkt und Aliasse. Bei einem Fehler klären Sie, ob er vom Resolver, von einer Delegation, fehlenden Signaturen oder der Erreichbarkeit stammt. Vergleichen Sie bei Bedarf die autoritativen Antworten und einen kontrollierten validierenden Resolver. Das vorübergehende Abschalten der Prüfung ist kein Nachweis einer funktionierenden DNSSEC-Konfiguration.

Für CAA zählen auch Zwischenknoten und Aliasziele, die obige kurze Befehlsliste nicht vollständig abdeckt. Ein sicherer Betriebstest prüft zusätzlich eine geplante Zertifikatsausstellung beziehungsweise Erneuerung im Verfahren des eingesetzten Anbieters. Keine unnötigen echten Zertifikate nur zur Erhöhung eines Scannerwerts bestellen.

Der tatsächliche Messumfang von Wolf-Agents

Der Web Security Check analysiert im geprüften Stand den angefragten Host. Das ist vom finalen Host nach einer Webseitenweiterleitung zu unterscheiden:

Resolver- und unvollständige CAA-Ergebnisse können als nicht zuverlässig prüfbar markiert sein. Das ist keine Aussage „sicher nicht vorhanden“. Ein erkannter DS-Datensatz belegt für sich keine gültige Kette. Ein ausgegebener Algorithmusname stammt aus den gelesenen Daten und bestätigt weder Schlüsselstärke noch jede Signatur.

Der Transport nutzt je nach Konfiguration den eigenen Resolver oder einen HTTPS-Resolver als begrenzten Fallback. Seine Herkunft ist relevant. Ein AD: true zählt nur, wenn die Resolverangaben eine angeforderte, nicht per Checking Disabled abgeschaltete Validierung über einen vertrauenswürdigen Kanal ausweisen. Fehlen diese Angaben oder sind sie negativ, gilt das Ergebnis als Messlücke ohne Validierungsbonus, nicht als DNSSEC-Fehler der Domain; ältere gespeicherte Ergebnisse werden dabei nicht neu bewertet. Der Befund ist daher ausdrücklich als Resolverbeobachtung zu lesen. Ein vollständiger DNS-Betriebsaudit, DNSSEC-Prüfung beim Besucher, Kontoschutz oder laufende Überwachung wird damit nicht ausgeführt.

Rechtliche und normative Bezüge mit ihrem Geltungsbereich

DNS-Sicherheit kann Teil angemessener technischer und organisatorischer Maßnahmen sein. Daraus folgt keine allgemeine gesetzliche DNSSEC- oder CAA-Pflicht für jede Website. Für erfasste Einrichtungen verlangt § 30 BSIG geeignete, verhältnismäßige und wirksame Maßnahmen. § 38 betrifft deren Geschäftsleitungen; Haftung folgt den dort genannten Voraussetzungen und Regeln, nicht einem einzelnen fehlenden DNS-Eintrag. § 30 BSIG, § 38 BSIG

Der einschlägige BSI-Grundschutzbaustein ist APP.3.6 DNS-Server, nicht APP.3.9. Seine Edition 2023 enthält unter A17 eine Standard-Anforderung mit „SOLLTE“ zum DNSSEC-Einsatz auf auflösenden und autoritativen DNS-Servern sowie zum Schlüsselwechsel. Ob und wie sie im jeweiligen Informationsverbund anzuwenden ist, folgt aus Modellierung, Anwendungsbereich und Prüfverfahren; eine einzelne Websiteabfrage belegt keine BSI-Zertifizierung. BSI APP.3.6, A17

Die ENISA-Leitlinie zur Durchführungsverordnung (EU) 2024/2690 nennt DNSSEC unter den zu berücksichtigenden DNS-Sicherheitspraktiken. Sie richtet sich an bestimmte Einrichtungsarten, darunter DNS-, Cloud- und weitere digitale Dienstleister; daraus wird keine pauschale Vorschrift für jeden Domaininhaber. Ebenso verlangt Art. 32 DSGVO eine risikobezogene Auswahl geeigneter Maßnahmen, keine universelle Kombination dieser zwei DNS-Einstellungen. Weiterführend: ENISA-Leitlinie, Compliance-Ratgeber, NIS2-Checkliste für Deutschland und Geschäftsleitungsverantwortung in Deutschland. Andere nationale Zusammenhänge ordnet die Länderübersicht ein.