What Is DNSSEC and How Does It Protect DNS?

DNSSEC is a set of security extensions for the Domain Name System that allows DNS data to be digitally signed and validated.

Its purpose is to help a validating DNS resolver determine whether the DNS information it receives is authentic and has not been modified since it was signed by the authoritative zone.

DNSSEC stands for:

Domain Name System Security Extensions

Traditional DNS was designed primarily to provide fast and distributed name resolution. It was not originally designed with strong cryptographic authentication of DNS data.

DNSSEC adds that authentication layer using public-key cryptography and new DNS record types such as:

• DNSKEY
• RRSIG
• DS
• NSEC
• NSEC3

When correctly configured, DNSSEC can help protect users against certain forms of forged DNS data, including attacks that attempt to poison resolver caches or redirect users by supplying false DNS answers.

What Problem Does DNSSEC Solve?

A normal DNS lookup may ask:

What is the IP address of example.com?

An authoritative DNS server may answer:

example.com. 3600 IN A 192.0.2.10

Without DNSSEC validation, a resolver does not have a built-in cryptographic method to prove that this answer is authentic.

If an attacker successfully injects a forged DNS response into the lookup process or cache, the resolver could potentially return a false address.

For example:

Expected:
example.com → 192.0.2.10

Forged:
example.com → 198.51.100.90

The user may then be sent to infrastructure controlled by someone else.

DNSSEC addresses this problem by adding digital signatures that validating resolvers can verify.

What Does DNSSEC Protect?

DNSSEC primarily provides two important protections for DNS data:

Data origin authentication

A validating resolver can determine whether the DNS data came from the zone that is supposed to be authoritative for it.

Data integrity

A resolver can check whether the signed DNS data has been modified since the zone owner signed it.

This means DNSSEC is designed to answer questions such as:

Did this DNS answer come from the correct signed zone?

Has this DNS data been changed after it was signed?

DNSSEC does not simply label a domain as “safe.” It verifies DNS data.

Does DNSSEC Encrypt DNS Queries?

No.

This is one of the most common misunderstandings about DNSSEC.

DNSSEC does not normally encrypt the DNS query or hide the domain name being requested.

For example, a network observer may still be able to see that a resolver is querying:

example.com

DNSSEC focuses on authenticity and integrity rather than confidentiality.

Protocols such as DNS over HTTPS and DNS over TLS address a different problem by encrypting DNS traffic between a client and a resolver.

DNSSEC vs DNS over HTTPS

DNSSEC and DNS over HTTPS, commonly called DoH, solve different security problems.

DNSSEC

Helps verify that DNS data is authentic and has not been modified.

DNS over HTTPS

Encrypts DNS traffic between the client and the recursive resolver.

A DNS setup can use both.

For example:

Browser
   ↓ encrypted DoH connection
Recursive resolver
   ↓ DNSSEC validation
Authoritative DNS

DoH protects the transport path to the resolver. DNSSEC validates the DNS data itself.

How Does DNSSEC Work?

At a high level, a DNSSEC-enabled zone signs its DNS record sets using a private cryptographic key.

The corresponding public key is published in DNS using a DNSKEY record.

The digital signature is published using an RRSIG record.

A validating resolver can retrieve:

• The requested DNS data
• The RRSIG signature
• The relevant DNSKEY public key

It can then cryptographically verify the signature.

A simplified flow is:

DNS record
     ↓
Signed with private key
     ↓
RRSIG published
     ↓
DNSKEY public key published
     ↓
Resolver verifies signature
     ↓
DNS data validated

What Is a DNSKEY Record?

A DNSKEY record publishes a public key used by DNSSEC.

A simplified DNSKEY record may look like:

example.com. 3600 IN DNSKEY 257 3 13 Base64PublicKey...

The record contains several fields including:

• Flags
• Protocol
• Algorithm
• Public key data

The public key allows validating resolvers to verify signatures created using the matching private key.

The private key is not published in DNS.

What Is an RRSIG Record?

RRSIG stands for Resource Record Signature.

An RRSIG record contains the digital signature for a DNS resource record set.

For example, if a zone contains:

example.com. IN A 192.0.2.10

DNSSEC can publish an RRSIG covering that A record set.

A validating resolver uses the appropriate DNSKEY to verify the signature.

If validation succeeds, the resolver has cryptographic evidence that the signed data has not been altered.

