Building Blue Canoe · 12 of 19
Publishing DANE Was the Easy Part
How Blue Canoe checked DANE against live SMTP endpoints and planned certificate renewal and key changes to keep DNSSEC-protected TLSA records correct.
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
At the time of this account, each of the three MX endpoints had a TLSA 3 1 1 record for TCP port 25. Usage 3 means DANE-EE: the association is made directly with the server's leaf certificate. Selector 1 means the SubjectPublicKeyInfo, or SPKI, 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 separate hostname-verification checks. Those checks matter to conventional certificate validation and MTA-STS; DANE-EE authenticates through the DNSSEC-protected TLSA association and does not require a certificate-name match. MX1's user-facing service is mail.blue-canoe.net, while sending MTAs deliver to mx1.blue-canoe.net; its active SMTP certificate covered both identities. MX2 and MX3 presented 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.
Key reuse is not a permanent ban on changing keys. A planned rotation needs a coordinated TLSA update, allowing for DNS caching before the new key is served. Replacing a node presents the same choice: securely recover the matching key or introduce a new one through that coordinated process. A successful renewal simulation does not, by itself, prove either recovery path.
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.