---
title: "What is DNSSEC?"
canonical: https://enum.co/learn/what-is-dnssec
locale: en
topic: Network
publishedAt: 2026-10-20
updatedAt: 2026-10-20
author: "Max Heyer"
summary: "DNSSEC adds digital signatures to DNS records, so resolvers can check that an answer came from the zone owner and was not changed on the way."
---

# What is DNSSEC?

DNSSEC adds digital signatures to DNS records, so resolvers can check that an answer came from the zone owner and was not changed on the way.

After reading this you will be able to:

- Explain how signatures let resolvers detect forged DNS answers
- Follow the chain of trust from the root to a zone
- Avoid outages when turning DNSSEC on or changing providers

## What is DNSSEC?

DNSSEC (DNS Security Extensions) is a set of additions to DNS that lets a zone sign its records with a private key. A validating resolver checks each signature against the zone's public key, so it can tell whether an answer really came from the zone owner and arrived unchanged. It also proves when a name does not exist.

Think of a sealed letter from your bank. Anyone can read the envelope, but a broken or missing seal tells you someone tampered with it. DNSSEC is that seal: it does not hide the contents, it only shows whether they are genuine.

Plain DNS has no such check. A resolver accepts the first answer that looks right, which is what cache poisoning attacks exploit to send users to the wrong IP address.

## How does DNSSEC work?

Signing adds a few record types to the zone. Each one has a narrow job.

### DNSKEY and RRSIG

DNSKEY records hold the zone's public keys. Every set of records with the same name and type gets an RRSIG record, a signature with a start and an expiry time. Many zones use two keys: a key signing key (KSK) that signs only the DNSKEY set, and a zone signing key (ZSK) that signs everything else.

The split means the ZSK can be replaced often without involving anyone outside the zone. Replacing the KSK needs a change at the parent zone.

### DS and the chain of trust

A resolver cannot trust a key just because the zone publishes it. So the parent zone, such as .com, holds a DS record with a hash of the child's KSK, and signs that DS record with its own keys. The parent's keys are vouched for by its parent in the same way, up to the root.

Validating resolvers ship with the root key as a trust anchor. From there they follow DS records down to your zone, and every link must check out.

### NSEC and NSEC3

To prove that a name does not exist, the zone returns a signed NSEC or NSEC3 record. NSEC covers the gap between two existing names, and NSEC3 does the same with hashed names, so an attacker cannot fake a "no such domain" answer. Plain NSEC also lets anyone walk the chain and list every name in the zone.

## What DNSSEC does and does not protect

DNSSEC solves one problem: trusting the content of DNS answers. It leaves others open.

- It protects against forged or modified answers and fake "does not exist" replies.
- It does not encrypt queries or answers. Anyone on the path can still see which names you look up.
- It does not stop denial-of-service attacks. Signed answers are larger, and validation adds crypto work an attacker can target.
- It does not secure the hop between your device and its resolver, unless the device validates itself.

When validation fails, a validating resolver returns SERVFAIL instead of the bad answer. That is the point, but it also means a mistake at the registrar takes the whole domain offline for those users.

The most common mistake happens during a provider change. If the old DS record stays at the registrar while the new provider signs with different keys, validation fails. The simple path is to remove the old DS and switch nameservers, wait for caches to expire, then publish the new DS.

## How enum handles DNSSEC

[enum DNS](/dns) signs zones online, so key handling and re-signing are done for you. Turn on signing for an active zone, and enum returns the DS records or the DNSKEY to publish at your registrar. DNSSEC is free on every account, and a CNAME at the zone apex is flattened to signed A and AAAA records.

## FAQ

**Does DNSSEC encrypt my DNS traffic?**
No. DNSSEC signs records but sends them in plain text. Anyone on the network path can still read the names you query. Encrypting the query between client and resolver is a separate job for other protocols.

**What happens if the DS record at my registrar is wrong?**
Validating resolvers cannot build the chain of trust, so they mark your zone as bogus and return SERVFAIL. Users behind those resolvers cannot reach your domain until the DS record matches a key the zone uses.

**Do I need DNSSEC on every domain?**
Not strictly, but we would turn it on for any domain that handles logins, payments or email. Signing costs little once the provider manages the keys, and it removes a whole class of forged-answer attacks.
