DNSSEC, CAA records and nameservers, explained

Most security work on a domain happens on top of DNS: SPF, DKIM and DMARC are DNS records, certificates are issued to whoever controls a DNS name, and visitors find your website through a DNS answer. These three settings protect the zone itself.

Three settings, three risks.

What DNSSEC does.

DNSSEC adds signatures to your DNS records. A validating resolver checks them along a chain that starts at the root: the parent zone, such as .se or .com, publishes a DS record holding a hash of your zone's key, and that key signs your records. RFC 4033 describes this as "origin authentication and integrity protection for DNS data".

When the check fails, a validating resolver does not pass the answer on. It returns a server failure (SERVFAIL) instead, as RFC 4035 requires. That is the protection, and also the risk: a mistake in DNSSEC makes the domain unreachable for everyone whose resolver validates, including users of Google Public DNS.

DNSSEC has limits worth knowing:

• It does not encrypt anything. RFC 4033 states plainly that DNSSEC "is not designed to provide confidentiality". DNS over HTTPS or DNS over TLS encrypt queries between a device and its resolver.
• It does not stop denial-of-service attacks on your nameservers.
• It does not help if someone takes over your DNS host or registrar account. They can change and sign whatever they like. Protect those accounts with multi-factor sign-in, and ask your registrar about registry lock.

Sweden has a head start: in 2005, .se became the first top-level domain to sign its zone.

Turn on DNSSEC in three steps.

1. Sign the zone at your DNS host. Most managed DNS services do this with one setting, and then change the signing keys automatically. If you choose the algorithm yourself, pick one of those currently recommended for signing: 13 (ECDSA P-256 with SHA-256), 8 (RSA with SHA-256) or 15 (Ed25519). The old SHA-1 algorithms 5 and 7 are not recommended.
2. Publish the DS record at your registrar. Your DNS host shows the values to enter: key tag, algorithm, digest type and digest. For .se and .nu, Internetstiftelsen can also read the DS from a CDS record that your DNS host publishes in the zone. It scans every domain daily, and switching DNSSEC on for an unsigned domain this way takes three days.
3. Check the chain. Zonemaster, from Internetstiftelsen and the French registry Afnic, and DNSViz both show whether the chain from the parent zone to your records validates. From a terminal, ask a validating resolver:

dig +dnssec example.se A @8.8.8.8

The ad flag in the answer means the resolver validated it.

Where DNSSEC goes wrong.

• Changing DNS host. This is the risky moment. Remove the DS record at your registrar, wait until its TTL has passed at the parent zone, and only then move the nameservers. Sign the zone at the new host and publish its DS record last. Cloudflare's guidance warns that changing nameservers before the old DS record has expired makes validating resolvers return SERVFAIL. Some hosts can move a signed zone without switching DNSSEC off, but that takes cooperation from both providers.
• Expired signatures. Every signature has an end date. A managed service re-signs automatically; a signer you run yourself must keep running, or the signatures lapse and the domain stops resolving.
• A new key without a new DS record. When the key that the DS record points to is replaced, the DS record at the parent must change too. CDS automation, where the registry supports it, handles this without anyone logging in to the registrar.
• Removing DNSSEC in the wrong order. Remove the DS record first, wait for its TTL, then stop signing. Never the other way round.

CAA: decide who can issue certificates.

Any publicly trusted certificate authority can issue a certificate for your domain to whoever passes its domain validation. A CAA record names the ones allowed to. Authorities have had to check CAA before issuing since 8 September 2017, under the CA/Browser Forum's Ballot 187.

example.com.  3600  IN  CAA  0 issue "letsencrypt.org"
example.com.  3600  IN  CAA  0 issue "digicert.com"
example.com.  3600  IN  CAA  0 issuewild ";"
example.com.  3600  IN  CAA  0 iodef "mailto:security@example.com"

• issue names an authority allowed to issue, one record per authority. Each publishes the name to use: letsencrypt.org for Let's Encrypt, digicert.com for DigiCert and pki.goog for Google Trust Services.
• issuewild applies only to wildcard certificates and takes precedence over issue for them. ";" forbids them entirely.
• iodef gives an address where an authority can report a request that breaks your policy.
• Subdomains inherit. An authority looks for CAA on the exact name first and then on each parent, so a record on example.com also covers www.example.com and every other subdomain without its own.

CAA works at the source. Browsers do not check it (RFC 8659 forbids using CAA to validate certificates), and it does nothing about certificates already issued.

Roll it out without breaking renewals.

Once a CAA record exists, every authority it does not name is refused, including the one that renews a certificate you forgot about. So list what you use first:

1. Search certificate transparency logs for your domain, for example on crt.sh, to see which authorities issued your current certificates. The TLS certificate checklist explains how.
2. Include subdomains pointed at other services, such as a help desk, a marketing platform or a CDN. They often get certificates from their own authority, which must be in your record.
3. Publish an issue record for each authority, issuewild if you use wildcard certificates, and an iodef address.

Nameservers: at least two, on separate networks.

RFC 1034, one of the original DNS standards, requires "every zone to be available on at least two servers". RFC 2182 adds that they "must be placed at both topologically and geographically dispersed locations", and recommends three for most organisations' zones.

With a single nameserver, one failure is enough. Resolvers keep cached answers for a while, but once those expire, the website, mail and everything else under the domain stop resolving. Most managed DNS services give you two to four nameservers on separate networks. Check two things:

• Every nameserver listed at the registrar answers, with the same records.
• The NS records at the registrar match the ones in your zone. Zonemaster tests both.

Two nameservers from the same provider protect against a server failure, not against an outage of the whole provider. A second provider covers that, but both must be kept in sync, and with DNSSEC both must sign.

What TrustSek checks.

The email security module reads the domain's CAA and NS records, and asks a validating DNS-over-HTTPS resolver, Cloudflare's and then Google's, for the zone's DNSSEC keys. These checks apply to every domain, whether or not it receives mail.

The checks have limits. A zone counts as signed when it publishes DNSSEC keys: a zone with keys but no DS record at the registrar, or with signatures that fail validation, raises no finding, so check the chain with Zonemaster after switching DNSSEC on. When neither resolver gives a clear answer, no DNSSEC finding is shown rather than a guess. CAA is read on the scanned domain itself. The nameserver check counts NS records; it does not test whether they sit on separate networks. You can see the DNSSEC status of any domain with the free MTA-STS and DNSSEC check.

Questions

Does DNSSEC encrypt DNS traffic?

No. It proves that an answer is genuine, but anyone on the path can still read it. Encrypting queries is the job of DNS over HTTPS or DNS over TLS, between a device and its resolver.

Can DNSSEC take our domain offline?

Yes, if it is misconfigured, because validating resolvers refuse answers they cannot verify. With a DNS host that signs and changes keys automatically, the risky moments are changing host and removing DNSSEC. Both are safe if the DS record goes first and its TTL is allowed to pass.

Do we need CAA if all our certificates come from one authority?

Yes. Without CAA, every publicly trusted authority may issue for your domain, not only the one you use. One issue record naming your authority changes that.

Does DNSSEC matter for email?

It protects your MX, SPF and DKIM records against forged answers, for senders whose resolvers validate. It is also required for DANE for SMTP (RFC 7672), which publishes your mail server's certificate in DNS. MTA-STS does a similar job without DNSSEC, and a domain can use both.

Check your domain's DNS security

The free check shows whether your zone is signed with DNSSEC, has a CAA record and enough nameservers, alongside SPF, DMARC and the rest of the outside-in score.

Your domain

Check your domain

Free, no sign-up. Takes about 30 seconds.