DNS security practices: DNSSEC, CAA, and lock

Your domain is the root of trust for everything above it: TLS certificates, email authentication, password resets, and the identity of your API endpoints. An attacker who controls your DNS can redirect traffic to a server they own and obtain certificates for your hostnames. DNS security is mostly three controls working together: DNSSEC to authenticate records, CAA to constrain certificate issuance, and registrar lock to protect the domain itself. Here is what each does and how to verify it.

DNSSEC: authenticating the answers

DNSSEC signs DNS records so resolvers can detect forged or modified answers. The zone is signed with a zone-signing key, that key is covered by a key-signing key, and the DS record published at your registrar anchors the chain of trust. Once deployed, a resolver that receives a bogus answer rejects it instead of using it. The operational cost is real: key rollover has to be planned, TTLs matter during transitions, and your registrar must support DS records (most do now). Verification is easy — the Verisign DNSSEC debugger and dnsviz both walk the chain for a domain and report failures — so there is no excuse for guessing whether it works. DNS over HTTPS on your clients is a complementary layer that protects the last mile.

CAA: constraining certificate issuance

A CAA record says which certificate authorities may issue for your domain. Without it, any CA that validates domain control can issue a certificate for you, which is how lookalike and misissued certificates end up in Certificate Transparency logs. With CAA, issuance outside the allowed CAs fails. Two practical notes: check the certificates you already have before adding records so you do not lock out the CA that issues them, and add an iodef property pointing at a contact address if your CA supports it, so misissuance attempts get reported to you. CAA does not stop an attacker who already controls your DNS — it limits what they can do with that control.

Registrar lock: protecting the domain itself

DNSSEC and CAA protect records and issuance; they do nothing about the domain registration. A domain is taken over at the registrar: an attacker resets the account password, disables the lock, and transfers the domain or changes the nameservers. The baseline is transfer lock enabled, a strong unique password, and two-factor authentication on the registrar account with recovery codes stored offline. For domains where a compromise would be serious, registry lock adds a manual, out-of-band approval step for any change. Keep contact and billing details current — expired domains are a takeover vector of their own.

The rest of the zone

DNS security also covers the records themselves. SPF, DKIM, and DMARC authenticate your mail so your domain cannot be used for spoofing; an aligned DMARC policy with a reporting address tells you when someone tries. Keep the zone minimal: every hostname you publish is a target, so remove records you do not use. Watch for dangling CNAMEs and stale NS records pointing at decommissioned services, which are the usual path to subdomain takeover. HSTS with preload pins HTTPS at the browser level, and monitoring certificate transparency logs for unexpected certificates gives you early warning.

Where this matters in practice

For a project that handles credentials, domain security is table stakes, which is why the trustless project treats its release pipeline as part of the same problem: signed artifacts and SBOMs so you can verify what you run. The code is at https://github.com/ikkun1222/trustless.

None of these controls is complex, but they are all easy to skip and hard to notice once skipped. When did you last check your DS record, your CAA records, and your registrar lock — and could you prove all three are still in place?