DANE TLSA Generator and Validator Guide: Read and Build TLSA Records

When a browser connects to a site over TLS, it trusts the site's certificate because a certificate authority vouched for it. That trust has a weakness: any of the many authorities in the browser's trust store could issue a certificate for any domain, so a compromise or error at one authority can produce a valid-looking certificate for a domain the owner never asked to certify. DANE, which stands for DNS-based Authentication of Named Entities, addresses that weakness by letting the domain owner publish, in DNS, a statement of which certificate or key their service must present. The TLSA record is that statement, and a client that checks DANE compares the presented certificate against the published record, refusing the connection if they do not match.

The DANE TLSA Generator and Validator tool generates a TLSA record from usage, selector and matching type, or validates a pasted record. Both directions are format operations on values you supply or paste. The generator assembles the record text from the fields you choose, and the validator checks that a pasted record has the right shape and recognised field values. Neither direction performs a live DNS lookup, and neither can confirm that a record is actually published, that it matches a live service, or that the DNS zone is signed. Those live facts need their own checks, and a well-formed record that is not published protects nobody, just as a published record in an unsigned zone can be forged by anyone who can tamper with DNS responses.

A TLSA record has 4 fields, and each one narrows the pin. The first field is usage, which states who is allowed to assert the pin. The most common values are 3, meaning the domain owner asserts it directly, and 2, meaning the assertion is constrained by a certificate authority. The second field is selector, which states what is being pinned: 0 means the full certificate, and 1 means the public key inside it, which survives certificate renewals that reuse the same key. The third field is matching type, which states how the pinned data is stored: 0 means the full data as-is, 1 means a SHA-256 hash of the data, and 2 means a SHA-512 hash. The fourth field is the certificate association data itself, either the certificate or key data, or its hash in hexadecimal, depending on the matching type. Reading a record therefore means reading 4 choices, each of which changes what the pin enforces.

The DNSSEC condition is the part most often missed, and it is essential. TLSA records are only trustworthy when the DNS zone serving them is signed with DNSSEC, because DNSSEC is what prevents an attacker who can tamper with DNS responses from replacing the genuine TLSA record with one matching their own certificate. Without DNSSEC, a DANE check adds a step an attacker can bypass by forging the record, so the security gain is zero. Publishing TLSA records is therefore a two-part commitment: the records themselves, and a signed zone behind them, with key rollovers managed so the zone stays valid. A team that publishes TLSA without DNSSEC has done the visible half of the work and skipped the half that makes it meaningful.

A worked example you can follow

Take a sample TLSA record for the secure service on port 443 of example.com: 3 1 1 followed by a 64-character hexadecimal value. Read the fields in order. Usage 3 means the domain owner asserts the pin directly, which is the strongest and simplest form. Selector 1 means the pin covers the public key, not the full certificate, so renewing the certificate with the same key does not break the pin. Matching type 1 means the data is a SHA-256 hash, and SHA-256 produces 256 bits, which is 256 divided by 8, or 32 bytes, written as hexadecimal at 2 characters per byte, giving 32 times 2, or 64 characters. Count the characters in the sample data field: 64, which matches the expected length exactly, so the record passes the length check for its matching type.

Now build a second record with the generator for the same service, but with matching type 2, meaning SHA-512. SHA-512 produces 512 bits, which is 512 divided by 8, or 64 bytes, giving 64 times 2, or 128 hexadecimal characters. The generated record therefore carries a data field twice as long as the first, 128 characters against 64, an increase of 64 characters, and the validator for the second record must expect 128, not 64. Confusing the two lengths is a common drafting error: a SHA-256 hash pasted into a matching-type-2 record fails validation, because 64 does not equal 128, and a SHA-512 hash pasted into a matching-type-1 record fails for the reverse reason. Counting the data length against the matching type is a five-second check that catches the error before publication.

Take a third sample, a pasted record reading 3 1 1 with only 40 hexadecimal characters of data. The field count is correct at 4 fields, but the data length is wrong: 40 instead of the expected 64, a shortfall of 24 characters. The record fails validation, and the fix is to regenerate the hash from the correct key rather than padding or editing the value, because a hash is a fingerprint, and altering it by hand produces a value that matches nothing. After regenerating, re-validate and confirm 64 characters for matching type 1, then confirm separately that the zone is DNSSEC-signed before publishing, because a valid record in an unsigned zone is still unprotected.

Mistakes to avoid

The first mistake is publishing TLSA records without DNSSEC, which makes the pins forgeable and the effort pointless. The second mistake is mismatching the data length to the matching type, such as a 64-character hash under matching type 2. The third mistake is pinning a full certificate with selector 0 and then renewing the certificate with a new key, which breaks the pin and takes the service offline until the record is updated; selector 1 avoids that for key-preserving renewals. The fourth mistake is treating a format pass as a live guarantee. A well-formed record that is not published, or published in an unsigned zone, protects nobody, and only live checks of publication and signing confirm the real state.

The SSL Certificate Checker tool checks the certificate side of a TLS service, and the DNS Lookup tool helps think about DNS records more broadly. For background on how certificates are issued and read, see Certificate Authorities: Reading Who Issued a Certificate.

Checking the result before you publish it

Treat a clean format check as a draft approval, not a deployment verdict. Before publishing, confirm the pinned key or certificate is the one the service actually presents, confirm the zone is DNSSEC-signed and stays signed through key rollovers, and plan the renewal sequence so a new key's record is published before the old key is retired. Keep a note of the 4 field values and the reason for each, because a TLSA record whose choices are unexplained will be mis-edited during the next renewal. A record that is well-formed, correctly pinned, DNSSEC-backed, and renewal-planned is a genuine second anchor for TLS trust.