What Is a DS Record?

A DS record helps connect a signed child zone to its parent and forms an important part of the DNSSEC chain of trust.

DS stands for:

Delegation Signer

For a domain such as:

example.com

the DS record is normally published in the parent zone:

.com

The DS record contains information derived from a DNSKEY in the child zone.

A validating resolver can use this relationship to determine whether the child zone's DNSKEY is trusted by the parent.

What Is the DNSSEC Chain of Trust?

DNSSEC validation depends on a chain of trust through the DNS hierarchy.

Conceptually:

DNS root
   ↓
.com
   ↓
example.com

The root zone is signed.

The parent zone can contain a DS record for a signed child zone.

The child publishes its DNSKEY records.

The resolver verifies each link until it reaches the DNS record being requested.

A simplified validation path might look like:

Trusted root key
       ↓
Root validates .com
       ↓
.com DS validates example.com DNSKEY
       ↓
example.com DNSKEY validates RRSIG
       ↓
A record validated

This chain allows trust to move from a known trust anchor down through delegated DNS zones.

What Is a DNSSEC Trust Anchor?

A trust anchor is a cryptographic key or key-related value that a validating resolver already trusts.

For the public DNS, the root zone key acts as the starting point for normal DNSSEC validation.

The resolver does not need to trust every domain individually.

Instead, it follows the chain of trust downward from the trusted root.

What Is the Root KSK?

The DNSSEC root zone uses a Key Signing Key, commonly abbreviated as KSK.

This key plays a central role in the root DNSSEC trust anchor.

Validating resolvers need an appropriate root trust anchor so they can begin verifying the DNSSEC hierarchy.

Root keys are occasionally rolled over as part of long-term cryptographic maintenance. Such changes are coordinated carefully because an outdated trust anchor can cause DNSSEC validation failures.

KSK vs ZSK

DNSSEC operations often distinguish between two key roles.

Zone Signing Key

A Zone Signing Key, or ZSK, is commonly used to sign ordinary DNS record sets in the zone.

Key Signing Key

A Key Signing Key, or KSK, is commonly used to sign the DNSKEY record set itself.

This separation can simplify key management and rollover procedures.

However, DNSSEC does not require every deployment to use two completely separate keys. Some configurations use a combined signing key.

What Is NSEC?

DNSSEC also needs a way to prove that a DNS name or record does not exist.

Without this, an attacker might attempt to forge a negative DNS response.

NSEC records provide authenticated denial of existence.

This allows a resolver to validate answers such as:

There is no A record for this hostname.

or:

This hostname does not exist.

The negative response itself can therefore be protected by DNSSEC.

What Is NSEC3?

NSEC3 is an alternative mechanism for authenticated denial of existence.

One motivation for NSEC3 was to make straightforward enumeration of every name in a signed zone more difficult.

Instead of exposing names directly in the same way as NSEC, NSEC3 uses hashed names.

Both mechanisms relate to proving that requested DNS data does not exist.

What Happens During DNSSEC Validation?

Suppose a user requests:

example.com A

A validating resolver may receive:

• The A record
• An RRSIG covering the A record set

The resolver also obtains the required DNSKEY information and follows the DS records through the delegation chain.

It verifies:

1. The signature matches the DNS data.
2. The signature is within its valid time period.
3. The DNSKEY used for validation is trusted through the chain.
4. The delegation information is consistent.

If those checks succeed, the answer is treated as DNSSEC-valid.

Secure, Insecure, and Bogus DNSSEC Results

DNSSEC validators commonly distinguish among several states.

Secure

The data is signed and the validator can successfully verify the chain of trust.

Insecure

The domain is not DNSSEC-signed, and there is no authenticated expectation that it should be signed.

This is not the same as a validation failure.

Bogus

The domain is expected to validate, but the cryptographic validation fails.

A validating resolver normally treats bogus data as an error rather than returning it as trustworthy DNS information.

Why Can Broken DNSSEC Make a Website Look Offline?

One of the most important operational risks of DNSSEC is misconfiguration.

Imagine that the parent zone publishes a DS record for example.com.

This tells validating resolvers that the child zone should be DNSSEC-signed with a matching key.

If the child zone no longer contains the correct DNSKEY or signatures, validation fails.

A validating resolver may then return an error instead of the domain's A record.

The web server itself can still be completely healthy.

