Network and Access

What is DNSSEC?

DNSSEC (Domain Name System Security Extensions) cryptographically signs DNS answers, so that whoever asks can tell an authentic answer apart from a forged one. It hides nothing and speeds up nothing: it solves the historical impossibility of knowing whether a name's translation can be trusted. The verification climbs a chain of signatures up to the root of the internet, and only protects when both ends take part, because signing is the decision of whoever owns the domain and validating is the decision of whoever asks.

Zamak TechnologiesUpdated on August 6, 2026

How DNSSEC works

The idea is simple and the execution is a chain: each level of DNS signs its own content and hands the level above just enough to confirm who it is. Whoever asks only has to trust the first link.

The zone is signed

The domain owner generates a key pair and signs its records. The signature for each set of records goes into a record of its own, the RRSIG, which travels with the answer.

The public key is published

The public half of the pair goes into the zone itself, in a DNSKEY record. That is what any resolver in the world uses to check that domain's signatures.

The link to the level above is registered

A digest of that key is published in the parent zone as a DS record, through the domain's registrar. It is this step, done outside the DNS panel, that ties your domain into the chain.

The resolver climbs the chain and decides

On receiving the answer, the resolver checks the signature against the key, the key against the DS one level up, and so on to the root. If any link fails to close, it refuses the answer rather than passing it along.

Source: RFC 4033, the official IETF specification introducing DNSSEC, which defines the chain of trust as an alternating sequence of DNSKEY and DS records with each link vouching for the next, RFC 4035, which defines validating resolver behaviour and the refusal of an answer that does not check out, and APNIC Labs' measurement material on the difference between signing and validating.

What DNSSEC does not do

It does not hide the query. The standard is explicit: DNSSEC was not designed to provide confidentiality or access control. Anyone watching the network still sees which names you looked up; what changes is that the answer can no longer be swapped without it showing.
It does not protect against unavailability. This too is written into the standard: DNSSEC provides no protection against denial of service attacks. Authenticity and availability are different problems.
It does not prevent takeover at the source. If a criminal gains access to the domain account at the registrar, they become the one signing, and the chain closes perfectly around an answer that is officially wrong.
The benefit does not show up on your side. Signing your domain does not protect your browsing: it protects those looking for you, and only if their resolver validates signatures. You do your half in full, and the other half is never yours to do.

The pieces of the chain of trust

DNSKEY (DNS Public Key), the zone's public key It is published in the domain itself and is what lets any server in the world check its signatures. Exposing that half is intentional and carries no risk: with it you verify, never sign.
RRSIG (Resource Record Signature), the signature on each set Every group of records gets its own signature, traveling with the answer and carrying an expiry. An expired signature fails the check, which makes renewal a standing task rather than a project that ends.
DS (Delegation Signer), the link to the level above A digest of your key, published in the parent zone through the registrar. It is the one step that does not happen in your DNS panel, and so the one that most often leaves a project half done: the zone is signed and nobody can validate it.
The root, the trust anchor The top of the chain already comes configured in advance in any resolver that validates on the public internet. The standard calls this a trust anchor: a key trusted by configuration rather than by checking. That is what makes the model workable: nobody has to trust each domain, only the first link.

Who pays for it and who reaps the benefit

36%

of internet users already sit behind a resolver that checks signatures, while only 7% of delegations are actually signed: the capacity to verify exists and sits idle waiting for someone to sign (APNIC, 2025)

SERVFAIL

is what a validating resolver returns when the signature does not check out: the standard requires refusal, so whoever asked gets nowhere rather than getting to the wrong place (RFC 4035)

Zero

confidentiality and zero protection against denial of service: the standard itself states DNSSEC was designed for neither (RFC 4033)

What most confuses decision-makers is that DNSSEC is a two-ended protocol with different owners. Signing your domain is your decision and you carry it out alone; validating signatures is the decision of whoever asks, and you have no say in it. That means the benefit of signing does not show up in your environment, it shows up in the experience of third parties looking for you, and only those whose resolver does the checking. It is the opposite of the intuition of someone used to buying controls that protect their own perimeter. For a company, the practical consequence is choosing the right side in each case: signing the domain protects customers, partners and the servers delivering your email from receiving a forged answer in your name; using validating resolvers protects your own operation from being taken to the wrong place. Both are cheap and both are independent of each other, and the second is the one that tends to lag for a mundane reason: most networks use whatever resolver came by default from the internet service provider, and validation today is concentrated in a handful of public resolvers (APNIC Labs). Moving to a resolver that validates is a configuration decision, not a budget one.

