So funktioniert’s
DANE (RFC 6698, für SMTP RFC 7672) legt den erwarteten Schlüssel eines Servers im DNS ab, statt sich allein auf Zertifizierungsstellen zu verlassen. Für Mailserver steht der TLSA-Record unter _25._tcp und dem Namen des MX-Hosts, also etwa _25._tcp.mail.example.com, und gilt für Port 25.
Ein typischer Eintrag lautet 3 1 1 gefolgt von 64 Hex-Zeichen. Die erste Zahl ist die Usage: 3 (DANE-EE) heißt „genau dieser Schlüssel“, 2 (DANE-TA) „ein Zertifikat dieser ausstellenden Stelle“. Die zweite Zahl wählt den öffentlichen Schlüssel (1) statt des ganzen Zertifikats (0), die dritte das Hashverfahren, hier SHA-256 (1). Die Usages 0 und 1 sind für SMTP nicht vorgesehen.
Wirksam ist DANE nur mit DNSSEC, denn ohne Signatur ließe sich der TLSA-Record genauso fälschen wie die Verbindung. Ein validierender Absender wie Posteo oder mailbox.org fragt den TLSA-Record ab, baut die Verbindung per STARTTLS auf und liefert nur aus, wenn das Zertifikat passt. Anders als MTA-STS braucht DANE keinen Webserver und schützt schon den ersten Kontakt.
Warum gefährlich
Passt der TLSA-Record nicht mehr zum Zertifikat, verweigern DANE-validierende Absender die Zustellung, statt unverschlüsselt auszuweichen. Häufigster Auslöser ist eine Zertifikatsverlängerung mit neuem Schlüssel, ohne dass vorher ein TLSA-Record für den neuen Schlüssel veröffentlicht wurde. Weil andere Absender weiter zustellen, fällt der Fehler oft erst nach Tagen auf.
Ein TLSA-Record ohne DNSSEC-Signatur schützt dagegen gar nicht, Absender ignorieren ihn. Und eine kaputte DNSSEC-Kette lässt die TLSA-Abfrage mit SERVFAIL scheitern – auch dann können validierende Absender nicht zustellen.
So vermeidest du es
- DNSSEC für die Zone des Mailservers aktivieren, bevor du TLSA-Records veröffentlichst, und die Signaturen überwachen.
- Für Mailserver nur Usage 3 oder 2 verwenden, in der Regel 3 1 1 mit dem SHA-256-Hash des öffentlichen Schlüssels.
- Beim Zertifikatswechsel den Schlüssel beibehalten (bei certbot etwa mit --reuse-key) oder den TLSA-Record für den neuen Schlüssel mindestens zwei TTL-Zeiträume vorher zusätzlich veröffentlichen.
- Für jeden MX-Host einen eigenen TLSA-Record pflegen; bei gehosteter Mail prüfen, ob der Anbieter DANE selbst unterstützt.
- Zusammen mit DANE einen TLS-RPT-Record setzen, damit Absender Fehler melden.
So erkennt DomainWarn es
Der Check DANE fragt für jeden MX-Host den TLSA-Record unter _25._tcp ab und prüft, ob er DNSSEC-signiert ist, sich lesen lässt und eine für SMTP brauchbare Usage (2 oder 3) hat. Ist Port 25 für die Prüfserver freigegeben, holt er zusätzlich per STARTTLS das ausgelieferte Zertifikat und gleicht es mit den TLSA-Records ab; sonst bleibt es bei Form und Signierung.
Passt kein TLSA-Record zum Zertifikat, ist das kritisch und eröffnet sofort den Incident „DANE: TLSA passt nicht zum Zertifikat“. Unsignierte, unlesbare, unbrauchbare oder nicht prüfbare Records sowie SERVFAIL bei der Abfrage eröffnen nach zwei Läufen „DANE fehlerhaft“. Ohne TLSA-Record gibt es nur einen Hinweis; liegt der Mailserver in einer Zone ohne DNSSEC, etwa bei Microsoft 365, erklärt DomainWarn, dass DANE dort nicht greift.
Neu eingerichtetes DANE sowie geänderte und entfernte TLSA-Records meldet DomainWarn als Änderung. Der Check läuft einmal am Tag.
DomainWarn prüft das für alle deine Domains regelmäßig und meldet sich, wenn etwas fehlt oder sich ändert.