The failure occurs before the browser ever learns the server's IP address.

What Does a DNSSEC Failure Look Like?

Users may report:

• The website does not load.
• The domain works on some DNS resolvers but not others.
• Email suddenly stops resolving.
• The domain returns SERVFAIL.
• DNS diagnostics report a broken chain of trust.

A common clue is that the domain works through a non-validating DNS path but fails through a resolver that performs DNSSEC validation.

Why Does DNSSEC Often Return SERVFAIL When Broken?

A validating resolver cannot safely return DNS data that it expected to authenticate but could not validate.

Instead, the lookup may fail.

To the end user, this frequently appears as:

SERVFAIL

This can be confusing because the authoritative server may still appear to return ordinary A or MX records when queried without validation.

Common DNSSEC Configuration Problems

The DS record does not match the DNSKEY

This is one of the most serious DNSSEC errors.

The parent says:

Trust this child key.

but the child publishes a different key.

The chain of trust breaks.

The DNS provider changed but the old DS record remains

This often happens during nameserver migrations.

Suppose the old DNS provider signed the zone.

You move the domain to a new provider but leave the previous DS record at the registrar.

The new provider may use different DNSSEC keys or may not have DNSSEC enabled at all.

Validating resolvers still expect the child zone to match the old DS information, so validation fails.

RRSIG signatures expired

RRSIG records include signature validity periods.

If a signed zone is not refreshed correctly and signatures expire, validating resolvers can reject the data.

DNSKEY records are missing

A zone may still contain signatures but no longer publish the required key used to validate them.

One authoritative nameserver serves different signed data

All authoritative servers should serve consistent DNSSEC information.

If one nameserver has outdated keys or signatures, validation may behave inconsistently.

DNSSEC was enabled only partially

For example, the zone may be signed while the parent DS record was never added.

In that case, the zone may contain DNSSEC records but there is no complete public chain of trust from the parent.

DNSSEC and Nameserver Migrations

Nameserver migrations require extra care when DNSSEC is enabled.

A normal DNS migration already involves:

• NS records
• Parent delegation
• DNS record synchronization
• Resolver caching

DNSSEC adds:

• DNSKEY records
• DS records
• RRSIG records
• Key rollover considerations

If these are handled incorrectly, the new authoritative DNS can be online and still fail validation.

Should You Disable DNSSEC Before Changing DNS Providers?

There is no universal rule that DNSSEC must always be disabled before every provider migration.

The correct procedure depends on whether both providers support coordinated DNSSEC migration.

Some platforms provide processes that preserve the chain of trust while keys change.

Other migrations are simpler if DNSSEC is carefully removed first and re-enabled after the new DNS system is stable.

Always follow the DNS provider and registrar's documented migration procedure rather than deleting DS or DNSKEY records at random.

DNSSEC and the Registrar

The registrar often provides the interface used to submit DS information to the parent registry.

Your DNS provider may generate the required DS details, while your registrar publishes them through the domain's parent zone.

Depending on the setup, DNSSEC configuration may therefore involve both:

• Your DNS hosting provider
• Your domain registrar

This is one reason users sometimes enable DNSSEC at the DNS provider but do not complete the process at the registrar.

What Information Is in a DS Record?

A DS record contains several fields.

A simplified example may look like:

example.com. IN DS 12345 13 2 ABCDEF1234...

The fields include:

• Key tag
• Algorithm
• Digest type
• Digest

The digest is derived from a DNSKEY in the child zone.

The validator uses this information to connect the parent delegation to the child's DNSSEC key.

What Information Is in an RRSIG Record?

An RRSIG includes information such as:

• The record type being signed
• The DNSSEC algorithm
• The key tag
• Signature inception time
• Signature expiration time
• The signer name
• The digital signature

The validity period is important because DNSSEC signatures are not intended to remain valid forever.

Does DNSSEC Protect Against DNS Cache Poisoning?

DNSSEC was designed specifically to allow resolvers to detect forged DNS information when the relevant chain of trust can be validated.

If an attacker injects a false record without a valid signature, a validating resolver should reject it.

This makes DNSSEC an important defense against attacks that rely on replacing authentic DNS data with forged answers.

Does DNSSEC Protect a Website From Hacking?

No.

DNSSEC protects DNS data integrity and authenticity.

It does not protect against:

• Vulnerable website software
• Weak passwords
• SQL injection
• Malware on the server
• Compromised administrator accounts
• DDoS attacks
• Application vulnerabilities

A domain can have perfectly configured DNSSEC while the website application itself remains insecure.

Does DNSSEC Replace HTTPS?

No.

DNSSEC and HTTPS protect different parts of the connection.

DNSSEC helps validate DNS information.

HTTPS uses TLS to authenticate and encrypt the connection between the browser and web server.

A secure web setup can use both:

DNSSEC
   ↓
Authentic DNS resolution
   ↓
HTTPS
   ↓
Encrypted browser-to-server connection

Does DNSSEC Protect Email?

DNSSEC can help authenticate DNS records used by email systems, but it does not replace email-specific security protocols.

Email still relies on mechanisms such as:

• SPF
• DKIM
• DMARC
• TLS
• Mail server authentication

DNSSEC can strengthen confidence in the DNS data behind some of these systems when validation is performed.

Does Every Domain Need DNSSEC?

DNSSEC can provide useful protection, but deployment should be done correctly.

A domain owner should not enable DNSSEC simply because the switch exists in a control panel without understanding how the DNS provider and registrar handle keys and DS records.

A broken DNSSEC configuration can make a domain unreachable to validating resolvers.

If the provider supports automatic DNSSEC management and the registrar integration is reliable, deployment can be relatively straightforward.

How to Check Whether a Domain Uses DNSSEC

You can inspect DNSSEC-related records using DNS lookup tools.

Useful records include:

• DNSKEY
• DS
• RRSIG

However, finding a DNSKEY record alone does not prove that the entire chain of trust is valid.

A proper DNSSEC check should verify:

1. The zone is signed.
2. Required signatures are present.
3. The DNSKEY is valid.
4. The parent DS record exists when expected.
5. The DS matches the child key.
6. The chain reaches a trusted anchor.

How to Troubleshoot DNSSEC

Step 1: Check whether a DS record exists

If the parent contains a DS record, validating resolvers expect the child zone to participate correctly in DNSSEC.

Step 2: Check DNSKEY records

Confirm the authoritative child zone publishes the expected DNSKEY data.

Step 3: Compare DS and DNSKEY

Verify that the parent DS corresponds to the correct child key.

Step 4: Inspect RRSIG records

Confirm signatures exist for the required record sets and have not expired.

Step 5: Query every authoritative nameserver

Make sure all servers publish consistent DNSSEC data.

Step 6: Test using a validating resolver

A validating resolver can reveal whether the chain is actually accepted.

Step 7: Check recent DNS provider changes

If DNSSEC stopped working immediately after a migration, stale DS information is a strong candidate.

Why Does DNSSEC Work on One Resolver but Not Another?

Different DNS resolvers may have different validation policies.

Some resolvers perform full DNSSEC validation.

Others may not validate or may be configured differently.

A broken DNSSEC domain can therefore appear to work through one resolver while failing through another.

This is an important clue during troubleshooting.

What Is the AD Bit?

DNSSEC adds an Authenticated Data bit, commonly called the AD bit, to DNS responses.

A validating resolver may set this bit when it has successfully authenticated the DNS data according to DNSSEC validation rules.

The presence and meaning of the AD bit depends on the resolver and the trust relationship between the client and that resolver.

What Is the CD Bit?

CD stands for Checking Disabled.

A DNS client can use this bit to tell a recursive resolver that it wants DNSSEC validation checking disabled for that query.

This is mainly relevant to software performing its own DNSSEC processing or diagnostic testing.

Does DNSSEC Make DNS Slower?

DNSSEC adds more records and cryptographic validation work.

Responses can be larger because they may include:

• RRSIG records
• DNSKEY records
• DS records
• NSEC or NSEC3 records

Modern DNS infrastructure is designed to handle this, and recursive resolvers cache DNSSEC data just like other DNS information.

For most end users, the added validation is not noticeable during normal browsing.

Can DNSSEC Cause Larger DNS Responses?

Yes.

Digital signatures and public keys add data to DNS responses.

This is one reason modern DNS infrastructure needs to properly support EDNS and TCP fallback when required.

Networks that incorrectly block larger DNS responses or TCP DNS can create failures that only become visible with DNSSEC-enabled domains.

DNSSEC and DNS TTL

DNSSEC-related records have TTL values and can be cached.