How to roll out DNSSEC without breaking the domain

Getting this wrong does not degrade the service, it takes the domain offline for everyone who validates. That is why the order matters:

Confirm the DNS provider and the registrar both support itBoth have to, and they are not always the same company. Finding that out after signing is what produces the signed domain nobody can validate.
Sign the zone and check before publishing the linkWith the zone signed and no DS at the parent yet, nothing changes for the world: it is the window to verify the signatures are correct with no risk of an outage.
Publish the DS at the registrar with the exact valueThis is the manual step and the most dangerous one: a wrong digest, or one published out of order, makes every validating resolver refuse your domain. Check the value before and verify the chain after.
Treat key rotation as routine, not as a projectSignatures expire. Automate renewal and key rollover, and monitor expiry the way you monitor a website certificate, because the failure has the same effect: the name stops resolving.
On the other side, use resolvers that validateSigning takes care of those looking for you. To protect your own operation, what counts is the resolver your network uses checking the signatures it receives.

In practice

It is notarization in a chain: each level attests the signature of the level below, up to a first link everyone already knows in advance. And that is what makes the model workable at planetary scale: trust does not have to be negotiated domain by domain, it descends from a single known point. So the question to ask is never whether you trust that domain, it is whether its chain closes all the way to the top.

How Zamak handles DNSSEC

Zamak Technologies treats DNSSEC as two separate decisions, because that is what they are: signing the client's zone, with the link correctly published at the registrar and key rotation automated and monitored, and on the other side making sure the resolvers the operation uses check signatures. It is the foundation email authentication stands on, since DMARC and the other authentication records are DNS answers, and it is the direct answer to DNS cache poisoning. It is not to be confused with DNS filtering, which decides whether a domain should be blocked: here the question is whether the answer is authentic. Anyone who wants to see the state of their own domain before any conversation can run the free domain check, which shows whether the zone is signed alongside the rest of the authentication. This is part of Managed Cybersecurity in the Zamak Method.

Frequently asked questions about DNSSEC

Does DNSSEC encrypt my DNS queries?

No, and this is the most common confusion on the subject. The standard says explicitly that DNSSEC was not designed to provide confidentiality. It guarantees the authenticity and integrity of the answer, not the secrecy of the question. Hiding which name you looked up is the business of other technologies, the ones that encrypt the query in transit: DNS over HTTPS (DoH) and DNS over TLS (DoT). They complement DNSSEC rather than replace it: they hide the question, it authenticates the answer.

If I sign my domain, is my company protected?

What gets protected is your name's reputation, not your browsing. Signing lets whoever looks for you detect a forged answer, which includes the servers delivering your email. To protect your own operation, what counts is the resolver your network uses validating the signatures it receives. They are two independent decisions.

What happens if I get the rollout wrong?

The domain stops resolving for everyone who validates signatures, which is considerably worse than having no DNSSEC. The two classic mistakes are publishing the link with the wrong value at the registrar and letting signatures expire. That is why the sequence matters and expiry monitoring is not optional.

Is it worth it if few resolvers validate?

A fair question, and measurement answers it better than intuition does. APNIC measured 36% validation in 2025, against 7% of delegations signed. Read the two together and the question flips: there is no shortage of checkers, there is a shortage of signers. A third of the internet would already catch a forged answer issued in your domain's name today, with nothing required of you beyond signing, and most domains simply give those people nothing to check. And signing is a prerequisite for the technologies that tie a certificate to DNS, such as DANE (DNS-based Authentication of Named Entities), so what you publish today keeps paying off downstream.

What is the difference between DNSSEC and DNS filtering?

They answer opposite questions. DNS filtering decides whether a domain is malicious and should be blocked, so it deals with the destination. DNSSEC has no opinion on the destination: it checks whether the answer about that name is authentic. A malicious domain can have flawless DNSSEC, and a legitimate domain can have its answer forged.

How do I know whether my domain already has DNSSEC?

The check is public and takes seconds: query the domain's DNSKEY and DS records. Both have to exist. A signed zone with no DS published at the level above is the most common half-finished project, and in that state no validating resolver can check anything. Check signature expiry too, because an expired RRSIG takes the name down with the same effect as a botched rollout.