Was ist DANE? Zertifikatsbindung über DNSSEC einfach erklärt
Bei der verschlüsselten Zustellung von E-Mails zwischen zwei Mailservern stellt sich eine unbequeme Frage: Wie weiß der sendende Server eigentlich, dass er mit dem echten Zielserver spricht und nicht mit einem untergeschobenen Gegenüber? Protokolle wie STARTTLS verschlüsseln zwar, prüfen aber oft nicht, ob das vorgelegte Zertifikat überhaupt erwartet wird. Genau diese Lücke schließt DANE.
Dieser Guide erklärt verständlich, was DANE und der TLSA-Record sind, warum DNSSEC die Grundlage bildet, wie sich DANE von MTA-STS unterscheidet und wie Unternehmen die fälschungssichere Transportverschlüsselung einführen.
Was ist DANE?
TL;DR: DANE, kurz für DNS-based Authentication of Named Entities, ist für E-Mail in RFC 7672 beschrieben. Eine Domäne hinterlegt im DNS, welches TLS-Zertifikat ihr Mailserver verwendet. Ein sendender Server vergleicht das tatsächlich vorgelegte Zertifikat mit diesem Eintrag und stellt nur zu, wenn beide übereinstimmen. Damit der Eintrag nicht gefälscht werden kann, muss die DNS-Zone mit DNSSEC signiert sein.
DANE verbindet zwei Welten, die lange getrennt waren: das Domain Name System und die TLS-Zertifikate. Statt sich allein darauf zu verlassen, dass irgendeine Zertifizierungsstelle ein Zertifikat ausgestellt hat, sagt die Domäne über DANE direkt: Mein Mailserver verwendet genau dieses Zertifikat, prüfe es bitte. Ein Angreifer kann dann kein eigenes, gültig aussehendes Zertifikat unterschieben, weil es nicht zum hinterlegten Eintrag passt.
Wie MTA-STS sichert DANE den Transport zwischen Mailservern ab, nicht die Ende-zu-Ende-Verschlüsselung einzelner Nachrichten.
Warum reicht opportunistisches STARTTLS nicht aus?
STARTTLS verschlüsselt die Verbindung, akzeptiert dabei aber in der Praxis nahezu jedes Zertifikat. Daraus folgen zwei Probleme:
- Kein Zwang zur Verschlüsselung: Bietet die Gegenstelle kein TLS an oder entfernt ein Angreifer das Verschlüsselungssignal, fällt die Zustellung still auf Klartext zurück.
- Keine Identitätsprüfung: Selbst wenn verschlüsselt wird, bleibt offen, ob das Zertifikat wirklich zum erwarteten Server gehört. Ein Mittelsmann mit eigenem Zertifikat fällt nicht auf.
DANE beseitigt beide Probleme zugleich. Existiert ein TLSA-Record, ist Verschlüsselung Pflicht, und das Zertifikat muss exakt zur Vorgabe passen. Andernfalls wird nicht zugestellt.
Wie funktioniert DANE Schritt für Schritt?
Die Zertifikatsbindung läuft in vier Schritten ab:
Schritt 1, signierte Zone: Die DNS-Zone der Domäne wird mit DNSSEC signiert. Erst dadurch sind die folgenden Einträge fälschungssicher.
Schritt 2, TLSA-Record veröffentlichen: Unter einem Namen wie _25._tcp.mail.ihre-domain.de wird ein TLSA-Record hinterlegt. Er enthält einen Fingerabdruck des erwarteten Zertifikats sowie Parameter dazu, welcher Teil der Zertifikatskette geprüft wird.
Schritt 3, Lookup beim Versand: Ein sendender Server, der DANE unterstützt, fragt vor der Zustellung den TLSA-Record der Empfängerdomäne ab und stellt über DNSSEC sicher, dass die Antwort echt ist.
Schritt 4, Abgleich: Der Server vergleicht das beim TLS-Handshake vorgelegte Zertifikat mit dem TLSA-Record. Stimmt es überein, wird verschlüsselt zugestellt. Stimmt es nicht oder fehlt, wird die Zustellung verweigert.
Der TLSA-Record im Überblick
Der TLSA-Record beschreibt nicht das Zertifikat selbst, sondern wie es geprüft wird. Drei Parameter steuern das:
| Parameter | Bedeutung |
|---|
| Usage | Ob die Zertifizierungsstelle oder das Endzertifikat gebunden wird |
| Selector | Ob das ganze Zertifikat oder nur der öffentliche Schlüssel verglichen wird |
| Matching | Ob der vollständige Wert oder ein Hash hinterlegt ist |
Für Mailserver ist eine Bindung an den öffentlichen Schlüssel verbreitet, weil sie eine Erneuerung des Zertifikats erleichtert, solange der Schlüssel erhalten bleibt.
DANE und DNSSEC: die untrennbare Verbindung
DANE steht und fällt mit DNSSEC. Ohne signierte Zone könnte ein Angreifer die DNS-Antwort mit dem TLSA-Record fälschen und damit die Prüfung aushebeln. DNSSEC signiert die Antworten kryptografisch, sodass der sendende Server der Zertifikatsinformation vertrauen kann. Diese feste Kopplung ist zugleich der Grund, warum DANE nicht überall verfügbar ist: Eine Domäne ohne DNSSEC kann DANE nicht nutzen.
DANE oder MTA-STS?
DANE und MTA-STS lösen dasselbe Problem auf unterschiedliche Weise:
| Kriterium | DANE | MTA-STS |
|---|
| Vertrauensanker | DNSSEC und TLSA | Zertifizierungsstellen und HTTPS |
| Voraussetzung | Signierte DNS-Zone | Erreichbare HTTPS-Subdomäne |
| Erstkontakt | Sofort abgesichert | Vertrauen beim ersten Kontakt |
| Verbreitung | Stark bei Providern mit DNSSEC | Breite Plattformunterstützung |
Die beiden schließen sich nicht aus. Eine Domäne kann beide gleichzeitig anbieten und so unterschiedliche sendende Systeme erreichen. Genau das empfiehlt das BSI in der Technischen Richtlinie TR-03108.
DANE und Compliance: BSI TR-03108 und NIS2
Für sicheren E-Mail-Transport nennt die BSI Technische Richtlinie TR-03108 DANE als zentralen Baustein, neben MTA-STS und TLS-RPT. Über die NIS2-Richtlinie und § 30 BSIG wird gesicherte Kommunikation für viele Unternehmen zur Pflicht. DANE ist eine konkrete, technisch nachweisbare Maßnahme, die auf diese Anforderungen und auf den Stand der Technik nach Artikel 32 DSGVO einzahlt.
DANE mit Conbool MailGuard einrichten
DANE ist im Betrieb anspruchsvoll: DNSSEC muss aktiv sein, die TLSA-Records müssen exakt zum Zertifikat passen und vor allem darf eine Zertifikatserneuerung die Bindung nicht brechen. Wird der Schlüssel getauscht, ohne den TLSA-Record rechtzeitig anzupassen, bleiben E-Mails liegen. Conbool MailGuard übernimmt das in beide Richtungen: eingehend werden die TLSA-Records veröffentlicht und bei Schlüsselwechsel sicher rolliert, ausgehend prüft der Dienst die DANE-Bindung der Empfängerdomänen und protokolliert das Ergebnis.
Den aktuellen Stand einer Domäne zeigt der kostenlose Transportsicherheits-Check. Die Details zur verwalteten Lösung stehen auf der Seite zu DANE und TLSA.
Häufig gestellte Fragen zu DANE
Was ist DANE?
DANE steht für DNS-based Authentication of Named Entities. Eine Domäne hinterlegt im DNS Informationen über das erwartete TLS-Zertifikat ihres Mailservers. Ein sendender Server prüft das tatsächliche Zertifikat dagegen und stellt nur bei Übereinstimmung zu.
Was ist ein TLSA-Record?
Der TLSA-Record ist der DNS-Eintrag, über den DANE die Zertifikatsbindung veröffentlicht. Er enthält einen Fingerabdruck oder Verweis auf das erwartete Zertifikat sowie Parameter zur Prüfung. Die Zone muss dafür mit DNSSEC signiert sein.
Warum benötigt DANE zwingend DNSSEC?
Ohne DNSSEC ließe sich der TLSA-Record manipulieren und der Schutz wäre wertlos. DNSSEC signiert die DNS-Antworten kryptografisch, sodass die Zertifikatsinformation als echt gelten kann. DNSSEC ist daher die Vertrauensbasis von DANE.
Worin unterscheidet sich DANE von MTA-STS?
Beide erzwingen verschlüsselten Transport, vertrauen aber unterschiedlich. DANE bindet das Zertifikat über DNSSEC, MTA-STS stützt sich auf Zertifizierungsstellen und HTTPS. Das BSI empfiehlt in TR-03108 den parallelen Einsatz.
Schützt DANE eingehende oder ausgehende E-Mails?
Beides. Eingehend veröffentlicht eine Domäne TLSA-Records für ihr eigenes Zertifikat. Ausgehend prüft der eigene Mailserver die TLSA-Records der Empfängerdomänen. Conbool MailGuard deckt beide Richtungen ab.
Fazit
DANE bringt die fehlende Identitätsprüfung in den E-Mail-Transport. Über einen mit DNSSEC signierten TLSA-Record wird das erwartete Zertifikat verbindlich festgelegt, sodass weder ein stilles Downgrade noch ein untergeschobenes Zertifikat unbemerkt bleiben. Gemeinsam mit MTA-STS und TLS-RPT entsteht ein nachweisbarer Transportschutz, der den Empfehlungen des BSI und den Pflichten aus NIS2 entspricht.
Der nächste Schritt liegt bei Ihnen: Prüfen Sie Ihre Domäne mit dem Transportsicherheits-Check und sehen Sie, wie Conbool MailGuard DANE übernimmt.
Weiterführende Artikel:
