Eingaben
Beispiel
_25._tcp.mail.example.com mit Nutzung 3, Selektor 1, Matching-Typ 1 erzeugt einen DANE-EE-SPKI-SHA-256-Record.
TLSA-Record-Prüfer/Generator
Erzeugt TLSA-Records aus Zertifikatsdaten und vergleicht DANE-Felder mit Live-DNS-TLSA-Antworten.
Nützlich, wenn DANE-Owner-Name, Selektor, Matching-Typ und Digest exakt mit DNS zusammenpassen müssen.
TLSA-Records bauen, die den Betrieb überleben
Ein TLSA-Record besteht aus drei kleinen Entscheidungen und einem Digest — und jede Entscheidung verändert, wie sich der Record im Betrieb verhält. Die Certificate-Usage bestimmt, was du pinnst: das End-Entity-Credential selbst (DANE-EE) oder einen Trust-Anchor darüber (DANE-TA). Der Selector bestimmt, was gehasht wird: das ganze Zertifikat, das sich bei jeder Erneuerung ändert, oder nur die SubjectPublicKeyInfo, die stabil bleibt, solange du das Schlüsselpaar behältst. Der Matching-Type wählt den Digest-Algorithmus. Das populäre Profil 3 1 1 ist aus gutem Grund populär: Es übersteht Routine-Erneuerungen unangetastet — vorausgesetzt, der Schlüssel wechselt nicht.
Dieses Tool erledigt die Fleißarbeit präzise: Es leitet die Association-Daten aus einem eingefügten oder hochgeladenen Zertifikat ab — oder aus dem Live-Zertifikat, das ein öffentlicher Host gerade präsentiert —, baut den korrekt geformten Owner-Namen aus Port, Protokoll und Host und kann den generierten Wert unmittelbar gegen die tatsächliche DNS-Antwort halten. Diese Generieren-und-Diffen-Schleife ist der schnellste Weg zu sehen, ob der Record, den du publizieren willst — oder der bereits publizierte — mit der kryptografischen Realität übereinstimmt.
Vom Zertifikat zum publizierten Record
Lege das Parameterprofil fest, bevor du Digests anfasst, denn es kodiert dein Betriebsmodell. Erneuern sich Zertifikate automatisch, während das Schlüsselpaar bestehen bleibt, macht 3 1 1 Renewals für DANE unsichtbar. Rotiert deine Automatisierung bei jeder Erneuerung auch den Schlüssel, dann behebe entweder das — oder akzeptiere, dass jede Erneuerung eine koordinierte DNS-Änderung mit TTL-Disziplin wird. Ganzzertifikat-Hashing (Selector 0) bindet den Record an genau ein Zertifikat und gehört in Setups, in denen genau das gewollt ist.
Dann generieren und vergleichen. Für ein geplantes Deployment erzeugst du den Record und prüfst gegen DNS, ob unter dem Owner-Namen nichts Veraltetes antwortet. Für einen Live-Dienst lässt du den Endpunkt das präsentierte Zertifikat holen und beide Seiten in einem Durchlauf diffen. Für einen Rollover gehören die Association-Daten des nächsten Schlüssels 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. Ob das Gesamt-Deployment DANE Ende-zu-Ende erfüllt, inklusive DNSSEC, ist die Frage des DANE-Validators.
Generierungsmechanik und Endpunkt-Grenzen
Zertifikats-Parsing und Digest-Erzeugung laufen lokal im Browser; eingefügtes oder hochgeladenes Zertifikatsmaterial verlässt den Rechner beim Generieren nicht. Der DNS-Vergleich nutzt zuerst DNS-over-HTTPS mit dem Same-Origin-Helfer als Fallback, und der Live-Zertifikats-Endpunkt akzeptiert nur öffentliche Hostnamen auf erlaubten Ports — direktes TLS und SMTP-STARTTLS. Das Tool baut und vergleicht Association-Daten; DNSSEC-Ketten validieren, Policy-Kohärenz beurteilen oder Senderverhalten bewerten tut es nicht — die Bewertung bleibt bewusst beim DANE-Validator.
Häufige Fragen
Welches Zertifikat füge ich ein — Leaf, Intermediate oder Root?
Für Usage-3-Profile das Leaf: DANE-EE pinnt das End-Entity-Credential. Intermediates und Roots werden nur dann zum gehashten Gegenstand, wenn du bewusst einen DANE-TA-Record (Usage 2) baust, der einen Trust-Anchor pinnt.
Warum blieb mein TLSA-Record nach einer Zertifikatserneuerung gültig?
Weil der Digest bei Selector 1 nur den öffentlichen Schlüssel abdeckt — und dein Renewal das Schlüsselpaar behalten hat. Das ist das gewollte Verhalten von 3 1 1, kein Versehen: Der Record folgt dem Schlüssel, nicht dem Papier drumherum.
Was bedeutet die \#-Wire-Format-Notation, die der DNS-Vergleich manchmal zeigt?
Generische RFC-3597-Kodierung, die manche DNS-APIs für Record-Typen nutzen, die sie nicht nativ modellieren. Das Tool dekodiert die Rohbytes vor dem Vergleich zurück in Usage, Selector, Matching-Type und Association-Daten — die Notation selbst ist harmlos.
Können mehrere TLSA-Records an einem Owner-Namen koexistieren?
Ja. Innerhalb einer exakten Usage-/Selector-/Matching-Type-Gruppe darf jede aktuelle Association passen; so können alte und neue Daten bei einem Rollover überlappen. Verschiedene Parametergruppen folgen Client-Auswahlregeln und müssen konsistent bleiben — der Match eines Digest-Algorithmus beweist keinen Erfolg für jeden Client.
Welche TTL sollten TLSA-Records haben?
Kurz genug, dass eine geplante Änderung innerhalb deines Wartungsfensters propagiert, lang genug für die Caches — üblich sind einige Minuten bis eine Stunde. Wichtiger als die exakte Zahl: Jeder Rollover-Schritt muss die vorherige TTL respektieren, bevor die nächste abhängige Änderung folgt.
Brauchen die Submission-Ports 465 und 587 eigene Records?
Wenn du DANE für diese Dienste anbietest, ja — jede Port-Protokoll-Kombination hat ihren eigenen Owner-Namen und Record. Der Durchsetzungsdruck des Ökosystems liegt auf MX-zu-MX-Port-25, aber Records je Dienst folgen derselben Konstruktion wie hier gezeigt.