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, bindet TLS-Zertifikate direkt im DNS an eine Domäne. Der Kern ist in RFC 6698 standardisiert, für den E-Mail-Transport konkret in RFC 7672. Eine Domäne hinterlegt im DNS, welches Zertifikat ihr Server verwendet. Die Gegenstelle vergleicht das tatsächlich vorgelegte Zertifikat mit diesem Eintrag und akzeptiert die Verbindung nur bei Übereinstimmung. 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 Server 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.
DANE ist dabei nicht auf E-Mail beschränkt. Grundsätzlich lässt sich damit jedes Protokoll mit TLS absichern, von HTTPS bis SMTP. Der mit Abstand wichtigste Anwendungsfall ist jedoch der verschlüsselte Transport zwischen Mailservern, und darauf konzentriert sich dieser Guide.
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.
Ein konkreter TLSA-Record sieht zum Beispiel so aus: _25._tcp.mail.ihre-domain.de. IN TLSA 3 1 1 a1b2c3...e5f6. Die drei Zahlen entsprechen den Parametern aus der Tabelle: 3 bindet das Endzertifikat des Servers direkt, 1 prüft nur den öffentlichen Schlüssel und 1 hinterlegt ihn als SHA-256-Hash. Der lange Hexwert ist genau dieser Fingerabdruck. Ein sendender Server mit DANE-Unterstützung liest den Eintrag vor der Zustellung und vergleicht ihn mit dem Zertifikat aus dem TLS-Handshake.
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.
Vorteile, Grenzen und Verbreitung von DANE
Der große Vorteil von DANE ist die Unabhängigkeit von der öffentlichen Zertifikatswelt. Das Vertrauen liegt allein in der signierten DNS-Zone der Domäne, nicht in der Frage, ob eine von hunderten Zertifizierungsstellen kompromittiert wurde. Weil der TLSA-Record über DNSSEC bereits ab dem ersten Kontakt fälschungssicher prüfbar ist, gibt es zudem kein Zeitfenster blinden Erstvertrauens.
Diesen Stärken stehen klare Grenzen gegenüber. DANE setzt eine mit DNSSEC signierte Zone zwingend voraus, ohne DNSSEC ist es technisch ausgeschlossen. Im Betrieb erfordert es Sorgfalt, weil jede Zertifikatserneuerung den TLSA-Record brechen kann, wenn er nicht rechtzeitig mitgeführt wird. Und der Schutz greift nur, wenn auch die sendende Gegenstelle DANE auswertet.
Bei der Verbreitung zeigt sich ein geteiltes Bild. Stark vertreten ist DANE für den E-Mail-Transport bei Providern mit DNSSEC, vor allem im deutschen und europäischen Raum sowie im Behörden- und Forschungsumfeld, wo das BSI es für zertifizierte Diensteanbieter verlangt. Große internationale Freemail-Dienste unterstützen die ausgehende DANE-Prüfung zunehmend, veröffentlichen für ihre eigenen Domänen aber nicht immer TLSA-Records. Der Trend geht klar zu breiterer Nutzung, getrieben von Regulatorik wie NIS2 und den BSI-Richtlinien.
DANE einordnen: MTA-STS-Vergleich und Pflicht-Frage
Zwei Fragen tauchen rund um DANE fast immer auf. Beide haben einen eigenen, ausführlichen Beitrag.
DANE oder MTA-STS? MTA-STS verfolgt dasselbe Ziel wie DANE, leitet sein Vertrauen aber aus öffentlichen Zertifizierungsstellen und HTTPS statt aus DNSSEC ab. Beide schließen sich nicht aus, das BSI empfiehlt sogar den parallelen Betrieb. Den vollständigen Abgleich mit Entscheidungshilfe liefert der Vergleich MTA-STS oder DANE.
Ist DANE Pflicht? Namentlich gesetzlich vorgeschrieben ist DANE nicht. Über die BSI-Richtlinie TR-03108, die NIS2-Umsetzung und § 30 BSIG wird nachweisbare Transportverschlüsselung für viele Organisationen aber faktisch verpflichtend. Die Pflicht-Frage samt Rechtslage klärt der Beitrag DANE und BSI TR-03108.
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:
