Building Blue Canoe · 12 of 19
Publishing DANE Was the Easy Part
Why publishing a TLSA record was only the start of keeping DANE correct through certificate renewal.
This account was drafted on 19 August 2026. Operational states, versions and test results describe that period unless a later update is explicitly dated.
Publishing a TLSA record is easy. Keeping it true is the engineering job.
DANE was one of the original reasons for rebuilding our authoritative DNS. Once the DNSSEC chain, MX topology and certificates had settled, blue-canoe.net could finally use that foundation on the live receiving service.
What the record actually says
Each of the three MX endpoints publishes TLSA 3 1 1 for TCP port 25. Usage 3 means DANE-EE: the association is made directly with the endpoint. Selector 1 means the SubjectPublicKeyInfo rather than the whole certificate. Matching type 1 means a SHA-256 hash.
That choice binds the endpoint key through DNSSEC without tying the record to every byte of one short-lived certificate.
Compare DNS with the service, not with another file
The published values were compared with the SPKI hashes derived from the certificates actually presented by mx1, mx2 and mx3 over SMTP. All three matched, and the TLSA responses validated through DNSSEC.
The SMTP certificates also passed hostname verification. MX1's user-facing service is mail.blue-canoe.net, while sending MTAs deliver to mx1.blue-canoe.net; its active SMTP certificate covers both identities. MX2 and MX3 present their own MX names.
External validation completed the loop
An independent SSL-Tools report generated on 19 August reported trustworthy certificates, secure protocols and valid DANE for all three MX hosts. For each TLSA owner it reported both DNSSEC valid and certificate match valid.
That does not prove universal sender support for DANE. It proves that the receiving side publishes a usable association and that an external validator can follow it to the live endpoint.
The next renewal is part of today's design
The certificates are short-lived. If ordinary renewal replaced a private key, its SPKI would change and the static TLSA hash would cease to match. At the time of this account, the active Certbot lineages saved reuse_key = True, and renewal simulations passed for the three DANE lineages.
Key reuse controls the expected renewal path. It is not an excuse to stop checking. After a real renewal, the operational acceptance test still compares the key presented by SMTP with the value protected by DNSSEC.
Strong controls create strong obligations
DANE improves authentication by making a mismatch meaningful. That is precisely why it was delayed until the endpoint identities, certificate roles, publication process and renewal behaviour could be treated as one system.
The record was the smallest part of the work. The value came from being able to explain why it should still be correct after the next automated change.