DNSSEC: what it does and doesn't protect

DNSSEC adds a signature to DNS answers, the lookup that turns your domain name into a server address. A resolver that checks the signature rejects a forged answer instead of sending your visitors, or the email addressed to you, to another server.

It encrypts nothing and does not protect the website itself. It proves the answer came from your zone. Zone signing is one of the things the DNS and domain audit checks.

What a forged DNS answer makes possible

Before every visit and every email, a machine asks the DNS where your domain lives. The original protocol gives no way to check that an answer really came from the server that is authoritative for that domain.

A forged answer placed in a resolver's cache sends that resolver's users to whatever server the forger chose, for as long as it stays there. The visitor still typed the right address. Email addressed to your domain can be diverted to another mail server the same way.

France's national cybersecurity agency (ANSSI) puts it this way in its best practices for acquiring and using domain names: DNSSEC makes up for the DNS protocol's weak security against attacks that replace an answer in transit, such as cache poisoning.

How the signature gets checked

The DNS security extensions are described in RFC 4033 and its two companion documents, published in 2005. The zone operator signs its records. A fingerprint of its key goes into the zone above, .com or .org for instance, which is signed in turn, all the way up to the root. The resolver walks back up this chain of trust.

Protection takes two parties. Your domain has to be signed, and your visitor's resolver (their internet provider's or their company's) has to check the signature. As ICANN points out, when both are in place a forged answer returns nothing at all, by design.

What DNSSEC does not protect

The signature answers one question: did this answer come from the authoritative zone? Everything else is a job for other protections.

Confidentiality. RFC 4033 says so plainly: DNSSEC is not designed to provide it. Queries and answers travel signed but readable.
The website itself. Once the browser has the address, the connection relies on HTTPS and the certificate, which the HSTS header makes mandatory in the browser's eyes.
A change made through the proper channel. If someone gets into your account at the registrar or DNS host, their changes are signed just like yours. ANSSI makes this point in its 2024 recommendations on DNS architecture.
Availability. RFC 4033 states that DNSSEC provides no protection against denial of service.

Your registrar account is also what keeps the domain renewed: the guide to domain expiration explains why renewals fail.

Why so few domains are signed

The DNS root has been signed since 2010, and most top-level domains are signed too. Below them, many domains are not. Afnic, the registry for .fr, gives two reasons: other security work comes first, and some resolvers still do not check signatures.

ANSSI itself does not formally recommend deploying DNSSEC. In its recommendations on DNS service architecture (in French), published in 2024, it asks organizations that run their own DNS servers to decide based on a risk analysis: DNSSEC requires ongoing key management and monitoring, and a mistake in the chain of trust can make a domain unreachable for hours or days.

For a website whose DNS is run by a provider, the question is different: the provider manages the keys and their rotation.

Who turns it on, and what can break

Two roles, sometimes held by the same provider. The DNS host, which answers for your zone, signs it. The registrar, where the domain is registered, passes the key fingerprint to the registry for .com or whichever extension you use. When one provider holds both roles, it is turned on there; when they are separate, the fingerprint has to travel from one to the other.

ANSSI makes this its recommendation R4 for domain names: choose a registrar that lets you publish this information. Without that, the domain holder cannot turn DNSSEC on.

What breaks is a chain that no longer matches. The typical case is a change of DNS host: if the fingerprint at the registry still points to the old key, validating resolvers reject the new host's answers, and the domain becomes unreachable for their users, website and email included. A signature left to expire has the same effect. On a signed domain, switching providers is prepared with both providers before the cutover.

What we find on the sites we audit

75%have no DNSSEC signature on their domain name

This percentage covers about 30 websites we audited between August 14, 2026 and September 24, 2026, the ones where this point could be checked. Many were audited because a defect showed up quickly, so the figure describes our audits, not websites in general.

What the audit looks at

The audit queries public DNS for your main domain. It looks for the key fingerprint published in the zone above and for your zone's signatures. The report states DNSSEC as active, missing or could not verify.

"Could not verify" is never read as "missing". If no resolver able to return these records answers during the audit, the report says so, and the score loses nothing.

A missing signature takes points off the pillar score, fewer than an unprotected mail setup. Zone signing does not replace a DMARC record, which stops others from emailing your customers in your name; ANSSI notes that DNSSEC complements these email mechanisms, which rely on DNS.

What this check doesn't tell you

We record whether the zone is signed and whether the key fingerprint is at the registry. We do not replay full validation of the chain of trust, and we cannot see your registrar access or how your provider manages keys.

DNSSEC encrypts nothing and does not protect the website itself: its presence says nothing about the security of your pages or your server.

By Quentin Mathis, Z29K · updated September 28, 2026