Inputs
Example
_25._tcp.mail.example.com with usage 3, selector 1, matching 1 generates a DANE-EE SPKI SHA-256 record.
TLSA Record Checker/Generator
Build valid TLSA records from certificate data and compare DANE fields directly with live DNS TLSA answers.
Useful when the exact DANE owner name, selector, matching type, and digest need to line up with DNS.
Constructing TLSA records that survive operations
A TLSA record is three small decisions and one digest, and each decision changes how the record behaves operationally. Certificate usage decides what you pin — the end-entity credential itself (DANE-EE) or a trust anchor above it (DANE-TA). The selector decides what gets hashed: the whole certificate, which changes on every renewal, or only the SubjectPublicKeyInfo, which stays stable for as long as you keep the key pair. The matching type picks the digest algorithm. The popular 3 1 1 profile is popular for a reason: it survives routine certificate renewals untouched, provided the key does not change.
This tool does the assembly work precisely: it derives the association data from a pasted or uploaded certificate — or from the live certificate a public host currently presents — builds the correctly formed owner name from port, protocol, and host, and can immediately compare the generated value against what DNS actually answers. That generate-then-diff loop is the fastest way to see whether the record you are about to publish, or the one already published, matches cryptographic reality.
From certificate to published record
Decide the parameter profile before touching digests, because it encodes your operational model. If certificates renew automatically but the key pair persists, 3 1 1 makes renewals invisible to DANE. If your automation rotates keys on every renewal, either fix that or accept that every renewal becomes a coordinated DNS change with TTL discipline. Full-certificate hashing (selector 0) ties the record to one exact certificate and is best reserved for setups where that is genuinely intended.
Then generate and compare. For a planned deployment, produce the record and check it against DNS to confirm nothing stale answers under the owner name. For a live service, let the endpoint fetch the presented certificate and diff both sides in one pass. For rollovers, publish the next key's TLSA association alongside the current one at least two relevant TLSA TTLs before the credential change, allow publication and cache propagation, switch and verify every endpoint, then retire the old record only after the old credential is nowhere in use. Whether the whole deployment satisfies DANE end to end, including DNSSEC, is the DANE validator's question.
Generation mechanics and endpoint boundaries
Certificate parsing and digest generation run locally in the browser; pasted or uploaded certificate material is not sent anywhere by the generation step. DNS comparison uses DNS-over-HTTPS first with the same-origin helper as fallback, and the live-certificate endpoint accepts public hostnames on permitted ports only, supporting direct TLS and SMTP STARTTLS. The tool builds and compares association data; it does not validate DNSSEC chains, judge policy coherence, or assess sender behavior — evaluation is deliberately left to the DANE validator.
Frequently asked questions
Which certificate do I paste — leaf, intermediate, or root?
For usage 3 profiles, the leaf: DANE-EE pins the end-entity credential. Intermediates and roots only become the hashed subject when you deliberately build a DANE-TA (usage 2) record that pins a trust anchor.
Why did my TLSA record stay valid after a certificate renewal?
Because with selector 1 the digest covers only the public key, and your renewal kept the key pair. That is the designed behavior of 3 1 1, not an oversight — the record follows the key, not the paper around it.
What is the \# wire-format notation the DNS comparison sometimes shows?
RFC 3597 generic encoding, used by some DNS APIs for record types they do not model natively. The tool decodes the raw bytes back into usage, selector, matching type, and association data before comparing, so the notation itself is harmless.
Can several TLSA records coexist at one owner name?
Yes. Within one exact usage, selector, and matching-type group, any current association may match; that permits old and new data to overlap during a rollover. Different parameter groups have client-selection semantics and must remain consistent — one digest algorithm's match does not prove success for every client.
Which TTL should TLSA records use?
Short enough that a planned change propagates within your maintenance window, long enough to be cache-friendly — commonly some minutes to an hour. What matters more than the exact number: every rollover step must respect the previous TTL before the next dependent change.
Do submission ports 465 and 587 need their own records?
If you offer DANE for those services, yes — each port and protocol combination has its own owner name and record. The ecosystem's enforcement pressure is on MX-to-MX port 25, but per-service records follow the same construction shown here.