DNSSEC: How DNS Security Works and Why You Need It

DNS (Domain Name System) does not authenticate responses by default. This means an attacker can forge a DNS response and redirect users to a phishing site. DNSSEC solves this by adding cryptographic signatures to DNS records.

The Problem: Unprotected DNS

Standard DNS uses UDP without encryption or authentication, making it vulnerable to several attack types:

DNS Cache Poisoning

An attacker sends forged DNS responses to a recursive resolver. If successful, the resolver caches the wrong IP address, and all its users receive the spoofed response.

Man-in-the-Middle

The attacker intercepts DNS queries between client and resolver and substitutes the response. The user receives a phishing server's IP instead of the real one.

BGP Hijacking

At the routing level, an attacker redirects traffic to a DNS server through their infrastructure, gaining the ability to modify responses.

What Is DNSSEC

DNSSEC (DNS Security Extensions) is a set of DNS extensions defined in RFC 4033–4035. DNSSEC does not encrypt DNS queries but adds digital signatures to DNS records, allowing resolvers to verify their authenticity and integrity.

How DNSSEC Works

Chain of Trust

DNSSEC builds a chain of trust from the DNS root zone to a specific domain:

1. Root zone (.) — signs records about TLDs (.com, .org, .net)
2. TLD (.com) — signs records about second-level domains (example.com)
3. Domain (example.com) — signs its own records (A, MX, TXT, etc.)

Each level stores the public key of the next level, forming an unbroken chain of signatures.

DNSSEC Record Types

Record	Purpose
RRSIG	Digital signature of a DNS record set. Each record set (e.g., all A records for a domain) is signed separately.
DNSKEY	Zone's public key. Used to verify RRSIG signatures.
DS	Delegation Signer — hash of a child zone's key, stored in the parent zone. Links the chain of trust.
NSEC / NSEC3	Authenticated Denial of Existence — proof that a requested record doesn't exist (prevents "no such domain" spoofing).

KSK and ZSK

DNSSEC uses two types of keys:

• KSK (Key Signing Key) — signs the zone's DNSKEY records. Its hash (DS record) is stored in the parent zone. Changed infrequently.
• ZSK (Zone Signing Key) — signs all other zone records (A, MX, TXT, etc.). Rotated regularly (every 1–3 months).

Validation Process

When a DNSSEC-validating resolver receives a DNS response:

1. Receives the A record (e.g., site's IP) along with its RRSIG
2. Requests the zone's DNSKEY and verifies the RRSIG signature
3. Validates DNSKEY through the DS record from the parent zone
4. Walks up the chain to the root key (trust anchor)
5. If all signatures are valid — the response is considered authentic
6. If any signature fails — the response is rejected (SERVFAIL)

How to Check DNSSEC

Command Line

# Check DNSSEC presence
dig example.com +dnssec +short

# Full check with signatures
dig example.com DNSKEY +dnssec
dig example.com DS

Online Tools

The DNS Lookup tool on Enterno.io displays DNSSEC records (DNSKEY, DS, RRSIG) for any domain.

How to Enable DNSSEC

Through Your Registrar

Most major registrars support DNSSEC:

1. Enable DNSSEC signing on your DNS hosting (Cloudflare, Route53, etc.)
2. Copy the DS record from your DNS hosting
3. Add the DS record at your domain registrar

Cloudflare

Cloudflare enables DNSSEC with a single click. The DS record is generated automatically — you just need to add it at your registrar.

DNSSEC Limitations

• Does not encrypt queries — DNSSEC verifies authenticity, but DNS queries are visible to your ISP. For encryption, use DoH (DNS over SSL/TLS проверку) or DoT (DNS over TLS).
• Increases response size — signatures add volume, which can cause UDP fragmentation issues.
• NSEC and zone walking — NSEC allows enumerating all zone records. NSEC3 solves this with hashing.
• Key rotation complexity — incorrect KSK rotation can take down an entire domain.

DNSSEC + DoH/DoT

For complete DNS protection, combine:

• DNSSEC — response authenticity (server-side signing)
• DoH / DoT — channel encryption between client and resolver (confidentiality)

Together they provide both authenticity and confidentiality for DNS queries.