In the credit union domain hijacking we worked this summer, the attacker's most valuable acquisition wasn't the DNS itself. It was what DNS control let them mint: publicly trusted TLS certificates for the institution's domain, issued within hours, including a wildcard covering every possible subdomain. Members' browsers would have shown the padlock. Every certificate authority involved followed its rules exactly.
How is that possible? Because certificate issuance is validated through DNS. If you control a domain's DNS answers, you can pass the challenge any public CA uses to prove domain ownership. And unless the domain says otherwise, every CA on earth is authorized to issue for it.
Record one: CAA, the allowlist almost nobody sets
A CAA (Certification Authority Authorization) record is a DNS record that names which certificate authorities may issue for your domain. CAs are required by industry rules to check it before issuing. The institution in our incident had none, which is the default, and which meant the attacker could shop the challenge to whichever CA was most convenient. They used two different ones.
A minimal deployment is three records at the domain apex: an issue record naming the CA (or CAs) you actually buy certificates from, an issuewild record for wildcard issuance (set it to ; to forbid wildcards entirely if you never use them, which most credit unions never do), and an iodef record with an email address, so violation reports have somewhere to go. If your certificates all come from one CA, your CAA policy is three lines and ten minutes of work.
Be honest about the limit: an attacker with full DNS control can change CAA records too. But that forces them to make a louder, slower, more visible change, and it completely shuts down the quiet early phase where a zone edit and a fast certificate happen before anyone notices. Combined with the monitoring below, it converts "instant padlock" into "tripwire."
Record two: DNSSEC, the signature on your answers
DNSSEC signs your DNS zone so resolvers can verify that answers actually came from you. Without it, nothing distinguishes your legitimate zone data from whatever an attacker publishes once they are answering in your place, and a whole class of resolver-level tampering becomes undetectable. The hijacked domain in our incident did not have DNSSEC. Neither do roughly nine out of ten domains we assess.
DNSSEC's honest caveat mirrors CAA's: an attacker who takes your registrar account can replace the DS record along with the delegation. Which is why this series keeps returning to the same architecture: registry lock makes the delegation immovable, DNSSEC makes the answers verifiable, CAA makes issuance restricted. Each control covers the others' flank. Any one alone is a speed bump; together they are a wall.
The free monitoring that makes both records bite
Every publicly trusted certificate is recorded in public Certificate Transparency logs, usually within minutes of issuance. Free services will watch those logs for your domains and email you when anything is issued. For a financial institution this is the single highest-value monitoring subscription that costs nothing: in our incident, certificate transparency was how the issuance timeline was reconstructed, and a CT alert would have flagged the compromise before the phishing infrastructure went live.
Watch three things from outside your own network: certificate transparency for your domains, your nameserver delegation, and your MX records (that last one gets its own article). All three change rarely and legitimately, which makes them perfect alert candidates: near-zero noise, near-total signal.
This week's checklist
1. Query your own domain for CAA records. No answer means no policy.
2. Publish CAA: one issue per CA you use, issuewild ";" unless you genuinely use wildcards, iodef to a monitored mailbox.
3. Ask your DNS host to enable DNSSEC and your registrar to publish the DS record. It is a checkbox at most providers.
4. Subscribe a monitored mailbox to certificate transparency alerts for every domain you own.
5. Document all four in your Part 748 program as vendor-facing controls alongside your broader third-party risk program. Examiners are starting to ask about DNS posture, and you want the answer to be a dated change ticket.
