A TLSA-Eintrag Ordnet einen TLS Dienst Zertifikat- oder Public-Key-Daten zu. Es ist kein TXT Eintrag, ein Ersatz für ein MX Eintrag oder Beweise, die jeder Absender verwendet DANE. Für SMTP wird das relevante Erkennungs- und Durchsetzungsverhalten durch RFC 7672 definiert.
Beginnen Sie mit dem Hostnamen MX Dienstes
Referenzen: RFC 7672 §2.2, RFC 7672 §3.1.1, RFC 6698 §2.1.
Für einen Dienst auf TCP-Port 25 unter mx.example.com, der herkömmliche TLSA-Besitzer ist _25._tcp.mx.example.com. Leiten Sie den Namen vom tatsächlichen SMTP -Exchange-Hostnamen ab, nicht automatisch vom sichtbaren Von-Domänen- oder Zonen-Apex. Überprüfen Sie jeden MX Endpunkt, den die Bereitstellung schützen soll, und die DNSSEC Status entlang des Entdeckungspfads.
Die TLSA-Datenfelder sind Zertifikatsverwendung, Wähler, passende Typ- und Assoziationsdaten. Für diese einfache Route ohne Alias reicht der angezeigte Besitzer aus; Aliase erfordern die authentifizierte TLSA-Basisdomänenbehandlung in RFC 7672 §2.2. Ein häufig empfohlenes SMTP DANE Profil ist 3 1 1: DANE-EE-Nutzung, SubjectPublicKeyInfo-Auswahl und SHA-256-Abgleich. Bei diesen Zahlen handelt es sich um sinnvolle Protokolloptionen und nicht um ein generisches Präfix für beliebigen Zertifikatstext. RFC 7672 und RFC 7671 beschreiben unterstützte Nutzungen und betriebliche Überlegungen; Halten Sie nicht unterstützte Kombinationen aus einem Bereitstellungsrezept fern.
Leiten Sie die genauen Bytes ab
Referenzen: RFC 6698 §2.1.2, RFC 6698 §2.1.3.
Für eine lokale PEM-Zertifikatdatei cert.pem, in einer Bash-Shell zuerst aktivieren set -o Pipefail; Dann entsteht eine reproduzierbare SPKI-Digest-Pipeline openssl x509 -in cert.pem -pubkey -noout | openssl pkey -pubin -outform DER | openssl dgst -sha256. Erfordern Sie jede Phase, um erfolgreich zu sein. Hashen Sie die DER-Öffentlich-Schlüssel-Darstellung, nicht den PEM-Text, den angezeigten Fingerabdruck oder das gesamte Zertifikat, wenn Selektor 1 vorgesehen ist.
Konstrukt _25._tcp.mx.example.com. 300 IN TLSA 3 1 1 HEXDIGEST, wobei HEXDIGEST durch den tatsächlichen Digest ersetzt wird. Dies ist eine Vorlage, kein veröffentlichbarer Datensatz. Erhalten Sie das vom vorgesehenen SMTP Endpunkt vorgelegte Zertifikat über einen kontrollierten Weg STARTTLS Inspektion und Vergleich der ausgewählten Bytes. Eine lokale Datei kann sich von dem Zertifikat unterscheiden, das der Server tatsächlich bereitstellt.
Testen Sie eine Schlüsseländerung, bevor Sie die alte Zuordnung aufgeben
Referenzen: RFC 7672 §4, RFC 7671 §8.
Das synthetische Gerät A verwendet ein Testzertifikat mit Schlüssel A und einer von A abgeleiteten TLSA-Zuordnung. Der erwartete Byte-Vergleich ist eine Übereinstimmung. Fixture B stellt ein Zertifikat mit Schlüssel B bereit und behält dabei nur die Assoziation von A bei; Der erwartete Vergleich stimmt nicht überein. Fixture C veröffentlicht beide akzeptablen Zuordnungen für einen geplanten Übergang und überprüft den beabsichtigten Endpunkt gegenüber B, bevor A zurückgezogen wird.
Das Timing muss zwischengespeicherte TLSA-Daten und alle aktiven Serverinstanzen berücksichtigen. Ein mit demselben öffentlichen Schlüssel erneuertes Zertifikat kann denselben behalten 3 1 1 Assoziation, während ein neuer Schlüssel sie ändert. Ein erfolgreicher Digest-Vergleich ist eine lokale kryptografische Prüfung und kein SMTP DANE Interoperabilitätsergebnis. Live- DNSSEC und SMTP Tests bleiben separate Nachweisanforderungen.
Überprüfen Sie den Transport anstelle eines Dashboard-Etiketts
Referenzen: RFC 7672 §2.2, RFC 7672 §3.
Verwenden Sie einen DNSSEC-validierenden Pfad, um verwendbare TLSA-Daten einzurichten, und testen Sie dann den tatsächlichen SMTP Handshake und die Zuordnung mit einer DANE-fähigen Implementierung. Behalten Sie DNS Antworten, Validierungs-Trace, Zertifikatskette, ausgewählte Zuordnung und das Ergebnis des Absenders bei. Ein unterstützender Absender sollte eine fehlgeschlagene erforderliche DANE Authentifizierung nicht stillschweigend als erfolgreiche sichere Zustellung behandeln. Beanspruchen Sie keinen universellen Transportschutz: Es kommt auf die Absenderunterstützung und das genaue authentifizierte Erkennungsergebnis an.
Beobachtete Assoziations- und Entdeckungsprüfungen
Referenzen: RFC 4035 §5.
Das beibehaltene, signierte Gerät vom 7. November 2026, das für diese Überprüfung überprüft, aber nicht erneut ausgeführt wurde, validiert einen TLSA-RRset über einen angehefteten übergeordneten, authentifizierten DS und untergeordneten DNSKEY. Ein separater Loopback- TLS Dienst präsentierte tatsächlich das Testzertifikat A und dann B. Das Extrahieren von SPKI aus jedem empfangenen Handshake-Zertifikat ergab eine Übereinstimmung für A mit A, eine Nichtübereinstimmung für B mit A allein, eine Übereinstimmung für B während einer A/B-Überlappung und eine Übereinstimmung für B nach der Außerbetriebnahme von A. Das Transkript zeichnet Zeitstempel, Loopback-Endpunkte, TLS Protokoll und Digests auf. Dadurch werden die einzelnen kryptografischen Bestandteile validiert; Der Dienst war gewöhnliches TLS , nicht SMTP STARTTLS , und es wird kein integrierter DANE Mail-Client oder Live DNS -Resolver-Test beansprucht.