DNS

CAA-Record im DNS verständlich erklärt: Zertifikats-Sicherheit

Zuletzt aktualisiert: 21. Juni 2026

Der CAA-Record (kurz für Certification Authority Authorization, RFC 6844, aktualisiert durch RFC 8659) ist ein wichtiger Sicherheits-Eintrag im Domain Name System. Er ermöglicht es Domaininhabern festzulegen, welche Zertifizierungsstellen (Certificate Authorities, CAs) berechtigt sind, SSL/TLS-Zertifikate für ihre Domain auszustellen. Dies verhindert, dass Cyberkriminelle unbemerkt betrügerische Zertifikate für Ihre Domain bei einer anderen, weniger streng kontrollierten CA beantragen (Man-in-the-Middle-Schutz).

Seit September 2017 ist die Überprüfung dieses Records für alle CAs vor jeder Zertifikatsausstellung gesetzlich vorgeschrieben. CAA-Records sind somit ein unverzichtbares Werkzeug für die Absicherung Ihrer HTTPS-Infrastruktur. Der Eintrag wird wie ein TXT-Record als Text in der Zone hinterlegt, entfaltet seine Wirkung aber nur in Kombination mit einer sauberen DNS-Hierarchie und idealerweise DNSSEC.

Das Sicherheitsrisiko ohne CAA

Zertifizierungsstellen validieren die Domaininhaberschaft meist über automatisierte Verfahren (z. B. durch das Platzieren einer temporären Datei auf dem Webserver oder das Eintragen eines temporären TXT-Records im DNS). Kompromittiert ein Angreifer kurzzeitig Ihren DNS-Server oder Ihren Web-Traffic (z. B. über BGP-Hijacking oder DNS-Cache-Poisoning), kann er bei einer beliebigen CA ein gültiges SSL-Zertifikat für Ihre Domain erzeugen lassen.

Mit dem Zertifikat ist der Angreifer in der Lage, verschlüsselten Traffic Ihrer Nutzer abzufangen und zu entschlüsseln (Man-in-the-Middle-Angriff), ohne dass der Browser eine Sicherheitswarnung anzeigt.

Der CAA-Record schränkt diese Gefahr drastisch ein. Selbst wenn der Angreifer die Inhaberschaft beweisen kann, verweigert die CA die Ausstellung des Zertifikats, wenn sie nicht im CAA-Record der Domain eingetragen ist.

Aufbau und Syntax eines CAA-Records

Ein CAA-Eintrag in einer DNS-Zonendatei besteht aus einem Flag, einer Eigenschaft (Tag) und dem Wert (Value) in Anführungszeichen:

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

Die drei Komponenten:

1. Flag (`0` bis `255`)

Das Flag steuert das Verhalten der CA bei unbekannten Tags. Aktuell ist nur das Bit 0 (Wert 128) standardisiert:

0 (Standard): Unkritisch. Erkennt die CA das Tag nicht, darf sie den Eintrag ignorieren und das Zertifikat dennoch ausstellen.
128 (Kritisch): Erkennt die CA das Tag nicht (oder kann es nicht verarbeiten), muss sie den Ausstellungs-Prozess sofort abbrechen.

2. Tag (Eigenschaft)

Bestimmt die Art der Regel:

issue: Autorisiert eine CA, reguläre (und optional Wildcard-) Zertifikate für die Domain auszustellen.
issuewild: Autorisiert eine CA, ausschliesslich Wildcard-Zertifikate (z. B. für *.example.com) auszustellen. Dieser Tag hat Vorrang vor issue bei Wildcard-Anfragen.
iodef (Incident Object Description Exchange Format): Definiert eine Kontaktmöglichkeit (E-Mail oder URL), an die CAs Berichte senden müssen, wenn unberechtigte Zertifikatsanfragen für Ihre Domain eingehen.

3. Wert (Value)

Die Domain der autorisierten Zertifizierungsstelle (z. B. "letsencrypt.org", "digicert.com", "sectigo.com").

Das Semikolon (;) im Wert signalisiert: Keine CA darf Zertifikate ausstellen. Der Eintrag 0 issuewild ";" verbietet somit allen CAs weltweit das Ausstellen von Wildcard-Zertifikaten für Ihre Domain.

Die Tags im Überblick

Tag	Wirkung	Typischer Wert
`issue`	erlaubt einer CA reguläre (und ohne `issuewild` auch Wildcard-) Zertifikate	`"letsencrypt.org"`
`issuewild`	erlaubt einer CA nur Wildcard-Zertifikate; hat Vorrang vor `issue`	`"digicert.com"`
`iodef`	Meldekanal für unberechtigte Anfragen	`"mailto:security@example.com"`
Wert `";"`	verbietet allen CAs die Ausstellung	`0 issue ";"`

Die DNS-Hierarchie: Parent Zone Climbing

CAs prüfen die CAA-Einträge hierarchisch von der Subdomain aufwärts zur Root-Domain. Wenn ein Zertifikat für sub.deep.example.com beantragt wird, sucht die CA in folgender Reihenfolge nach CAA-Records:

sub.deep.example.com
deep.example.com
example.com

Sobald der erste CAA-Record gefunden wird, stoppt die CA die Suche und wendet diese Regeln an – auch wenn auf höheren Ebenen andere Regeln definiert sind. Werden keine Einträge gefunden, ist die Ausstellung standardmässig für alle CAs erlaubt.

Falsch vs. richtig: Typische Fehlkonfigurationen

