DNSSEC: Trust Has to Leave Your Network

Originally published on LinkedIn on 17 September 2026. This is the permanent Blue Canoe edition, with dated technical updates where the work subsequently progressed.

Signing a zone is not the same as establishing a public chain of trust. That sounds obvious once you have done it. It is rather easier to blur the distinction while you are staring at DNSKEY and RRSIG records and everything on your own servers appears to be working.

DNSSEC was not an ornamental addition to our DNS project. It was a prerequisite for where I wanted the mail platform to go. DANE relies on DNSSEC, so if the chain of trust was not dependable there was little point publishing TLSA records on top of it.

That meant the DNSSEC work had to become boring before DANE could sensibly depend on it.

Signing was the easy part

The hidden master uses BIND inline signing. Once a zone is configured correctly, the authoritative servers can publish DNSKEY records and signed answers.

But those signatures only prove part of the job.

For an external resolver to trust the result, the chain has to connect through the parent zone. That means the DS record at the registrar and registry has to correspond to the active child key.

So our definition of green became wider than "there is an RRSIG". The master and both public secondaries had to agree. The DNSKEY had to be visible. The DS had to be generated from the key actually in use. Delegation had to be correct. Then the result had to validate from outside our own infrastructure.

The registrar became part of the system

That was one of the useful practical lessons.

I controlled the DNS servers, but I did not control the whole DNSSEC chain. The registrar sits in the middle of the process because that is where the DS normally has to be published.

Some domains were straightforward. Others were delayed by registrar access or support. One domain, themotorsportsschool.co.uk, was eventually moved away from a registrar that did not provide the DS support we needed. Once the move completed, the DNS itself did not particularly care: the authoritative service had not changed. We could finally add the DS and validate the chain.

That distinction matters. A locally signed zone can be perfectly healthy while the public chain of trust remains incomplete. Calling both states "DNSSEC enabled" would have hidden something important. So we did not.

Prove the chain, not the command

The checks became deliberately repetitive.

Before publishing DS, we compared the SOA serial on the hidden master, ns0 and ns1. We queried the active DNSKEY directly from each authoritative server. We generated the DS from the key actually in use.

After publication, we checked from outside the system. A successful BIND reload says BIND accepted something. A DNSKEY query says the key is being served. A DS query says the parent has a delegation record. A validating resolver proves that those pieces actually form a usable chain of trust.

The final state I care about is not "the command succeeded". It is "fully validated".

Even correct output can be misunderstood

One of the useful clean-up jobs came much later. A DNSSEC status script reported two DNSKEY records. The zone was healthy, so it would have been easy to leave it alone.

When we checked the evidence, there was one DNSKEY. The second line was the RRSIG covering it. The high-level conclusion — signed — was right, but one of the supporting numbers was wrong because the query and the counting logic did not mean quite the same thing.

We fixed it anyway.

That is a small example of a rule that has become increasingly important through this project: do not improve an answer because it is convenient, and do not accept a convenient answer merely because the overall result happens to be right.

Not every domain had to move at once

We resisted turning the rollout into an all-or-nothing exercise.

Some domains could have DS published immediately. Some could not because the required registrar access was outside our control. That did not make the whole DNS platform a failure, and it did not justify pretending those domains had the same security state as the others.

A domain without DS for a known external reason is a known limitation. A domain that I merely think is probably validating is something else entirely.

Why DANE waited

The temptation was to finish DNSSEC and immediately publish TLSA records for the mail platform. We chose not to. TLSA binds the identity of a live SMTP endpoint into the DNSSEC chain. Publishing it before the final MX topology, certificates and renewal behaviour were settled would have created another strong failure mode while the underlying service was still moving.

So the order became: stabilise DNS, deploy DNSSEC where possible, bring conventional mail into production, settle the certificates, then introduce DANE and MTA-STS as separately testable stages.

Trust finally reached the mail endpoints

DANE is now live for mx1, mx2 and mx3. Each endpoint publishes a TLSA association using DANE-EE, the certificate's SubjectPublicKeyInfo and a SHA-256 hash: TLSA 3 1 1. The published values were compared with the keys actually presented by the three SMTP services, and all three matched through DNSSEC-validated responses.

An independent SSL-Tools test subsequently reported DANE valid for all three receiving MX hosts, with valid DNSSEC and valid certificate matches. That matters because it tests the public service rather than merely repeating what our own zone files say.

A fresh public check on 16 September 2026 independently queried the TLSA records through Google Public DNS and connected to each SMTP service over STARTTLS. All three responses carried authenticated DNSSEC state, and the SHA-256 SPKI hash calculated from each presented certificate matched its published TLSA 3 1 1 value.

Renewal belongs inside the design

A correct TLSA record can become wrong at the next certificate renewal if the private key changes. The active Certbot lineages therefore use key reuse, and renewal dry-runs passed for all three DANE certificate lineages. That controls ordinary renewal behaviour; it does not remove the requirement to compare the live SPKI with TLSA after a real renewal.

DNSSEC is now doing the job I wanted from it: providing a trust layer on which another live service genuinely depends. The interesting part was not simply producing signatures. It was understanding where trust crossed organisational boundaries, proving every link and refusing to call the chain complete until something outside our network agreed.

Mail was the reason we started. Trust was the thing we had to build first.