Eingaben
Beispiel
_25._tcp.mail.example.com -> 3 1 1 <sha256> plus sicherer DNSSEC-Kontext und Live-Zertifikatsvergleich.
DANE-Validator
Prüft DANE-Service-Owner, TLSA-RRsets, DNSSEC-Kontext und implementierte DANE-EE-Livevergleiche.
Nutze es, um TLSA-Records zusammen mit dem für DANE erforderlichen DNSSEC-Kontext zu prüfen.
Beurteilen, ob DANE einen Dienst wirklich schützt
DANE beantwortet eine Frage, die klassische PKI nicht beantworten kann: Ist das Zertifikat, das dieser Server gerade präsentiert, dasjenige, das sein Betreiber gemeint hat — festgehalten im DNS, geschützt durch DNSSEC? Für SMTP-Transport ist das strukturell wichtig, denn TLS auf Port 25 ist per Default opportunistisch: Ein Downgrade-Angreifer zwischen zwei MTAs kann STARTTLS schlicht herausfiltern, solange die sendende Seite keinen unabhängigen Grund hat, auf TLS mit einem bestimmten Schlüssel zu bestehen. Ein DNSSEC-signierter TLSA-Record ist dieser Grund — und DANE-konfigurierte Sender setzen ihn hart durch.
Diese Durchsetzung schneidet in beide Richtungen: Ein falscher TLSA-Record degradiert nicht sanft, sondern lässt DANE-validierende Sender die Zustellung verweigern. Dieser Validator beurteilt ein Deployment deshalb so, wie ein validierender Sender es täte — als Ganzes: Der Service-Owner-Name muss aus dem tatsächlichen MX-Host gebildet sein, die TLSA-Parameterkombination muss kohärent sein, der DNSSEC-Kontext muss die Antwort authentifizieren, und auf Anforderung muss das Live-Zertifikat den publizierten Association-Daten tatsächlich entsprechen. Ein einziger Fehltritt bricht das gesamte Versprechen.
Ein Deployment Ende-zu-Ende bewerten
Bewerte in der Reihenfolge, in der ein Sender validiert. Zuerst der Owner-Name: Für Mail liegt TLSA unter _25._tcp am MX-Hostnamen — dem Host, der Verbindungen annimmt, nicht der Empfängerdomain. Danach die Parameter-Plausibilität: Certificate-Usage, Selector und Matching-Type müssen eine betrieblich sinnvolle Kombination ergeben; DANE-EE über SPKI mit SHA-256 (3 1 1) ist der breit etablierte Standardfall. Dann das DNSSEC-Urteil, denn eine unsignierte TLSA-Antwort ist Dekoration: Ohne Authentifizierung kann ein Angreifer mit DNS-Spoofing-Möglichkeiten Records unterschieben — exakt der Angriff, den DANE schließen soll.
Zum Schluss folgt der Live-Vergleich mit dem präsentierten Zertifikat. Einen Mismatch liest du betrieblich: Der klassische Vorfall ist eine Zertifikatserneuerung, die den öffentlichen Schlüssel gewechselt hat, während der TLSA-Record den alten Digest behielt. Von außen ist das von einem Angriff nicht zu unterscheiden, und validierende Sender behandeln es genauso. Für einen Rollover gehören neue Association-Daten mindestens zwei relevante TLSA-TTLs vor dem Credential-Wechsel zusätzlich ins DNS; nach Publikations- und Cache-Propagation werden alle Endpunkte umgestellt und geprüft, und erst wenn das alte Credential nirgends mehr läuft, wird der alte Record entfernt.
Bewertungsumfang und seine Grenzen
Eingefügte TLSA-Records bleiben im Browser; Live-Checks nutzen den geschützten Same-Origin-Endpunkt für öffentliche Hosts auf erlaubten Ports. Der Validator bewertet jeweils eine Service-Bindung. Innerhalb einer exakten Usage-/Selector-/Matching-Type-Gruppe darf jede aktuelle Association passen; so bleibt ein Alt/Neu-Rollover möglich. Für ein sauberes Cross-Client-Ergebnis muss jedoch jede unterstützte publizierte Gruppe passen. Gemischte Digest-Gruppen sind kein universelles ODER. Diese hostbezogene Prüfung authentifiziert weder das MX-RRset noch die Alias-Routing-Kette der Empfängerdomain. DANE-TA Usage 2 wird als unsupported gemeldet, weil dieser Pfad weder die vollständige Chain zum gewählten Trust Anchor baut noch die SMTP-Referenzidentität validiert. Policy des sendenden MTA, Trust Store und Monitoring auditiert er nicht; Records baut der TLSA-Generator.
Häufige Fragen
An welchem Namen liegt der TLSA-Record für Mail?
Am MX-Hostnamen, nicht an der Empfängerdomain: _25._tcp.mail.example.com, wenn mail.example.com die Mail für example.com annimmt. Records unter der nackten Domain sind eine verbreitete und völlig wirkungslose Fehlplatzierung.
Warum ist TLSA ohne validiertes DNSSEC wertlos?
Weil die ganze Rolle des Records darin besteht, die vertrauenswürdige Aussage über den erwarteten Schlüssel zu sein. Unsigniert kann ihn derselbe Angreifer fälschen, den DANE stoppen soll — ein Sender, der die Antwort nicht authentifizieren kann, ignoriert sie zu Recht.
Woran scheitern DANE-Deployments in der Praxis am häufigsten?
An Renewals. Zertifikat oder Schlüssel ändern sich, der TLSA-Record nicht — und DANE-validierende Sender beginnen, Mail abzuweisen. SPKI-basierte Association (Selector 1) plus beibehaltenes Schlüsselpaar machen Routine-Renewals zum Nicht-Ereignis.
Muss ich 2-x-x-Records anders bewerten als 3-x-x?
Ja. Usage 3 (DANE-EE) pinnt das End-Entity-Credential; Self-signed-, WebPKI-Namens- oder Ablaufstatus negiert eine passende DNSSEC-sichere Association nicht. Usage 2 (DANE-TA) verlangt vollständige Chain, Association zum gewählten Trust Anchor und SMTP-Referenzidentitätsprüfung. Dieser Validator meldet Usage 2 als unsupported, bis alle diese Checks verfügbar sind.
Schützt DANE die Browser meiner Nutzer?
Praktisch nein. Mainstream-Browser validieren die Web-PKI, nicht TLSA. Das Produktions-Habitat von DANE ist MTA-zu-MTA-SMTP — dort erzwingt ein relevanter Anteil validierender Sender die Records, und Zustellung hängt real davon ab, dass sie stimmen.
Wie verhält sich DANE zu MTA-STS?
Gleiche Bedrohung, verschiedene Vertrauenswurzeln: DANE ankert in DNSSEC, MTA-STS in HTTPS und der Web-PKI — jedes deckt Sender ab, die das andere nicht erreicht. Gut betriebene Mail-Domains publizieren beides; diese Seite beurteilt nur die DANE-Hälfte.