DNSSEC with Cloudflare: what it protects, what it doesn't protect and how to activate without problems

The most common confusion about DNSSEC is to describe it as “DNS encryption”. Teams that start from this wrong premise reach two equally wrong conclusions: either they dismiss the feature because "we already have TLS", or they activate it without understanding the operational dependency they have just introduced. DNSSEC signs DNS responses to prove authenticity — it doesn't encrypt anything. The attack it stops, the consequence of a mismanaged configuration, and what it simply doesn't cover are three distinct subjects that deserve separate treatment.

What DNSSEC actually does

When a recursive resolver queries an authoritative server and receives a response, there is no mechanism in traditional DNS to verify that that response is legitimate. The cache poisoning attack described by Dan Kaminsky in 2008 — and later variants — exploits exactly this: an attacker injects false records into a resolver's cache, redirecting traffic to IPs under its control without the domain owner knowing. Users query the compromised resolver, receive a malicious IP with a seemingly normal response, and move on. TLS does not solve this problem on its own: if the user was taken to a server that has a valid certificate for the domain — obtained, for example, via DV in another CA — the HTTPS chain appears intact even if the destination is fraudulent.

DNSSEC solves the problem at the DNS layer, before any TCP connection. Each DNS response carries RRSIG records — cryptographic signatures generated with the zone's private key. The resolver that supports DNSSEC validation verifies the signature using the public key published in the zone (DNSKEY record), and verifies that this public key is legitimate by checking the DS record in the parent zone — the chain of trust descends from the root, passes through the TLD zone (.com, .com.br), and arrives in your zone. A record with an invalid or missing signature, in a zone that declares DNSSEC support, results in SERVFAIL: the resolver refuses the response rather than passing on potentially tampered data.

What DNSSEC doesn't cover

DNSSEC does not encrypt DNS queries. An observer on the network can still see which domains you are querying — for this there are DNS over HTTPS (DoH) and DNS over TLS (DoT), separate protocols that encrypt transport. DNSSEC also does not protect the content of your service, does not mitigate DDoS against your authoritative servers, and does not prevent typosquatting or phishing on domains that simply look like yours. The guarantee is narrow and specific: DNS responses for your zone, when signed correctly, arrive at the resolver without tampering.

Activating on Cloudflare

The technical process in Cloudflare is simple: a button on the zone's DNS panel generates the key pair, starts signing all records in the zone, and starts serving RRSIG records automatically. The feature is available on all plans, including the free one. What you do next is what determines whether DNSSEC will work or break production.

After activating in the dashboard, Cloudflare displays the DS record that you need to register with your registrar. This DS record, published to the TLD zone by the registrar, is the link that connects the TLD's trust to your zone — without it, the chain of trust is incomplete and DNSSEC-validated resolvers treat your zone as unsigned, not invalid. The DS registration process varies by registrar: some have a graphical interface on the control panel, others require you to manually enter the fields — Key Tag, Algorithm, Digest Type and Digest. Cloudflare displays all of these formatted values after you enable DNSSEC.

The key rotation problem

The operational risk of DNSSEC isn't in the activation — it's in the maintenance. Cloudflare rotates the zone's DNSSEC keys periodically. When this happens, the DS record registered with the registrar needs to be updated to reflect the new key. If the registrar supports automatic DS updating via API — as is the case with Cloudflare Registrar, Amazon Route 53 in registered domain mode, and Namecheap with API enabled — rotation happens without manual intervention. If the registrar doesn't support it, Cloudflare sends you an alert and you have a window of time to update manually.

Missing this window has a direct consequence: the DS in the register points to a key that the zone no longer uses. DNSSEC-validated resolvers begin receiving RRSIG signed by a different key than the published DS, conclude that tampering has occurred, and return SERVFAIL for any query to your domain. From the user's point of view, the domain simply stops resolving. The fix requires updating the DS in the registrar and waiting for the TTL of the TLD zone to propagate — which is often long, on the order of hours, because you don't control that TTL.

Activate safely: what to check before and after

Before enabling DNSSEC, confirm that your registrar accepts DS records for the domain in question. For .com.br domains, Registro.br now supports DNSSEC, but historical support has been inconsistent — it's worth checking directly in the dashboard to see if the DS option is available for your specific domain before activating on Cloudflare. Activating Cloudflare without being able to register the DS with the registrar leaves the zone signed but without the complete chain of trust, which does not offer any additional protection and also creates a state that can generate confusion in future diagnostics.

After activating and registering the DS, test validation with tools such as dnssec-analyzer.verisignlabs.com or dnsviz.net before considering the process complete. These tools show each link in the chain of trust and identify invalid, expired, or missing RRSIG records. Set up alerts for key rotation — Cloudflare's dashboard offers email notifications — and document the DS update process in your DNS operations runbook. A poorly managed rotation at three in the morning, with the company's main domain returning SERVFAIL, is the type of incident that should be in the runbook before it happens, not after.