What Is DNSSEC? Signed DNS, CAA Records and What They Protect

DNSSEC (the DNS Security Extensions) signs DNS records so a validating resolver can prove an answer came from the zone owner and was not altered; it does not encrypt DNS queries or hide who asked. A CAA (Certification Authority Authorization) record is a separate DNS record that tells certificate authorities which of them may issue TLS certificates for the domain. Together they protect the DNS answers and certificate issuance that SPF, DMARC, MTA-STS and HTTPS depend on.

What is DNSSEC and which attack it stops: forged DNS answers and cache poisoning

DNSSEC exists because plain DNS gives a resolver no way to tell whether an answer came from the real nameserver or from someone who got a response in first. A recursive resolver caches whatever it accepts, so an injected answer is served to every client behind it until the record expires. That is cache poisoning.

RFC 4033 section 3 defines what the extensions add: origin authentication and integrity assurance for DNS data, plus authenticated denial of existence. Each record set in a signed zone carries a signature made with the zone owner's private key; a validating resolver checks it against the published public key and discards anything that fails.

RFC 4033 section 4 sets the limits: DNSSEC is not designed to provide confidentiality, and it provides no protection against denial of service. The query and the answer travel in the clear. Encrypting the transport is a separate feature, DNS over HTTPS or DNS over TLS, negotiated between a client and its resolver.

DNSSEC proves the answer is real; it does not hide it.

How the DNSSEC chain of trust works: root, TLD DS, zone DNSKEY, RRSIG and the AD bit

The DNSSEC chain of trust is an alternating sequence of DNSKEY and DS record sets, each link vouching for the next, starting from a trust anchor configured in the resolver (RFC 4033 section 2). In practice that anchor is the root zone key. For a TXT record at _dmarc.example.com the walk is:

1. The root zone's DNSKEY signs a DS record for com.
2. The com zone's DNSKEY signs a DS record for example.com.
3. The example.com DNSKEY signs an RRSIG over the TXT record set.
4. The resolver verifies each signature in turn; if every link holds, it sets the AD bit in the response header (RFC 4033 section 7).

A DS record is a digest of a child zone's DNSKEY, and RFC 4034 section 5 places it on the parent side of the delegation. That is why the registrar is involved: the DS for example.com lives in com, and the registrar is the path to get it there. Signing without publishing the DS leaves the chain broken at the top, and validating resolvers treat the zone as unsigned.

NSEC3 (RFC 5155) exists because an NSEC names the next entry in the zone, which RFC 5155 section 1.1 notes is enough to enumerate the whole zone; NSEC3 hashes the names instead.

KSK vs ZSK and key rollover: why DNSSEC uses two keys and where the operational risk is

A signed zone usually has two keys, a Key Signing Key (KSK) and a Zone Signing Key (ZSK), because the parent only needs to know about one of them. RFC 4034 does not mandate the split; section 2.1.1 defines bit 7 as the Zone Key flag and bit 15 as the Secure Entry Point (SEP) flag, a hint for signing software rather than something validators act on.

By convention the KSK carries the SEP flag and signs only the DNSKEY record set, and the DS in the parent is a digest of the KSK. The ZSK signs everything else, so rotating it never touches the registrar, while a KSK change requires a new DS at the parent.

That parent-side step is the operational risk. A KSK rollover means publishing the new key, replacing the DS through the registrar, and only then retiring the old key; a DS that points at a retired key breaks the chain for every validating resolver. Managed DNS providers commonly automate ZSK rollover, but whether the DS update is automated depends on the provider and registrar pairing.

Algorithm choice is set out in RFC 8624 section 3.1. For signing, RSASHA256 and ECDSAP256SHA256 are MUST, Ed25519 is RECOMMENDED, and RSASHA1 and RSASHA512 are NOT RECOMMENDED; the RFC points zones still on RSASHA1 toward ECDSAP256SHA256.

Why DNSSEC matters for email authentication: SPF, DKIM, DMARC and MTA-STS all read TXT records

Every email authentication mechanism is a DNS lookup first. SPF is a TXT record at the sending domain, DKIM's public key is a TXT record at selector._domainkey.domain, DMARC is a TXT record at _dmarc.domain, and MTA-STS policy discovery starts with a TXT record at _mta-sts.domain.

Without DNSSEC validation, a forged TXT answer is indistinguishable from the real one. A poisoned SPF answer can authorize an attacker's server; a poisoned DMARC answer can replace p=reject with p=none for every client behind the affected resolver. The overview of how SPF, DKIM and DMARC work together covers each record, the guide to what DMARC is covers the policy at stake, and the MTA-STS section of the BIMI post covers policy discovery.

DNSSEC also unlocks DANE for SMTP: RFC 7672 defines a downgrade-resistant protocol for MTA-to-MTA TLS built on DNSSEC-signed TLSA records, and section 1.3.2 states that secure verification of SMTP TLS certificates against the server name is not possible without DNSSEC.

What goes wrong with DNSSEC: expired signatures, stale DS records and provider migrations

DNSSEC failures tend to be operational rather than cryptographic, and the consequence of each is the same: validating resolvers reject the zone's data.

