A TLSA rekord knytter en TLS tjeneste til certifikat- eller offentlige nøgledata. Det er ikke en TXT post, en erstatning for en MX record eller beviser, som hver afsender bruger DANE. For SMTP er den relevante opdagelses- og håndhævelsesadfærd defineret af RFC 7672 .
Start med MX tjenestens værtsnavn
Referencer: RFC 7672 §2.2, RFC 7672 §3.1.1, RFC 6698 §2.1.
For en tjeneste på TCP-port 25 kl mx.example.com, er den konventionelle TLSA-ejer _25._tcp.mx.example.com. Udled navnet fra det faktiske SMTP udvekslingsværtsnavn, ikke automatisk fra det synlige Fra-domæne- eller zonetop. Kontroller hvert MX endepunkt, som implementeringen har til hensigt at beskytte, og DNSSEC status langs opdagelsesvejen.
TLSA-datafelterne er certifikatbrug, vælger, matchende type og tilknytningsdata. Til denne simple ikke-aliasede rute er den viste ejer tilstrækkelig; aliaser kræver den autentificerede TLSA-basedomænehåndtering i RFC 7672 §2.2. En almindeligt anbefalet SMTP DANE profil er 3 1 1: DANE-EE brug, SubjectPublicKeyInfo valg og SHA-256 matching. Disse tal er meningsfulde protokolvalg, ikke et generisk præfiks for vilkårlig certifikattekst. RFC 7672 og RFC 7671 beskriver understøttede anvendelser og operationelle overvejelser; hold ikke-understøttede kombinationer ude af en implementeringsopskrift.
Udled de nøjagtige bytes
Referencer: RFC 6698 §2.1.2, RFC 6698 §2.1.3.
For en lokal PEM-certifikatfil cert.pem, i en Bash-shell aktiveres først set -o pipefail; en reproducerbar SPKI digest pipeline er derefter openssl x509 -in cert.pem -pubkey -noout | openssl pkey -pubin -outform DER | openssl dgst -sha256. Kræv hver fase for at lykkes. Hash den offentlige DER-repræsentation, ikke PEM-teksten, det viste fingeraftryk eller hele certifikatet, når vælger 1 er beregnet.
Konstruere _25._tcp.mx.example.com. 300 IN TLSA 3 1 1 HEXDIGEST, og erstatter HEXDIGEST med den faktiske digest. Dette er en skabelon, ikke en post, der kan publiceres. Få certifikatet præsenteret af det tilsigtede SMTP slutpunkt gennem en kontrolleret STARTTLS inspektion og sammenlign de valgte bytes. En lokal fil kan afvige fra det certifikat, som serveren virkelig tjener.
Test en nøgleændring, inden den gamle forening går på pension
Referencer: RFC 7672 §4, RFC 7671 §8.
Syntetisk armatur A bruger et testcertifikat med nøgle A og en TLSA-tilknytning afledt af A. Forventet byte-sammenligning er et match. Armaturet B serverer et certifikat med nøgle B, mens det kun bevarer A's tilknytning; forventet sammenligning er et misforhold. Fixture C udgiver begge acceptable associationer for en planlagt overgang og verificerer det tilsigtede endepunkt mod B, før A trækkes tilbage.
Timingen skal tage højde for cachelagrede TLSA-data og alle aktive serverforekomster. Et certifikat fornyet med den samme offentlige nøgle kan beholde det samme 3 1 1 forening, hvorimod en ny nøgle ændrer den. En vellykket sammenfatning er en lokal kryptografisk kontrol, ikke et SMTP DANE interoperabilitetsresultat. Live DNSSEC og SMTP test forbliver separate beviskrav.
Bekræft transport i stedet for en dashboard-etiket
Referencer: RFC 7672 §2.2, RFC 7672 §3.
Brug en DNSSEC-validerende sti til at etablere brugbare TLSA-data, og test derefter det faktiske SMTP håndtryk og tilknytning til en DANE-kompatibel implementering. Bevar DNS svar, valideringssporing, certifikatkæde, valgt tilknytning og afsenderens resultat. En understøttende afsender bør ikke stille behandle en mislykket påkrævet DANE godkendelse som en vellykket sikker levering. Gør ikke krav på universel transportbeskyttelse: Afsendersupport og det nøjagtige autentificerede opdagelsesresultat betyder noget.
Observerede associations- og opdagelsestjek
Referencer: RFC 4035 §5.
Den bibeholdte 7. november 2026 signerede opstilling, inspiceret, men ikke genudført til denne anmeldelse, validerer et TLSA RRset gennem en fastgjort forælder, autentificeret DS og underordnet DNSKEY. En separat loopback TLS tjeneste præsenterede faktisk testcertifikat A og derefter B. Udtrækning af SPKI fra hvert modtaget håndtrykscertifikat frembragte et match for A mod A, et mismatch for B mod A alene, et match for B under et A/B-overlap og et match for B efter tilbagetrækning af A. Transskriptionen registrerer tidsstempler, loopback-slutpunkter, TLS protokol og digests. Dette validerer de separate kryptografiske ingredienser; tjenesten var almindelig TLS , ikke SMTP STARTTLS , og ingen integreret DANE mailklient eller live DNS resolver-test er påstået.