TLSA-Eintragsgenerator und -Checker

What a TLSA record says

DANE (RFC 6698) lets a domain publish, in DNS, which certificate or key its TLS service presents. The record lives at _<port>._<protocol>.<host> — _25._tcp.mail.example.com for a mail server, _443._tcp.www.example.com for a web server — and has three numbers and some data. The certificate usage says what to match: 3 (DANE-EE) the server's own certificate, 2 (DANE-TA) a CA certificate in the chain the server sends, 1 and 0 the same with the usual public-CA validation on top. The selector says whether the whole certificate (0) or only its public key, the SubjectPublicKeyInfo (1), is matched. The matching type says whether the data is the item itself (0) or its SHA-256 (1) or SHA-512 (2) digest.

A TLSA record only counts when the answer is signed: clients ignore records that do not validate with DNSSEC (RFC 6698 §4.1), and refuse to connect when validation fails. DANE is therefore as strong as the zone's chain of trust — which the DNSSEC inspector shows step by step.

Why 3 1 1

RFC 7671 (DANE operations) and RFC 7672 (DANE for SMTP) recommend 3 1 1: the SHA-256 digest of the server's public key. It survives a certificate renewal that keeps the key, does not depend on any CA, and ignores the certificate's names and dates — the DNSSEC signature carries the validity instead. The generator starts there, explains what changes with other combinations (a full certificate makes large answers; 2 1 x has to match a key that appears in the chain), and checks the input against the choice: a CA certificate offered for usage 3, a server certificate offered as a trust anchor, names that do not match the host, an expired certificate under a usage that checks dates.

Changing keys without an outage

Clients cache the record set for its TTL. If the server switches to a new key before the new record is everywhere, those clients refuse to connect — for mail, messages bounce. RFC 7671 §8.1 describes the safe order: publish the record of the next key next to the current one, wait at least twice the TTL, switch the server, then remove the old record. Paste the next certificate, public key or certificate request into Next certificate or key and the generator writes both records and the waiting time. A certificate request is enough: its public key is the one the next certificate will carry.

What the checker does

The checker takes TLSA records — looked up in DNS, or pasted from a zone file or dig — and the chain the server presents, as openssl s_client -showcerts prints it. It matches every record against every certificate in the positions its usage allows, the way a DANE client does: DANE-EE against the server certificate only, DANE-TA against a CA certificate above it. It reports which record matches, which match nothing, which are unusable (unknown parameters or malformed data, which RFC 6698 §4.1 tells clients to skip), whether a stronger digest makes a weaker one irrelevant (RFC 7671 §9), and finally what a DANE client will do: connect, refuse, or ignore the records because the answer is not signed.

The tool cannot open a TLS connection from your browser to read the chain itself — browsers do not expose server certificates to pages — so the chain is pasted. A server-side STARTTLS check of mail servers is the job of the STARTTLS checker.

What leaves your browser

Certificates, chains and pasted records are read and digests computed in your browser; they are never sent anywhere, and private keys are refused before anything is read. Look up in DNS asks the resolver you choose — Cloudflare at cloudflare-dns.com or Google at dns.google — for one name, such as _25._tcp.mail.example.com, with the DNSSEC OK bit set; if the resolver answers SERVFAIL, the same question is repeated with checking disabled, to tell records whose signatures fail from a broken server. The requests carry no cookies and no referrer, and our servers see none of it. Share links keep the certificate, the records and the settings after the # of the address, which browsers never send.