This matters when changing keys or correcting an incorrect DS record.

For example, removing a bad DS record from the parent may not instantly change what every resolver sees if relevant delegation information is still cached.

Key rollovers therefore need to account for DNS caching as well as cryptographic validity.

Can DNSSEC Expire?

DNSSEC itself does not “expire” as a feature, but individual RRSIG signatures have validity periods.

If signatures are not regenerated before expiration, the signed DNS data can become invalid to validating resolvers.

Managed DNS providers normally automate signature generation and renewal.

Operators running their own authoritative DNSSEC infrastructure must monitor this carefully.

Common DNSSEC Mistakes

Enabling DNSSEC without publishing the DS record

The zone may be signed, but there is no complete chain of trust from the parent.

Publishing DS before the child zone is ready

Validating resolvers may immediately expect signatures that are not available.

Changing DNS provider without updating DS

The parent still trusts the old key while the new provider serves a different one.

Removing DNSKEY too early during rollover

Cached signatures or DS data may still depend on the old key.

Allowing RRSIG records to expire

The data may become bogus even though the underlying A, MX, or TXT records are correct.

Assuming DNSSEC encrypts DNS

DNSSEC authenticates DNS data. It does not provide DNS query privacy.

Assuming DNSSEC makes a website secure

It only protects the DNS layer against specific classes of manipulation.

A Practical DNSSEC Migration Checklist

1. Confirm whether DNSSEC is currently enabled.
2. Inspect the existing DS record at the parent.
3. Identify the current DNSKEY records.
4. Review the new provider's DNSSEC migration instructions.
5. Prepare the new authoritative zone completely.
6. Confirm DNSSEC signatures are valid at the new provider.
7. Coordinate the DS update or removal according to the migration method.
8. Keep both DNS environments available where required.
9. Test through validating recursive resolvers.
10. Confirm the full chain of trust after migration.

Frequently Asked Questions

What is DNSSEC?

DNSSEC is a set of DNS security extensions that uses digital signatures to provide origin authentication and integrity protection for DNS data.

What does DNSSEC stand for?

Domain Name System Security Extensions.

Does DNSSEC encrypt DNS?

No. DNSSEC authenticates DNS data but does not normally hide the DNS query or response contents.

Does DNSSEC stop DNS spoofing?

DNSSEC allows validating resolvers to detect forged DNS data when the chain of trust is correctly configured.

What is a DNSKEY record?

A DNSKEY record publishes a public key used to verify DNSSEC signatures.

What is an RRSIG record?

An RRSIG contains a digital signature covering a DNS resource record set.

What is a DS record?

A DS record is published in the parent zone and links the parent's trust to a DNSKEY in the signed child zone.

Why does DNSSEC cause SERVFAIL?

If a resolver expects DNSSEC validation to succeed but detects an invalid signature, incorrect DS record, missing key, or another broken trust relationship, it may return SERVFAIL rather than the DNS data.

Does DNSSEC replace SSL?

No. DNSSEC protects DNS data. TLS certificates and HTTPS protect browser-to-server connections.

Should I enable DNSSEC?

DNSSEC can add useful protection when your DNS provider and registrar support it correctly. It should be deployed with an understanding of key management and DS records because misconfiguration can cause DNS failures.

How do I know whether DNSSEC is working?

Check the DNSKEY, DS, and RRSIG records and verify the complete chain using a DNSSEC-validating resolver or diagnostic tool.

Final Thoughts

DNSSEC adds cryptographic authentication to DNS data.

It allows validating resolvers to verify that DNS information originated from the expected signed zone and that the data has not been modified after signing.

The system relies on several DNSSEC-specific records, including DNSKEY, RRSIG, and DS, together with a chain of trust that normally begins at the signed DNS root.

The most important operational lesson is that DNSSEC must be treated as part of DNS infrastructure rather than as a simple security checkbox.

A mismatched DS record, expired signature, missing DNSKEY, or incomplete provider migration can make an otherwise healthy domain fail resolution for validating users.

When troubleshooting DNSSEC, examine the complete chain: parent DS record, child DNSKEY, RRSIG signatures, authoritative nameservers, and resolver validation results.

Use DomainScan's DNS Lookup and DNS Delegation Check tools to inspect DNSSEC-related records and investigate whether the authoritative DNS and parent delegation are configured consistently.