DNS Security: DNSSEC, CAA Records, and DDoS Protection

On 11 October 2026 the DNS root zone switches to a single DNSSEC signing key, KSK-2024 — the second Key Signing Key rollover ever. Most users will notice nothing: over 95% of reporting resolvers already trust the new key. Only validating resolvers without key tag 38696 in their trust anchor will fail — check yours now.

DNS security is not one feature but three complementary mechanisms, and each protects a different property. DNSSEC authenticates the data itself, so a resolver can verify that an answer came from the authoritative source and was not altered in transit; it does not encrypt anything. CAA records tell certificate authorities which of them may issue certificates for your domain, which narrows the risk of certificate mis-issue but does not make the domain immune to other attacks. DDoS protection keeps the DNS infrastructure answering under floods, which is a prerequisite for every other service that depends on a name resolving. This guide explains the three mechanisms for readers who know web development but have never administered DNS, walks through concrete configuration examples, and ends with an action checklist for the October deadline and beyond.

What DNS is and why attackers care

DNS is the phonebook of the internet: it translates human-readable names such as example.com into the IP addresses that clients actually connect to. A browser loads a page by first asking the operating system, which in turn queries a recursive resolver — the service run by your ISP, your company, or a public provider such as 1.1.1.1 or 8.8.8.8 — to find the answer. The resolver follows the chain of authoritative servers — the nameservers that are the source of truth for a particular zone (a portion of the namespace, usually a domain and its subdomains) — and returns the result. The most common record types are A and AAAA (IPv4 and IPv6 addresses), CNAME (aliases), MX (mail servers), and TXT (arbitrary text used for verification records such as SPF and DKIM). Responses normally travel over UDP port 53, with TCP port 53 used for larger answers.

Attackers target DNS because it sits between the user and everything else. A few properties make it attractive:

• Availability. If DNS stops answering, nothing resolves: web, mail, APIs, and internal services all fail at once. A domain is effectively offline even when its web server is perfectly healthy.
• Integrity. If an attacker can forge a DNS answer, they can redirect users to a malicious server while the address bar still shows the correct domain name.
• Confidentiality. Every query reveals what the user is trying to reach. DNS itself does not hide that information.

Each of the three mechanisms described here addresses one of these properties. DNSSEC protects integrity and origin authenticity. CAA protects a different kind of control: who is allowed to obtain a certificate for your domain. DDoS protection protects availability.

DNSSEC: authentication, not encryption

DNSSEC (DNS Security Extensions) adds digital signatures to DNS records. Think of it as a signed letter in a transparent envelope: the recipient can verify who wrote the letter and that nobody changed a word, but anyone who handles the envelope can still read the contents. The standards — RFC 4033, RFC 4034, and RFC 4035 — are explicit that DNSSEC provides data origin authentication and data integrity, and that it does not provide confidentiality. It does not encrypt queries or answers, it does not hide which domains you look up, and it does not make your DNS traffic private.

Mechanically, a zone signs its record sets with a Zone Signing Key (ZSK) and publishes the signatures as RRSIG records. A second key, the Key Signing Key (KSK), signs the zone’s DNSKEY record so that the zone keys can be rotated independently. The chain of trust starts at the root zone: the parent zone publishes a DS (Delegation Signer) record that contains a digest of the child zone’s KSK, and your registrar publishes the DS record for your domain. A validating resolver walks that chain from the root trust anchor down to your domain and checks every signature. If a signature is missing or invalid, the resolver returns SERVFAIL and the client gets no answer at all.

What DNSSEC actually protects is the answer path. A validating resolver cannot be tricked by a forged answer, a poisoned cache entry, or a response modified in transit, because the signature will not verify. What it does not protect is everything around that: it does not stop an attacker from flooding your servers, it does not hide your queries, and it does not protect users from domains that are deliberately malicious but correctly signed. A signed zone is not a trusted zone; it is a zone whose answers can be verified.

The practical cost of DNSSEC is operational. You hold two keys instead of none, you must rotate them on a schedule, and every signature adds bytes to responses, which is why EDNS0 and TCP fallback matter. The most common failure mode is a broken chain: a zone that is signed but whose DS record was never published, or a DS record that does not match the current key. The failure is silent for end users — they simply get SERVFAIL — which makes DNSSEC one of the few security controls whose outage looks like a network outage.