• Expired RRSIGs. Every signature carries inception and expiration times (RFC 4034 section 3.1.5). If the signing automation stops, the signatures age out while the records stay in place, and validating resolvers return a validation failure (SERVFAIL) instead of the record.
• DS not updated after a key change. A KSK rollover that never reaches the registrar leaves a DS pointing at a key the zone no longer publishes.
• Broken chain after a DNS provider migration. A new DNS host produces new keys. If the old DS stays at the registrar, validation fails until the DS is replaced or removed.
• Registrar or DNS host does not support it. Some registrars offer no way to publish a DS record, and some DNS hosts do not sign zones. Either gap leaves the chain incomplete.

What is a CAA record: flags, tag and value under RFC 8659

A CAA record is a DNS resource record, defined in RFC 8659, that states which certificate authorities are authorized to issue certificates for a domain name. Each record has three parts: a flags byte, a property tag and a value (RFC 8659 section 4.1).

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

The flags byte carries the Issuer Critical flag at bit 0, written as 128 in zone files; when it is set on a tag the CA does not recognize, the CA must not issue (RFC 8659 section 4.1). RFC 8657 adds two parameters to the issue and issuewild values: accounturi binds issuance to one account at the CA, and validationmethods limits which domain validation methods the CA may use.

How a certificate authority processes CAA: at issuance, climbing to the parent, and only when a record exists

A CA checks CAA at the moment of issuance, and publicly trusted CAs have been required to do so since the CA/Browser Forum's Ballot 187 took effect on 8 September 2017. The current Baseline Requirements (version 2.3.0, section 4.2.2.1) state that the CA MUST retrieve and process CAA records in accordance with RFC 8659 for each dNSName in the certificate, must issue within the record's TTL or 8 hours, whichever is greater, and must respect the critical flag.

The lookup climbs the DNS tree. RFC 8659 section 3 has the CA start at the exact name requested and, if no CAA record set is there, move up parent by parent, stopping at the first name that has one or giving up just below the root, which is never consulted. A record at example.com therefore governs www.example.com unless that name publishes its own. CNAME handling is left to the CA's resolver (section 7).

If the record set found contains no tag that restricts issuance, or no CAA record exists anywhere up the tree, CAA does not restrict issuance (RFC 8659 section 3). That is the default state of a domain, and it means every publicly trusted CA is permitted to issue for it.

RFC 8659 also states that relying parties MUST NOT use CAA records in certificate validation, so browsers are not permitted to consult it and it does nothing against a certificate already issued. The Baseline Requirements (section 4.2.2.2) require DNSSEC validation on CAA lookups, which is where the two records meet: a signed zone protects the CAA answer the CA relies on.

CAA mistakes that block renewals or leave issuance open

CAA errors come in two kinds: records that block a legitimate certificate and records that fail to restrict anything.

• Forgetting the ACME CA after switching. A record that names the previous CA blocks the new one, and the failure appears at the next automated renewal.
• Leaving issuewild open. With no issuewild record, the issue list also governs wildcards. A team that wants no wildcards from anyone needs an explicit issuewild set to ;.
• An iodef address that goes nowhere. Baseline Requirements section 4.2.2.1 says CAs SHOULD report blocked requests to the iodef contact. A mailbox nobody reads turns that signal into silence.
• Blocking the CA a vendor uses for a CNAME'd subdomain. SaaS platforms, CDNs and load balancers commonly obtain certificates for app.example.com from their own CA, and an apex CAA record that omits it can stop the vendor's renewal.

How to check DNSSEC and CAA for a domain

Both records are public and can be checked passively. A DNSSEC checker asks a validating DNS over HTTPS resolver for the domain's records and reads the AD flag: a signed zone with a valid chain from the root returns authenticated data, while an unsigned zone, or a signed zone whose DS is missing at the registrar, is flagged.

A CAA record checker reads the CAA records the same way, lists each issue and issuewild tag with the CA it permits and any iodef address, and flags the absence of a record. A DNS lookup pulls the nameserver, A, MX, TXT and CAA records plus the DS at the parent zone, and reports nameserver count, CAA presence and whether DNSSEC is enabled.

For companies under SOC 2 or ISO 27001 review, the DNSSEC checker maps each finding to SOC 2 CC6.1, CC6.7 and A1.2 and to ISO 27001:2022 A.8.20, A.8.14 and A.8.24. The other free security tools cover the SPF, DKIM and DMARC records DNSSEC protects.

Frequently asked questions about DNSSEC and CAA

What is DNSSEC in simple terms?

DNSSEC adds digital signatures to DNS records. A resolver checks each signature against a chain of public keys leading back to the DNS root and rejects any answer that does not verify.

Does DNSSEC encrypt DNS?

No. RFC 4033 section 4 states that DNSSEC is not designed to provide confidentiality. Queries and answers stay readable on the path; encrypting them is done separately with DNS over HTTPS or DNS over TLS.

What is a CAA record?

A CAA record is a DNS record, defined in RFC 8659, that names the certificate authorities allowed to issue TLS certificates for a domain, using issue for standard certificates, issuewild for wildcards and iodef for a violation-report address. Publicly trusted CAs are required by the CA/Browser Forum Baseline Requirements to check it before issuing.

Does a CAA record stop phishing sites?

No. A CAA record limits which CAs may issue certificates for the domain that publishes it. A phishing site on a look-alike domain gets its certificate for that other domain, which the CAA record has no say over.

Do I need DNSSEC for DMARC?

No. DMARC works without DNSSEC; DNSSEC adds assurance that the _dmarc TXT record a receiver reads is the one the owner published. DANE for SMTP (RFC 7672) does require it.