DANE (DNS-based Authentication of Named Entities)

DANE (DNS-based Authentication of Named Entities) ist ein in RFC 6698 spezifiziertes Verfahren, das TLS-Zertifikate über das Domain Name System verifiziert. Anstatt sich ausschließlich auf das Vertrauen in Zertifizierungsstellen (Certificate Authorities) zu verlassen, veröffentlicht der Domaininhaber den Fingerabdruck oder den öffentlichen Schlüssel seines TLS-Zertifikats als TLSA-Record im DNS. Voraussetzung ist eine funktionierende DNSSEC-Infrastruktur, die die Integrität des TLSA-Records kryptografisch absichert.

Das Problem: Opportunistisches STARTTLS

Die meisten Mailserver unterstützen heute STARTTLS, um E-Mails verschlüsselt zu transportieren. Diese Verschlüsselung ist jedoch rein opportunistisch: Wenn ein Angreifer die STARTTLS-Aushandlung zwischen zwei Mailservern unterdrückt, fällt die Verbindung stillschweigend auf unverschlüsselten Klartext zurück. Selbst wenn TLS zustande kommt, prüft der sendende Server bei opportunistischem STARTTLS in der Regel nicht, ob das Zertifikat des Empfängers gültig ist — er akzeptiert jedes beliebige Zertifikat, weil er keine Möglichkeit hat, das korrekte zu kennen.

DANE schließt beide Lücken: Durch den TLSA-Record weiß der sendende Server, welches Zertifikat er erwarten muss. Stimmt das vorgelegte Zertifikat nicht überein oder unterstützt der Empfänger kein TLS, verweigert der sendende Server die Zustellung, statt auf Klartext zurückzufallen.

TLSA-Record: Aufbau und Felder

Ein TLSA-Record wird unter _25._tcp.mx.example.de im DNS veröffentlicht und besteht aus vier Feldern. Das Certificate Usage Field definiert das Vertrauensmodell — der Wert 3 (DANE-EE) bindet das Zertifikat direkt an den DNS-Record und ist für Mailserver am gebräuchlichsten. Das Selector Field gibt an, ob das vollständige Zertifikat (0) oder nur der öffentliche Schlüssel (1) geprüft wird. Das Matching Type Field bestimmt die Hash-Methode: 1 für SHA-256, 2 für SHA-512. Das vierte Feld enthält den eigentlichen Fingerabdruck.

Die Wahl des Selectors hat praktische Konsequenzen: Wird der öffentliche Schlüssel referenziert, muss der TLSA-Record bei einer Zertifikatserneuerung nur dann aktualisiert werden, wenn sich der Schlüssel selbst ändert. Bei einer reinen Verlängerung mit demselben Schlüssel bleibt der Record gültig — das reduziert den operativen Aufwand erheblich.

DNSSEC als zwingende Voraussetzung

DANE ohne DNSSEC bietet keinen Sicherheitsgewinn. Die gesamte Vertrauenskette basiert darauf, dass der TLSA-Record im DNS authentisch und nicht manipuliert ist. Ohne DNSSEC könnte ein Angreifer, der DNS-Antworten manipulieren kann, auch den TLSA-Record fälschen und sein eigenes Zertifikat einschleusen. DNSSEC signiert alle DNS-Antworten kryptografisch und ermöglicht dem anfragenden Server die Verifizierung über die hierarchische Vertrauenskette von der Root-Zone bis zur einzelnen Domain.

Diese Abhängigkeit ist zugleich die größte Stärke und die größte Hürde von DANE. Die Stärke: Das Vertrauen basiert auf Kryptografie und DNS-Hierarchie, nicht auf der Integrität von Zertifizierungsstellen. Die Hürde: In Deutschland hat nur ein geringer Anteil der .de-Domains DNSSEC aktiviert, was die Verbreitung von DANE einschränkt.

DANE vs. MTA-STS

Neben DANE gibt es mit MTA-STS (RFC 8461) ein alternatives Verfahren zur Absicherung der SMTP-Transportverschlüsselung. MTA-STS nutzt eine HTTPS-basierte Policy-Datei und das klassische CA-Vertrauensmodell statt DNSSEC. Es ist einfacher zu implementieren, bietet aber ein schwächeres kryptografisches Fundament. In der Praxis empfiehlt sich die parallele Implementierung beider Verfahren: DANE für Mailserver, die DNSSEC-validierend arbeiten, und MTA-STS als Fallback für alle anderen. Mit dem MTA-STS-Check können Sie prüfen, ob Ihre Domain auch diese Alternative implementiert hat.

Verbreitung und regulatorische Relevanz

DANE hat vor allem in Nordeuropa signifikante Verbreitung erreicht. In den Niederlanden, Dänemark und Schweden setzen Behörden DANE flächendeckend für die E-Mail-Kommunikation ein. In Deutschland empfiehlt das BSI DANE-TLSA in seinen technischen Richtlinien als Maßnahme für sichere E-Mail-Kommunikation. Unter der NIS2-Richtlinie müssen betroffene Unternehmen angemessene technische Maßnahmen für die Sicherheit ihrer Kommunikation implementieren — DANE kann hier als Nachweis für den Stand der Technik dienen.

Deutsche Mailprovider wie posteo.de und mailbox.org unterstützen DANE sowohl für eingehende als auch ausgehende E-Mails. Bei großen internationalen Providern wie Gmail und Microsoft variiert die DANE-Unterstützung — Google hat DANE-Validierung für ausgehende Mails eingeführt, während Microsoft primär auf MTA-STS setzt.

Praxistipp

Ob Ihre MX-Server DANE korrekt konfiguriert haben, prüfen Sie mit dem SMTP-TLS-Check. Das Tool analysiert die TLSA-Records, verifiziert die DNSSEC-Signatur und gleicht den hinterlegten Fingerabdruck mit dem tatsächlich ausgelieferten TLS-Zertifikat ab. Voraussetzung ist ein aktives DNSSEC — prüfbar mit dem DNSSEC-Check. Ergänzend empfiehlt sich der E-Mail Security Check, um sicherzustellen, dass auch SPF, DKIM und DMARC korrekt konfiguriert sind.