Warum ist DNSSEC für DANE zwingend?

Ein TLSA-Record ohne DNSSEC lässt sich unterwegs fälschen; ein Angreifer könnte ihn entfernen oder ersetzen und damit den Schutz aushebeln. Nur ein DNSSEC-validierter TLSA-Record ist vertrauenswürdig, deshalb wird das AD-Flag der Antwort geprüft.

Was bedeuten die drei Zahlen im TLSA-Record?

Usage (für SMTP nur 2 = DANE-TA, eigene CA, oder 3 = DANE-EE, Server direkt), Selector (0 = ganzes Zertifikat, 1 = nur der öffentliche Schlüssel) und Matching-Type (0 = voller Wert, 1 = SHA-256, 2 = SHA-512).

Wie erstelle ich einen TLSA-Record für SMTP?

Üblich ist 3 1 1: Usage 3, Selector 1 (öffentlicher Schlüssel), Matching-Type 1 (SHA-256). Den SHA-256-Hash des SubjectPublicKeyInfo aus dem Serverzertifikat bilden und als Record unter _25._tcp. mit TTL veröffentlichen. Die Zone muss DNSSEC-signiert sein.

Wie rotiere ich das Zertifikat ohne Zustellausfall?

Vor dem Wechsel den TLSA-Record des neuen Schlüssels zusätzlich veröffentlichen, sodass alter und neuer Record parallel gelten. Nach der Umstellung und Ablauf der TTL den alten Record entfernen. Bei Selector 1 mit gleichbleibendem Schlüssel entfällt das ganz.

Warum steht DANE nicht im Domain Check?

DANE ist noch wenig verbreitet und setzt DNSSEC voraus. Im Sammel-Check würde es bei den meisten Domains nur 'nicht eingerichtet' melden. Wer es einsetzt, prüft es gezielt hier.

MTA-STS oder DANE, was soll ich nehmen?

Beide erzwingen TLS für eingehende Mail. DANE ist stärker (Bindung ans DNS statt an die Web-PKI), verlangt aber DNSSEC in der eigenen Zone. MTA-STS kommt ohne DNSSEC aus, braucht dafür einen HTTPS-Endpunkt. Wer beides veröffentlicht, deckt beide Sender-Typen ab.

DANE Check

TLSA-Records der MX-Hosts prüfen: DNSSEC, Usage/Selector/Matching, Abdeckung.

DANE bindet das TLS-Zertifikat der Mailserver einer Domain über TLSA-Records direkt ans DNS. Für SMTP liegen sie unter _25._tcp.<mx-host> und legen fest, welchen Schlüssel oder welches Zertifikat der Zielserver vorweisen muss. Ein sendender Server, der DANE unterstützt, akzeptiert dann keine unverschlüsselte und keine falsch zertifizierte Verbindung mehr, ohne dass es eine externe Zertifizierungsstelle braucht. Der Vertrauensanker ist DNSSEC.

Was dieses Werkzeug prüft

Für jeden MX-Host der Domain fragt es die TLSA-Records unter _25._tcp.<mx-host> ab und wertet das AD-Flag der Antwort aus, also ob die Zone DNSSEC-validiert ist. Geprüft werden die drei Felder jedes Records nach RFC 7672: Usage (für SMTP nur 2 oder 3), Selector und Matching-Type mit der zur Hash-Länge passenden Byte-Zahl. Außerdem wird geprüft, ob alle MX-Hosts abgedeckt sind; eine nur teilweise Abdeckung ist eine Downgrade-Lücke. Liefert der Upstream-Resolver kein AD (alte Resolver, DNS-Interception im lokalen Netz), meldet das Werkzeug den DNSSEC-Status als nicht bestätigt und prüft nur die Syntax, statt fälschlich Sicherheit zu behaupten.

Das Ergebnis lesen

Grün heißt: jeder MX-Host hat mindestens einen syntaktisch gültigen TLSA-Record, die Zone ist DNSSEC-validiert und alle MX-Hosts sind abgedeckt. Gewarnt wird bei Teil-Abdeckung, bei Usage 0 oder 1 (für SMTP unzulässig) und wenn der DNSSEC-Status nicht bestätigt werden konnte. Kein TLSA-Record ist kein Fehler, sondern der Hinweis, dass DANE für diese Domain nicht eingerichtet ist. Der eigentliche Abgleich, ob das beim SMTP-Handshake vorgezeigte Zertifikat zum TLSA-Hash passt, braucht eine SMTP-Verbindung und ist nicht Teil dieses DNS-Checks.

