DANE TLSA Generator and Validator

Generate or check a TLSA record for DANE, with usage, selector and matching type explained and the DNSSEC requirement stated plainly.

Runs locally

Everything happens in your browser. What you paste or drop here is never uploaded, logged or stored.

Host

Port

Protocol

Usage

Selector

Matching type

Certificate or public key Hashed in your browser. No private key is needed or wanted here.

Or drop a certificate file

Read locally.

DANE is only as trustworthy as the DNS carrying it

DANE publishes a TLSA record in DNS stating which certificate or key a service is allowed to present. That moves trust from the certificate authorities into your DNS - which is a real improvement if your DNS is signed, and no protection at all if it is not.

On an unsigned zone, an attacker who can spoof or intercept DNS simply serves their own TLSA record alongside their own certificate. The record matches, the client is satisfied, and nothing has been gained. A TLSA record without DNSSEC is decoration.

This tool reports the DNSSEC status prominently on every lookup, and refuses to describe an unvalidated record as protective. The DNSSEC signal is the resolver's Authenticated Data bit - the resolver's claim that it validated the chain, not an independent verification by this tool, and the finding says so. Check your zone with DNSSEC Checker first.

Usage, selector and matching type

A TLSA record is three small numbers and a digest. Getting them wrong produces a record that matches nothing, and because DANE fails closed, a wrong record takes the service down for DANE-aware clients rather than degrading quietly.

Usage - what is being asserted

3, DANE-EE - this exact certificate is trusted, bypassing CA validation entirely. The most common deployment.
2, DANE-TA - a trust anchor that need not be publicly trusted. For a private CA.
1, PKIX-EE - normal validation must pass and the certificate must be this one.
0, PKIX-TA - normal validation must pass and the chain must include this CA.

Selector - what gets hashed, and the renewal trap

This is the choice that decides whether your record survives a certificate renewal.

0, full certificate - the digest covers the whole certificate, which changes at every renewal even when the key is unchanged. Every renewal then needs a matching DNS update, and doing them in the wrong order takes the service offline.
1, SubjectPublicKeyInfo - the digest covers the public key only. Renewing with the same key does not invalidate the record. RFC 7671 recommends this, and so does this tool.

Matching type

SHA-256 (type 1) is the recommendation. Type 0 embeds the whole certificate in DNS, producing a record of several kilobytes that risks truncation. Type 2 is SHA-512 - valid, longer, no practical gain here.

Browsers do not implement DANE

Worth stating plainly before you deploy it as a web security control. No mainstream browser validates TLSA records and none has announced plans to. For HTTPS, DANE currently protects almost nobody, and HSTS plus a CAA record give you more real protection today.

Where DANE is genuinely deployed and genuinely valuable is SMTP. Mail servers do validate TLSA records, and DANE together with MTA-STS is the current state of the art for securing mail transport between servers. If you are here for a mail server, this is worth doing - use port 25 and tcp.

Deploying without an outage

Because DANE fails closed, ordering matters:

Sign the zone with DNSSEC and confirm it validates.
Generate the record with selector 1 so it survives key-preserving renewals.
Publish the new record before deploying a new certificate, and keep both live during the overlap.
Let the old record expire only after the new certificate is confirmed in place.

Generation here happens entirely in your browser - the certificate is parsed and hashed locally, and no private key is needed or wanted. The lookup goes through this site's existing DNS client, which speaks to a fixed set of public resolvers over TCP.

Frequently asked questions

Do I need DNSSEC for DANE?

Yes, absolutely. Without it an attacker who can spoof DNS serves their own TLSA record with their own certificate and the record provides no protection. This tool reports DNSSEC status on every lookup and will not describe an unvalidated record as protective.

Which selector should I use?

Selector 1, SubjectPublicKeyInfo. It covers the public key rather than the whole certificate, so the record survives any renewal that reuses the key - which is the normal case. Selector 0 requires a DNS change at every single renewal.

Will DANE protect my website in browsers?

No. No mainstream browser implements DANE. It is genuinely valuable for SMTP, where mail servers do validate it. For HTTPS, HSTS and CAA give you more today.

What happens if my record does not match my certificate?

DANE fails closed, so DANE-aware clients refuse the connection entirely. This is why the deployment order matters: publish the new record before deploying the new certificate, and overlap them.

Is my certificate uploaded to generate the record?

No. It is parsed and hashed in your browser with the Web Crypto API. Only the lookup function contacts a server, and that sends a hostname and port - never your certificate.

References

Related tools

What this tool can and cannot tell you. It reports what is present in the input you provide. It cannot see anything you did not give it, and a clean result means nothing was found in that input - not that the wider system is secure.

Security guidance here follows current published sources - OWASP, MDN, the relevant RFCs, NIST, CISA, FIRST and MITRE - which are linked beside the specific claims they support.