Gerade beim CAA-Record führen kleine Syntaxfehler dazu, dass die automatische Zertifikatserneuerung (z. B. via ACME/Let’s Encrypt) plötzlich scheitert:

Problem	Falsch	Richtig
Tippfehler im CA-Namen	`0 issue "letsencrypt.com"`	`0 issue "letsencrypt.org"`
Protokoll im Wert	`0 issue "https://letsencrypt.org"`	`0 issue "letsencrypt.org"`
Versehentliche Totalsperre	`0 issue ";"` (blockiert alles)	`0 issue "letsencrypt.org"`
Wildcard vergessen	nur `0 issue "letsencrypt.org"`, aber Wildcard angefragt	zusätzlich `0 issuewild "letsencrypt.org"`

Ein besonders heimtückischer Fall ist die vergessene Wildcard-Autorisierung: Die Erneuerung des Hauptzertifikats funktioniert, aber das Wildcard-Zertifikat für *.example.com schlägt fehl, weil bei Wildcard-Anfragen ausschliesslich der issuewild-Tag (bzw. ersatzweise issue) gilt.

Best Practice Konfigurationen

Szenario A: Ausschliesslich Let’s Encrypt erlauben

Für die meisten modernen Websites, die kostenlose, automatisierte Zertifikate nutzen:

example.com.   IN   CAA   0 issue "letsencrypt.org"

Szenario B: Let’s Encrypt für normale Seiten, DigiCert für Wildcards

Ideal, wenn die Root-Domain automatisiert validiert wird, Wildcards aber über ein Enterprise-Konto laufen:

example.com.   IN   CAA   0 issue "letsencrypt.org"
example.com.   IN   CAA   0 issuewild "digicert.com"

Szenario C: Wildcard-Zertifikate komplett verbieten

Sicherheitsmassnahme, um zu verhindern, dass Subdomains unkontrolliert erstellt werden:

example.com.   IN   CAA   0 issue "letsencrypt.org"
example.com.   IN   CAA   0 issuewild ";"

CAA und DNSSEC: Das perfekte Sicherheits-Duo

Ein CAA-Record ist am effektivsten, wenn die DNS-Zone mit DNSSEC (DNS Security Extensions) kryptografisch signiert ist. CAs sind verpflichtet, DNSSEC-Signaturen bei der Abfrage von CAA-Records zu prüfen. Ist DNSSEC aktiv, kann die CA sicherstellen, dass die CAA-Einträge auf dem Transportweg nicht manipuliert wurden.

CAA-Records abfragen

Sie können die CAA-Konfiguration einer Domain mit einfachen Terminal-Befehlen prüfen:

Mit dig (Linux/macOS):

dig CAA allerate.com +short

Mit nslookup (Windows):

nslookup -type=CAA allerate.com

Praxisbeispiel: CAA für ein Unternehmen mit Wildcard

Ein Unternehmen betreibt seine Hauptseite über Let’s Encrypt, nutzt für interne Wildcard-Subdomains aber ein DigiCert-Enterprise-Konto und möchte zusätzlich über Missbrauch informiert werden:

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

Wirkung: Reguläre Zertifikate dürfen nur über Let’s Encrypt laufen, Wildcards nur über DigiCert. Versucht eine dritte CA, ein Zertifikat auszustellen, bricht sie ab und meldet den Vorfall an die hinterlegte Adresse.
Empfehlung: Kombinieren Sie diese Konfiguration mit einer kurzen TTL während der Testphase und einer signierten Zone, damit die Einträge auf dem Transportweg nicht manipuliert werden können.

[!TIP] Der CAA-Record ist eine einfache und äusserst effektive Schutzmassnahme zur Absicherung Ihrer HTTPS-Infrastruktur. Prüfen Sie Ihre CAA-Einträge im Handumdrehen mit dem DNS Check auf balou.tools. Eine Übersicht über weitere praktische Werkzeuge finden Sie in den Developer Tools.

Häufig gestellte Fragen (FAQ)

Ist die Überprüfung von CAA-Records für Zertifizierungsstellen Pflicht?

Ja. Seit September 2017 sind alle offiziell anerkannten Zertifizierungsstellen (CAs) durch das CA/Browser Forum verpflichtet, vor der Ausstellung eines SSL-Zertifikats die CAA-Records der entsprechenden Domain abzufragen.

Was passiert, wenn für eine Domain kein CAA-Record existiert?

Ist kein CAA-Record vorhanden, darf jede beliebige Zertifizierungsstelle (z. B. Let’s Encrypt, Sectigo, DigiCert) ein Zertifikat für Ihre Domain ausstellen, sofern die Inhaberschaft über andere Verfahren (wie HTTP- oder DNS-Challenges) nachgewiesen wird.

Wie lange dauert es, bis eine Änderung am CAA-Record wirksam wird?

Die Wirksamkeit hängt von der TTL des Records ab. CAs fragen den CAA-Record stets frisch beim Ausstellen ab, doch zwischengespeicherte Werte bei Resolvern können bis zum Ablauf der TTL gültig bleiben. Planen Sie Änderungen daher mit einigen Stunden Vorlauf, bevor Sie ein Zertifikat bei einer neu autorisierten CA beantragen.

Blockiert ein CAA-Record auch bereits ausgestellte Zertifikate?

Nein. Der CAA-Record wirkt ausschliesslich zum Zeitpunkt der Neuausstellung oder Erneuerung eines Zertifikats. Bereits gültige Zertifikate einer nicht (mehr) autorisierten CA bleiben bis zu ihrem Ablaufdatum gültig und müssten zum Entzug aktiv widerrufen (revoked) werden.