The October 2026 root KSK rollover

The root zone’s KSK is the ultimate trust anchor for every validating resolver. The first rollover happened in October 2018; the second one is happening now. The new key, KSK-2024, was first published in the root zone on 11 January 2025, and under the automated trust anchor update mechanism defined in RFC 5011, resolvers that observe the new key for 30 days begin trusting it automatically. On 11 October 2026 the root zone will begin signing with KSK-2024 only.

A validating resolver that does not have key tag 38696 in its trust anchor by that date will fail to validate everything below the root — in practice, total DNS resolution failure for everyone using it. ICANN’s guidance is to verify manually rather than assume automatic updates worked:

• ISC BIND: check bind.keys
• Unbound / PowerDNS Recursor: check root.key
• Knot Resolver: check root.keys

If key tag 38696 is missing, confirm that RFC 5011 automatic updates are enabled and that the resolver’s process has write permission to its storage directory so the new key can actually be saved. You can inspect what your resolver believes with the usual DNS tooling:

dig +dnssec example.com A
dig DNSKEY example.com
dig DS example.com

The first command shows the RRSIG records attached to the answer. The second shows the zone’s signing keys, and the third shows what a parent zone publishes about a child. If you operate a validating resolver, treat the October date as a hard deadline: validate the trust anchor, enable automatic updates, and check again after the rollover.

CAA records: who may issue certificates for your domain

By default, any public certificate authority (CA) may issue a certificate for any domain name, provided it can demonstrate control of that domain through one of the standard validation methods. That means the entire public web PKI is only as strong as the weakest CA’s validation process. A CAA (Certification Authority Authorization) record lets you publish an allowlist: these CAs, and only these CAs, may issue certificates for this domain.

The record format is standardized in RFC 8659 (published in 2019, replacing the original RFC 6844 from 2013). Since September 2017 the CA/Browser Forum Baseline Requirements have required all publicly trusted CAs to check CAA before issuing a certificate. The syntax is simple:

example.com. IN CAA 0 issue "letsencrypt.org"

The fields are: the owner name, the class and type, a flag (almost always 0; 128 marks the record as critical so that a CA which does not understand it must refuse to issue), a tag, and a value. Three tags matter in practice:

• issue — which CAs may issue for the domain and its subdomains.
• issuewild — which CAs may issue wildcard certificates (*.example.com). In the absence of any issuewild record, the issue records apply to wildcard issuance too.
• iodef — where the CA should report attempted issuance that violates your policy, typically a mailto: or https: URL.

CAA records are additive, and the CA uses the closest record set when walking up the tree. A request for www.community.example.org checks www.community.example.org, then community.example.org, then example.org, and stops at the first set of CAA records it finds. CAA lookups also follow CNAME chains, because the CA issues for the target of the alias. That gives you fine-grained control: you can allow one CA for the whole domain but a different CA for a single subdomain hosted by a cloud provider.

A practical record set for a small site that uses Let’s Encrypt and a commercial CA, and wants reporting, looks like this:

example.com.   IN CAA 0 issue "letsencrypt.org"
example.com.   IN CAA 0 issue "sectigo.com"
example.com.   IN CAA 0 iodef "mailto:security@example.com"

To allow only non-wildcard certificates, add a deny for wildcard issuance:

example.com.   IN CAA 0 issuewild ";"

An empty value in quotes — in practice written as ";" — matches no CA, which is exactly the point. RFC 8659 uses the same trick to forbid all issuance for a name, which is occasionally useful for domains you want to keep certificate-free. You can inspect what your zone currently publishes with:

dig CAA example.com
dig +short CAA example.com

What CAA does and does not do

CAA is a control on certificate issuance, and only that. The RFC is explicit that conformance with a published CAA record is a necessary but not sufficient condition for issuance, and that relying parties must not use CAA as part of certificate validation. The practical consequences:

• CAA does not protect certificates that are already issued and valid. It only constrains future issuance.
• CAA is only as strong as CA compliance. A CA that ignores the record, or a CA that is not part of the public WebPKI, is not stopped by it.
• CAA does not stop phishing, does not prevent abuse of a valid certificate, and does not protect your DNS from hijacking or your servers from DDoS.
• CAA records need to cover every CA that issues for you, including CAs used by third parties such as your hosting provider, CDN, or email security vendor. Publishing a CAA record that omits a CA your infrastructure relies on breaks renewals — the outage looks like a certificate expiration.
• The value of CAA grows when the records are signed with DNSSEC. RFC 8659 strongly recommends DNSSEC for CAA, because a signed CAA record cannot be forged or suppressed, and the CA can prove it checked the correct record set.

CAA is best understood as a risk-reduction control, not a guarantee. It turns the default of “any CA may issue” into “the CAs I chose may issue”, which meaningfully narrows the surface for certificate mis-issue while costing almost nothing to operate.

DNS-layer DDoS protection and how it differs from network and application mitigation

A distributed denial-of-service (DDoS) attack aims to make a service unavailable by overwhelming it with traffic. CISA’s joint guidance groups attacks into three families: volumetric attacks that consume bandwidth, protocol attacks that exploit weaknesses in how servers handle connections, and application attacks that exhaust the resources of a specific application. DNS attracts all three, plus a few attack shapes that are specific to how DNS works.

• Reflection and amplification. An attacker sends a small query with a spoofed source address to many open resolvers, which respond with much larger answers to the victim. The attacker’s traffic is multiplied many times over.
• Random subdomain floods (DNS water torture). The attacker queries millions of random subdomains of a target domain. Every query is a cache miss, so the authoritative server must work for each one, and legitimate queries get lost in the noise.
• NXDOMAIN floods. A flood of queries for names that do not exist, exhausting the authoritative server and the resolver caches in front of it.
• Direct query floods and TCP SYN floods. High volumes of ordinary-looking queries, or connection floods against the TCP/53 endpoint that large answers require.

The reason DNS DDoS matters more than the same traffic against a web server is the single point of failure. If the web server dies, users see an error page. If DNS dies, users cannot even find the web server, and email, APIs, and internal services fail with it. DNS protection is therefore a prerequisite for every other layer of availability.

DNS-layer mitigation keeps the resolution path answering. The standard building blocks are:

• Anycast. The same IP address is advertised from many servers in many locations; traffic lands on the nearest one, and an attack spreads across the whole network instead of concentrating on one box.
• Rate limiting and Response Rate Limiting (RRL). The server drops or throttles excessive traffic from a source, including the amplification-prone responses that make reflection attacks work.
• DNS firewalls and RPZ. Filtering at the resolver or edge based on policy zones, which helps absorb random-subdomain and NXDOMAIN floods.
• Managed DNS providers. Commercial DNS services (including the major cloud providers) run anycast infrastructure with DDoS absorption built in, so your authoritative servers never see the flood.

Network-layer (L3/L4) mitigation is broader: it protects the connection and transport layers for any service — SYN flood protection, packet scrubbing, and blackholing at the network edge. A scrubbing center can absorb a volumetric attack aimed at your IPs before it reaches your infrastructure. This is a general-purpose control; it does not know or care that the service is DNS.

Application-layer (L7) mitigation is narrower in a different direction: it protects the application itself — a web application firewall (WAF), bot management, HTTP flood protection, and CDN caching keep the website responsive under application-layer attacks. This layer is where most people who think about “DDoS protection for a website” actually live, and it is where TLS, caching, and origin protection matter.

The three layers are complementary, and the failure modes are different. You can have excellent application-layer protection and still be offline if an attacker floods your authoritative DNS. You can have excellent DNS protection and still lose your web application to an HTTP flood. Network-layer scrubbing protects both, but only if the traffic actually routes through the scrubbing infrastructure. A sensible order of operations: protect DNS first, then the network path, then the application. DNSSEC fits into this picture only as an authentication layer — it makes forged answers fail validation, but an attacker who just wants to flood you does not care about signatures and will simply send more queries.

Operational trade-offs

Every control here has a price, and the honest way to choose is to compare the price against the risk.

DNSSEC costs ongoing operations. You manage two keys instead of none, you must rotate them on a schedule, and every signed answer is larger, which means your DNS infrastructure needs EDNS0 and working TCP fallback. The NSEC records that prove non-existence also reveal the names in your zone; NSEC3 hashes them at the cost of more computation and larger responses. The biggest real-world risk is silent breakage: a DS record that goes stale or a signature that expires turns valid lookups into SERVFAIL, and the failure looks like a network outage rather than a configuration error. Most registrars, cloud DNS services, and CDNs now support DNSSEC with one click, which removes most of the operational burden — the remaining cost is monitoring and key hygiene.

