Warum einen Offline-Validator nutzen
Ein fehlerhaft formatierter TLSA Record wird von konformen MTAs ohne Warnung ignoriert. Du glaubst, dass deine DANE-Bereitstellung deinen eingehenden SMTP-Fluss schützt; in der Praxis prüft kein sendender Server irgendetwas. Der Ausfall bleibt still, bis zum nächsten Audit oder bis ein Zustellungsproblem die Lücke aufdeckt.
Der DANE-TLSA-Syntax-Validator analysiert deinen Record ohne Veröffentlichung oder Abfrage des DNS. Keine Daten verlassen deinen Browser, kein Signal gelangt zu einem externen Resolver. Dieser Offline-Ansatz deckt vier Anwendungsfälle ab, die ein Live-Audit nicht abdecken kann.
Typische Anwendungsfälle:
- Vor der Bereitstellung: einen Entwurf vor der DNS-Veröffentlichung validieren, um einen stillschweigend ignorierten Record zu vermeiden.
- Generator-Ausgabe: die Syntax eines Records prüfen, der von einem Drittanbieter-Tool, einem internen Wiki oder einer gemeinsamen Vorlage stammt.
- Offline-Debugging: einen Fehler reproduzieren und beheben, ohne das öffentliche DNS zu berühren, etwa in der Vorproduktion.
- Konfigurations-Review: einen Record prüfen, der von einem Partner stammt oder aus einer Kunden-Infrastruktur exportiert wurde, bevor du ihn anwendest.
Der Validator wendet die Strukturvorgaben von RFC 6698 und die operativen Vorgaben von RFC 7671 an. Keine DNS-Abfrage, keine externe Verbindung.
So nutzt du diesen Validator in 3 Schritten
Schritt 1: TLSA Record einfügen
Kopiere den Wert deines Records in das vorgesehene Feld:
3 1 1 2bb183af2e2b295b444c1fd4072f2b59a8c1c9abf7f3f1e9b0d4c7e8f1a2b3c4
Du kannst auch die vollständige Zeile mit dem Owner Name einfügen:
_25._tcp.mail.captaindns.com. IN TLSA 3 1 1 2bb183af...
Der Validator extrahiert die vier Felder und analysiert jedes unabhängig. In diesem Schritt erfolgt keine Netzwerkverbindung.
Schritt 2: Verdikt lesen
Die Ergebnisse werden nach Schweregrad sortiert:
- Fehler: blockierendes Problem, der Record wird von konformen MTAs ignoriert oder abgelehnt
- Warnung: nicht empfohlene Kombination, funktional, setzt dich aber operativen Risiken aus
- Gültig: Syntax konform mit RFC 6698 und 7671
Jede Meldung enthält das betroffene Feld, den ungültigen Wert und die erwartete Korrektur.
Schritt 3: vor der Veröffentlichung korrigieren
Passe deinen Record den Empfehlungen entsprechend an. Sobald die Syntax sauber ist, veröffentliche den TXT unter _25._tcp.<mx-host> in der DNSSEC-signierten Zone des MX-Hosts, warte auf die Propagierung und bestätige live mit dem DANE TLSA Checker.
Validator oder Checker: wann welches Tool nutzen
Die beiden Tools ergänzen sich. Sie kommen zu unterschiedlichen Zeitpunkten im Lebenszyklus eines TLSA Records zum Einsatz.
| Dimension | Validator (dieses Tool) | Checker |
|---|---|---|
| Einsatzzeitpunkt | Vor der DNS-Veröffentlichung | Nach der Veröffentlichung |
| DNS-Auflösung | Keine | Live-Auflösung _25._tcp.<mx> |
| DNSSEC-Prüfung | Nein | Ja, vollständige Kette |
| Live-Zertifikatsvergleich | Nein | Ja, über STARTTLS auf Port 25 |
| Record-Quelle | Manuell (eingefügt) | Öffentliches DNS |
| An den Server gesendete Daten | Keine | Analysierte Domain |
Empfohlener Ablauf:
- Record entwerfen oder generieren und Syntax mit dem Validator prüfen
- Den TXT in der DNSSEC-Zone des MX-Hosts veröffentlichen und auf die Propagierung warten
- Den Checker starten, um DNSSEC und den Live-Zertifikatsabgleich zu bestätigen
Der Validator fängt Eingabefehler vor der Veröffentlichung ab. Der Checker fängt Drift ab und bestätigt, dass das öffentliche, ausgelieferte DNS mit dem aktuell über STARTTLS präsentierten Zertifikat übereinstimmt.
Anatomie eines TLSA Records
Der TLSA Record enthält vier streng spezifizierte Felder.
Allgemeine Struktur
_25._tcp.mail.captaindns.com. IN TLSA <usage> <selector> <matching> <data>
| Feld | Werte | Beschreibung |
|---|---|---|
| Usage | 0-3 | Vertrauensanker |
| Selector | 0-1 | Gehashter Teil des Zertifikats |
| Matching Type | 0-2 | Vergleichsalgorithmus |
| Daten | Hex | Hash oder Binärblock |
Usage (Feld 1)
| Wert | Name | Beschreibung |
|---|---|---|
| 0 | PKIX-TA | CA-Bedingung: Das Zertifikat muss von dieser CA signiert sein UND die PKIX-Validierung bestehen |
| 1 | PKIX-EE | Zertifikatsbedingung: exakte Übereinstimmung + PKIX-Validierung |
| 2 | DANE-TA | Vertrauensanker: jedes von dieser CA signierte Zertifikat wird akzeptiert |
| 3 | DANE-EE | Domain-Zertifikat: exakte Übereinstimmung, keine PKIX-Validierung |
SMTP-Empfehlung: DANE-EE (3). Der Anker liegt in deinem Schlüssel, unabhängig von einer externen Autorität.
Selector (Feld 2)
| Wert | Name | Beschreibung |
|---|---|---|
| 0 | Cert | Vollständiges Zertifikat (DER) |
| 1 | SPKI | SubjectPublicKeyInfo (nur öffentlicher Schlüssel) |
Empfehlung: SPKI (1). Der Record bleibt gültig, solange der öffentliche Schlüssel erhalten bleibt, unabhängig von Zertifikatserneuerungen.
Matching Type (Feld 3)
| Wert | Name | Erwartete Hex-Länge |
|---|---|---|
| 0 | Full | Variabel (Rohzertifikat oder Schlüssel) |
| 1 | SHA-256 | 64 Zeichen (32 Bytes) |
| 2 | SHA-512 | 128 Zeichen (64 Bytes) |
Empfehlung: SHA-256 (1). Universell unterstützt, robust genug, kompakt.
Die empfohlene SMTP-Kombination
3 1 1 ist der De-facto-Standard für SMTP DANE.
3 1 1 <sha256-der-spki>
- Usage 3 (DANE-EE): keine CA-Abhängigkeit, Anker direkt in deinem Schlüssel
- Selector 1 (SPKI): invariant gegenüber der Zertifikatserneuerung, solange der Schlüssel erhalten bleibt
- Matching Type 1 (SHA-256): 32 Bytes, perfekt geeignet
Andere Kombinationen sind möglich, aber nicht empfohlen:
| Kombination | Status | Warum |
|---|---|---|
| 3 1 1 | Empfohlen | SMTP-Standard, robust, invariant gegenüber Erneuerungen |
| 3 0 1 | Toleriert | Hash auf das vollständige Zertifikat, ändert sich bei jeder Erneuerung |
| 2 0 1 | Akzeptabel | DANE-TA auf CA, keine DNS-Aktualisierung bei Erneuerung |
| 2 1 1 | Akzeptabel | DANE-TA auf CA-SPKI |
| 3 1 0 | Abgelehnt | Matching Type 0 legt das Rohzertifikat offen, riesige DNS-Größe |
| 1 x x | Bei SMTP abgelehnt | PKIX-EE auf MTAs selten einsetzbar |
| 0 x x | Bei SMTP abgelehnt | PKIX-TA für SMTP ungeeignet |
Der Validator meldet Kombinationen außerhalb der Empfehlung ausdrücklich und schlägt die Standardkombination vor.
Häufige Syntaxfehler und Korrekturen
Usage außerhalb des Bereichs
Ursache: Usage-Wert größer als 3.
Korrektur:
- 4 1 1 2bb183af...
+ 3 1 1 2bb183af...
Ungültiger Selector
Ursache: Selector ungleich 0 oder 1.
Korrektur:
- 3 2 1 2bb183af...
+ 3 1 1 2bb183af...
Matching Type außerhalb des Bereichs
Ursache: Matching Type größer als 2.
Korrektur:
- 3 1 3 2bb183af...
+ 3 1 1 2bb183af...
Ungültige Hexadezimaldaten
Ursache: Zeichen außerhalb des Hex-Bereichs (0-9, a-f, A-F).
Korrektur:
- 3 1 1 2bg183zf...
+ 3 1 1 2bb183af...
Falsche Hash-Länge
Ursache: Die Datenlänge passt nicht zum Matching Type.
Korrektur SHA-256:
- 3 1 1 2bb183
+ 3 1 1 2bb183af2e2b295b444c1fd4072f2b59a8c1c9abf7f3f1e9b0d4c7e8f1a2b3c4
SHA-256 (Matching Type 1) erfordert exakt 64 Hex-Zeichen. SHA-512 (Matching Type 2) erfordert exakt 128 Zeichen.
Fragile Usage/Selector-Kombination
Ursache: DANE-EE (3) + Full Cert (0) führt zu einem Hash, der sich bei jeder Zertifikatserneuerung ändert.
Empfohlene Korrektur: auf SPKI (1) umstellen, um den Record gegenüber Erneuerungen invariant zu machen (mit der ACME-Option --reuse-key).
- 3 0 1 <hash-des-vollständigen-zertifikats>
+ 3 1 1 <hash-des-öffentlichen-schlüssels>
Falscher Owner Name
Ursache: Record am Domain-Apex statt am MX-Host veröffentlicht, oder am falschen Port.
Korrektur: _25._tcp.<mx-host> exakt. Für einen MX mail.captaindns.com lautet das _25._tcp.mail.captaindns.com.
Vorbereitung eines Schlüsselwechsels
Mehrere TLSA Records in derselben Zone sind kein Fehler: Es ist das empfohlene Muster für einen unterbrechungsfreien Schlüsselwechsel.
Saubere Wechselprozedur
- T-7: Erzeuge den nächsten Schlüssel, berechne seinen SPKI-Hash und veröffentliche ihn als Duplikat:
_25._tcp.mail.captaindns.com. IN TLSA 3 1 1 <aktueller-Schlüssel-Hash>
_25._tcp.mail.captaindns.com. IN TLSA 3 1 1 <nächster-Schlüssel-Hash>
-
T-0: Führe die Zertifikatsrotation mit dem neuen Schlüssel durch. Konforme MTAs akzeptieren die Verbindung, wenn mindestens einer der beiden Records zum ausgelieferten Zertifikat passt.
-
T+7 (oder das Doppelte der TTL): Entferne den alten Record. Der Wechsel ist abgeschlossen.
Was der Validator prüft
Der Validator verarbeitet jeden Record unabhängig und bestätigt, dass:
- Jeder Hash die vom Matching Type erwartete Länge respektiert
- Kein Feld den gültigen Bereich verlässt
- Die Kombinationen innerhalb der Empfehlungen bleiben
Ein doppelter Record wird nie als Fehler gemeldet, wenn beide syntaktisch korrekt sind.
DANE und MTA-STS: komplementäre Ansätze
| Kriterium | DANE | MTA-STS |
|---|---|---|
| Mechanismus | DNSSEC + TLSA Record | HTTPS + Text-Policy |
| Abhängigkeit | DNSSEC erforderlich | HTTPS erforderlich |
| Vertrauen | Kryptografisch (signiertes DNS) | PKI (HTTPS-CA) |
| Postfix-/Exim-Unterstützung | Exzellent | Gut |
| Microsoft-365- / Google-Workspace-Unterstützung | Teilweise bis keine | Vollständig |
| Bereitstellung | Komplex (DNSSEC) | Einfacher |
Empfehlung: nicht wählen, beide einsetzen. Validiere hier deinen TLSA Record und veröffentliche dann zusätzlich eine MTA-STS-Policy. Maximale Abdeckung erfordert die Kombination.
Ergänzende Tools und Ressourcen
| Tool | Wann nutzen |
|---|---|
| DANE TLSA Checker | Live-Audit des im DNS veröffentlichten Records mit DNSSEC-Validierung und Zertifikatsabgleich |
| DANE TLSA Generator | Einen TLSA Record aus einem Zertifikat oder einem öffentlichen Schlüssel erzeugen |
| MTA-STS Syntax-Validator | Die begleitende MTA-STS-Policy offline validieren |
| TLS-RPT Syntax-Validator | Den begleitenden TLS-RPT Record offline validieren |
| E-Mail-Authentifizierungs-Audit | Übersicht der E-Mail-Authentifizierungstools |
Verwandte Leitfäden
- DANE TLSA: der vollständige Leitfaden - DANE von Anfang bis Ende verstehen, von DNSSEC bis zur SMTP-Bereitstellung.
- DANE TLSA auf Postfix, BIND und Let's Encrypt - Schritt-für-Schritt-Einrichtung mit Schlüsselwechsel.
- DANE TLSA und Microsoft 365 Exchange Online - Eingehende und ausgehende DANE-Unterstützung auf Exchange Online.
- DANE-TLSA-Troubleshooting: 12 Fallstudien - Diagnose und Behebung von DANE-Vorfällen.
- MTA-STS vs. DANE: detaillierter Vergleich - Eines wählen oder beide kombinieren.
Spezifikationen
- RFC 6698 - DANE TLSA (Originalspezifikation)
- RFC 7671 - Updates to DANE (operative Klarstellungen)
- RFC 7672 - SMTP Security via DANE (DANE für SMTP)