Grundlagen

DANE und der TLSA-Record sind in RFC 6698 definiert, die operative Anwendung in RFC 7671, die SMTP-spezifischen Regeln (nur Usage 2 und 3, Pflicht zu DNSSEC, Umgang mit mehreren MX) in RFC 7672. DNSSEC selbst beschreiben RFC 4033 bis 4035. Ohne DNSSEC ist ein TLSA-Record wertlos, weil ein Angreifer ihn unterwegs entfernen oder ersetzen könnte; deshalb ist das validierte AD-Flag die Voraussetzung, nicht bloß eine Empfehlung.

Typische Fehlerbilder und wie man sie behebt

TLSA-Record vorhanden, aber Zone ohne DNSSEC. DANE greift dann nicht. Zuerst DNSSEC für die Zone des MX-Hosts aktivieren und die DS-Records beim Registrar hinterlegen, danach die TLSA-Records veröffentlichen.
Nur ein Teil der MX-Hosts hat TLSA-Records. Ein sendender Server weicht dann auf den ungeschützten MX aus. Für jeden MX-Hostnamen einen passenden TLSA-Record setzen.
Zertifikat erneuert, TLSA nicht. Bei Usage 3 mit Matching-Type SHA-256 ändert sich der Hash mit jedem neuen Schlüssel. Vor dem Wechsel den neuen TLSA-Record zusätzlich veröffentlichen (beide parallel), umstellen, dann den alten entfernen. Wer auf den Schlüssel statt aufs Zertifikat pinnt (Selector 1) und den Schlüssel behält, muss nichts anfassen.
Usage 0 oder 1 im Record. Diese PKIX-gebundenen Modi sind für SMTP nicht zulässig (RFC 7672). Auf Usage 3 (Zertifikat oder Schlüssel des Servers direkt, DANE-EE) oder Usage 2 (eigene CA, DANE-TA) umstellen.
Falsche Byte-Länge beim Matching-Type. Matching-Type 1 verlangt genau 32 Byte (SHA-256), Type 2 genau 64 Byte (SHA-512). Ein abgeschnittener oder mit Leerzeichen umgebrochener Hash macht den Record ungültig.

Häufige Fragen

Warum ist DNSSEC für DANE zwingend?: Ein TLSA-Record ohne DNSSEC lässt sich unterwegs fälschen; ein Angreifer könnte ihn entfernen oder ersetzen und damit den Schutz aushebeln. Nur ein DNSSEC-validierter TLSA-Record ist vertrauenswürdig, deshalb wird das AD-Flag der Antwort geprüft.
Was bedeuten die drei Zahlen im TLSA-Record?: Usage (für SMTP nur 2 = DANE-TA, eigene CA, oder 3 = DANE-EE, Server direkt), Selector (0 = ganzes Zertifikat, 1 = nur der öffentliche Schlüssel) und Matching-Type (0 = voller Wert, 1 = SHA-256, 2 = SHA-512).
Wie erstelle ich einen TLSA-Record für SMTP?: Üblich ist 3 1 1: Usage 3, Selector 1 (öffentlicher Schlüssel), Matching-Type 1 (SHA-256). Den SHA-256-Hash des SubjectPublicKeyInfo aus dem Serverzertifikat bilden und als Record unter _25._tcp.<mx-host> mit TTL veröffentlichen. Die Zone muss DNSSEC-signiert sein.
Wie rotiere ich das Zertifikat ohne Zustellausfall?: Vor dem Wechsel den TLSA-Record des neuen Schlüssels zusätzlich veröffentlichen, sodass alter und neuer Record parallel gelten. Nach der Umstellung und Ablauf der TTL den alten Record entfernen. Bei Selector 1 mit gleichbleibendem Schlüssel entfällt das ganz.
Warum steht DANE nicht im Domain Check?: DANE ist noch wenig verbreitet und setzt DNSSEC voraus. Im Sammel-Check würde es bei den meisten Domains nur 'nicht eingerichtet' melden. Wer es einsetzt, prüft es gezielt hier.
MTA-STS oder DANE, was soll ich nehmen?: Beide erzwingen TLS für eingehende Mail. DANE ist stärker (Bindung ans DNS statt an die Web-PKI), verlangt aber DNSSEC in der eigenen Zone. MTA-STS kommt ohne DNSSEC aus, braucht dafür einen HTTPS-Endpunkt. Wer beides veröffentlicht, deckt beide Sender-Typen ab.