CAA costs coordination. The control is only correct if the record set matches reality: every CA that issues for you, including CAs used by your hosting, CDN, and email providers. An inventory of who can currently issue for your domains is a prerequisite, along with a process for adding a CA before you start using it. The failure mode is renewal breakage, which is why the checklist below includes testing issuance after any CAA change. The benefit — narrowing mis-issue risk — is real but modest for most sites, which is why CAA is best treated as a hygiene control that costs minutes to deploy and almost nothing to run.

DDoS protection costs money or control. Managed DNS with anycast and built-in mitigation costs little and removes the single point of failure, at the price of depending on a provider. Self-hosted DNS gives full control but makes you responsible for the availability problem: without anycast and scrubbing, a determined attacker only needs to find your IPs. Always-on protection costs more than on-demand but avoids the activation latency that lets an attack win the first minutes. Rate limiting has false positives: legitimate users behind a shared NAT or a large corporate resolver can be throttled together with the attacker. There is no configuration that is both maximally protective and never wrong, so the realistic goal is protection that is good enough, measurable, and regularly tested.

Common mistakes

• Assuming DNSSEC encrypts your queries. It authenticates; it does not hide. If query privacy matters, add DNS over TLS (DoT) or DNS over HTTPS (DoH) at the resolver.
• Enabling DNSSEC but forgetting the DS record. A signed zone without a DS record at the registrar is invisible to validating resolvers, and a mismatched DS record breaks the chain entirely.
• Publishing CAA without an inventory of your CAs. The first renewal after a CAA change is when you discover the CA you forgot — your hosting provider’s.
• Believing CAA stops phishing or DDoS. It constrains certificate issuance only, and only among compliant CAs.
• Treating anycast as the whole DDoS answer. Anycast spreads the load; rate limiting, monitoring, and a plan for the largest attacks still matter.
• Ignoring the resolver’s write permissions. RFC 5011 automatic updates fail silently when the resolver cannot write its trust anchor storage, which is exactly how resolvers miss KSK-2024.
• Self-hosting authoritative DNS with no redundancy and no mitigation. A single server with a public IP is the easiest target on the internet.
• Skipping monitoring because DNSSEC is enabled. Validation failures surface as SERVFAIL, not as alerts; without monitoring you will not know the chain broke.

Action checklist

• Before 11 October 2026: confirm your validating resolver’s trust anchor contains key tag 38696 (bind.keys for BIND, root.key for Unbound/PowerDNS Recursor, root.keys for Knot Resolver) and that RFC 5011 automatic updates are enabled with write access to the storage directory. Re-check after the rollover date.
• Enable DNSSEC on the domains you control and publish the DS record at your registrar. If your DNS provider or CDN manages signing for you, enable it there instead.
• Publish CAA records for the CAs you and your providers actually use, add an iodef reporting record, and test issuance (Let’s Encrypt’s staging environment is a safe place to do that) before and after the change.
• Put authoritative DNS behind anycast managed DNS, or verify that your current provider publishes its DDoS posture in plain language.
• Add encrypted DNS (DoT or DoH) for the resolver paths where query privacy matters.
• Monitor for SERVFAIL and validation failures, and set an annual reminder to review keys, CAs, and the DNS provider.

The three mechanisms answer three different questions. DNSSEC answers “can I trust this answer?”, CAA answers “who may issue certificates for my domain?”, and DNS-layer DDoS protection answers “will my domain still resolve under attack?”. They are complementary, not interchangeable — and the October root key rollover is a useful reminder that even the most foundational security control needs active, ongoing operation rather than a one-time configuration.

Sources: ICANN: Preparing for the Root Zone KSK Rollover, CISA: Understanding and Responding to Distributed Denial-of-Service Attacks, RFC 4033: DNS Security Introduction and Requirements, RFC 8659: DNS Certification Authority Authorization (CAA) Resource Record, RFC 5011: Automated Updates of DNS Security (DNSSEC) Trust Anchors, Let’s Encrypt: Certificate Authority Authorization (CAA)