DNS Security in Practice: DNSSEC and CAA Records

1. DNS Spoofing and Cache Poisoning: The Attack DNSSEC Was Built For

The classic DNS protocol was designed without cryptographic protection: a DNS answer carries no signature proving it genuinely came from the authoritative nameserver and was not altered in transit. An attacker able to inject a forged answer, for example by guessing the transaction ID of an in-flight query, can trick a resolver into caching the wrong IP address for a domain, an attack known as cache poisoning that gained wide attention through the Kaminsky vulnerability in 2008.

Once such an attack succeeds, the affected resolver redirects every subsequent request for that domain to an address the attacker controls, often for hours or days, as long as the poisoned answer stays in the cache. Users trying to reach mironsoft.de land unknowingly on an attacker-run copy of the site, one that harvests credentials or delivers malware, with no visible warning in the browser unless a TLS certificate error happens to trigger.

2. How DNSSEC Works: Signatures and the Chain of Trust

DNSSEC adds cryptographic signatures to DNS answers, stored in additional resource records such as RRSIG, DNSKEY and DS. Every zone signs its own records with a private key, while the corresponding public key gets published through a DS record at the parent zone, for example the DS record for mironsoft.de sitting in the .de zone. A validating resolver can then verify the signature of every answer and trace an unbroken chain of trust from the root zone down to the domain itself.

That chain of trust means any forged answer would invalidate the cryptographic signature, causing a validating resolver to discard the manipulated answer instead of caching it. DNSSEC specifically stops cache poisoning and spoofing, but it provides no encryption: DNS answers remain readable in plain text, since DNSSEC only guarantees authenticity and integrity of the answer, never its confidentiality.

# Check a domain's DNSSEC status
dig mironsoft.de DNSKEY +dnssec +short

# Show the full validation chain
delv mironsoft.de
# ; fully validated

# DS record published at the registrar (example values)
# mironsoft.de. IN DS 12345 13 2 A94B58...D3F2

3. Setting Up DNSSEC: DS Record and Key Rotation

Setup begins with the DNS hosting provider, which enables DNSSEC for the zone and automatically generates a key pair, a Key Signing Key for the DNSKEY records themselves and a Zone Signing Key for the rest of the zone's records. The public part of the Key Signing Key gets published as a DS record at the registrar, which passes it on to the parent TLD zone, closing the chain of trust.

Key rotation is part of ongoing operations: the Zone Signing Key should be renewed at regular intervals, while the Key Signing Key rotates less often but under tighter control, since changing it always requires updating the DS record at the registrar. Most modern DNS providers automate this rotation entirely, which cuts down the risk of human error considerably compared to manual key management.

4. CAA Records: Controlling Who Gets to Issue Certificates

A CAA record, Certification Authority Authorization, defines at the DNS level which certificate authorities are actually allowed to issue a TLS certificate for a given domain. Since 2017, every certificate authority bound by the CA/Browser Forum baseline requirements has been required to check the target domain's CAA record before issuing a certificate, and to refuse issuance if the requesting authority is not explicitly listed.

Without a CAA record, in principle any publicly trusted certificate authority can issue a certificate for a domain, provided domain validation succeeds. That widens the attack surface, since an attacker who briefly gains control over domain validation, through a DNS or email vulnerability for example, can request a valid certificate from practically any certificate authority. CAA records shrink that attack surface down to the explicitly permitted issuers.

5. Configuring CAA in Practice: issue, issuewild and iodef

The issue directive permits a named certificate authority to issue regular certificates, while issuewild specifically governs wildcard certificates and can be set independently of issue. Setting issuewild to a semicolon with no value forbids wildcard issuance entirely, even for otherwise permitted certificate authorities, which makes sense as an extra restriction for most domains that never use wildcard certificates.

The iodef directive lets you publish a contact address that certificate authorities can notify whenever an issuance request violates the CAA record. Those notifications provide an early warning signal for attempted misissuance and should point at a monitored address, not a mailbox nobody checks regularly anyway.

6. What DNSSEC Does Not Do: Limits and Misconceptions

DNSSEC protects only the integrity and authenticity of DNS answers, not the confidentiality of the query itself. Anyone eavesdropping on which domains a user resolves can still do so despite DNSSEC, since answers travel in plain text. Whoever needs confidentiality has to layer on DNS over TLS or DNS over HTTPS, which solve a different problem and complement DNSSEC rather than replace it.

DNSSEC also only protects the DNS layer itself, not downstream steps such as the TLS connection to the resolved server or a compromised application. An attacker who already has access to the server itself is not stopped by DNSSEC, since the DNS answer in that case is correct and unaltered, even though the target behind it has already been compromised.

7. What CAA Does Not Do: Limits of Certificate Control

CAA records only protect against misissuance by certificate authorities that actually follow the CA/Browser Forum rules and genuinely check the record. A malicious or compromised certificate authority that deliberately ignores the check is not technically stopped by a CAA record, even though such a violation now carries severe consequences for the authority itself, up to and including trust removal by major browser vendors.

Certificates already issued remain unaffected by a CAA record set afterward: the record only takes effect at the moment of a new issuance or renewal, never retroactively. Anyone suspecting an unauthorized certificate already exists has to actively hunt for it through Certificate Transparency logs and request revocation from the issuing authority if needed, since CAA alone does not solve that problem.

8. Common Misconfigurations and How DNSSEC Breakage Happens

The most serious DNSSEC mistake is a broken chain of trust, commonly called DNSSEC breakage: if the DS record published at the registrar no longer matches the zone's current Key Signing Key, after an incomplete key rotation or a provider switch without updating the DS record for example, every validating resolver discards all of the zone's answers as invalid. The domain becomes effectively unreachable for every user behind a validating resolver, a far more serious outage than simply not having DNSSEC at all.

With CAA records, the most common mistake is an overly restrictive or stale configuration that no longer includes the certificate authority actually in use, after switching from a commercial CA to Let's Encrypt without updating the CAA record, for example. The next certificate renewal then fails, often noticed only once the old certificate is already expiring, which is why updating CAA records should be a fixed step on every CA migration checklist.

9. DNSSEC and CAA as Complementary Pieces of a DNS Security Strategy

DNSSEC and CAA address different phases of the same chain of trust: DNSSEC ensures a DNS answer genuinely came from the authoritative server and was not forged in transit, while CAA governs who is even allowed to issue certificates for the domain once a certificate authority performs domain validation. Deployed together, both measures make it considerably harder for an attacker to forge DNS answers and to fraudulently obtain a valid certificate.

Neither measure replaces the other, and neither replaces additional building blocks such as HTTP Strict Transport Security or clean monitoring of issued certificates through Certificate Transparency logs. Running DNSSEC and CAA together, and regularly checking both for consistency, closes two of the practically most relevant DNS-based attack vectors without neglecting the rest of the security stack.

10. Summary

11. FAQ: DNSSEC and CAA Records: The Essentials at a Glance