DNSSEC Explained: DNSKEY, DS, RRSIG, Chain of Trust and DNSSEC Validation

The Domain Name System was designed to translate human-readable names such as example.com into information computers can use, including IPv4 and IPv6 addresses.

Traditional DNS, however, was not originally designed to cryptographically prove that the DNS data received by a resolver is authentic.

That creates an important security question:

How can a resolver verify that a DNS answer actually came from the legitimate DNS zone and was not modified after it was signed?

DNSSEC — Domain Name System Security Extensions — addresses this problem by adding cryptographic signatures and a hierarchical chain of trust to DNS.

DNSSEC does not replace DNS. It extends it.

It also does not encrypt DNS queries or responses. Instead, DNSSEC provides mechanisms for data-origin authentication, data integrity, and authenticated denial of existence.

At the center of DNSSEC are several important DNS record types:

• DNSKEY
• DS
• RRSIG
• NSEC
• NSEC3

Together with trust anchors and validating resolvers, these records allow a resolver to determine whether DNS data can be cryptographically authenticated.

This guide explains how DNSSEC works from the root of the DNS hierarchy to an individual signed domain, including DNSKEY records, DS records, RRSIG signatures, KSK and ZSK operational roles, NSEC and NSEC3, trust anchors, validation states, key rollover, common DNSSEC failures, and practical troubleshooting with dig.

For the DNS foundation, start with DNS Explained. For the underlying Internet protocol stack, see TCP/IP Explained.

What Is DNSSEC?

DNSSEC stands for Domain Name System Security Extensions.

It is a collection of extensions to DNS that allows DNS data to be cryptographically authenticated.

The core DNSSEC standards are defined primarily by RFC 4033, RFC 4034, and RFC 4035.

Traditional DNS might provide an answer such as:

www.example.com. 300 IN A 192.0.2.10

Without DNSSEC validation, a resolver does not use DNSSEC signatures to cryptographically verify that this RRset was signed by the expected DNS zone.

DNSSEC adds signatures.

Conceptually:

A RRset
   |
   v
Digital Signature
   |
   v
RRSIG

A validating resolver can then use the appropriate public DNSSEC key to verify that signature.

The high-level process becomes:

DNS Data
   |
   v
RRSIG
   |
   v
DNSKEY
   |
   v
Cryptographic Validation

But verifying one zone’s public key is not enough.

The resolver must also determine whether it should trust that key.

That is where the DNSSEC chain of trust becomes essential.

What Problem Does DNSSEC Solve?

Consider an ordinary DNS lookup:

Client
   |
   v
Recursive Resolver
   |
   v
DNS Infrastructure
   |
   v
192.0.2.10

Without DNSSEC validation, the resolver has no DNSSEC-based cryptographic proof that the answer was signed by the expected zone.

DNSSEC changes the security model.

The authoritative zone signs its DNS RRsets using private cryptographic keys.

The corresponding public keys are published through DNSKEY records.

A validating resolver can verify the signatures.

Conceptually:

RRset
  |
  v
RRSIG
  |
  v
DNSKEY
  |
  v
Signature valid?
  |
  +------ YES ------> Authenticated data
  |
  +------ NO -------> Validation failure

DNSSEC therefore provides two major properties:

Data origin authentication — evidence that signed DNS data originated from the expected signed zone.

Data integrity — evidence that the signed data has not been modified without detection after it was signed.

DNSSEC also provides mechanisms for authenticated denial of existence, allowing resolvers to validate that a requested DNS name or record type does not exist.

DNSSEC Does Not Encrypt DNS

One of the most important DNSSEC distinctions is:

DNSSEC ≠ DNS encryption

DNSSEC provides:

Authentication
Integrity
Authenticated denial of existence

It does not provide:

Confidentiality

A DNSSEC-protected query can still be visible to systems on the network path unless another mechanism encrypts DNS transport.

Technologies designed for DNS transport confidentiality include:

DNS over HTTPS (DoH)
DNS over TLS (DoT)

These solve a different problem.

A simplified comparison:

Technology	Primary Purpose
DNSSEC	Authenticate DNS data
DoH	Encrypt DNS transport over HTTPS
DoT	Encrypt DNS transport over TLS

They can complement each other.

For example:

Client
   |
   | encrypted DNS transport
   v
Recursive Resolver
   |
   | DNSSEC validation
   v
DNS hierarchy

Encryption protects the communication channel.

DNSSEC validates the DNS data.

DNSSEC Works with RRsets

DNSSEC does not conceptually sign an entire DNS zone with one giant signature.

It signs resource-record sets — RRsets.

Suppose:

example.com. 300 IN A 192.0.2.10
example.com. 300 IN A 192.0.2.11

These records form an A RRset.

DNSSEC creates an RRSIG covering that RRset.

Conceptually:

example.com A RRset
       |
       +---- 192.0.2.10
       |
       +---- 192.0.2.11
       |
       v
     RRSIG

A validating resolver uses the corresponding DNSKEY to authenticate the signature over the canonicalized RRset.

This RRset-based model is fundamental to understanding DNSSEC.

DNSSEC Records Explained

The core DNSSEC architecture introduces several important record types.

Record	Purpose
DNSKEY	Publishes DNSSEC public keys
RRSIG	Contains signatures covering RRsets
DS	Connects a parent zone to a child’s DNSKEY
NSEC	Authenticated proof of nonexistence
NSEC3	Hashed form of authenticated denial mechanism

The first three are central to understanding the chain of trust:

DS
 ↓
DNSKEY
 ↓
RRSIG
 ↓
RRset

NSEC and NSEC3 handle the equally important question:

How can a resolver cryptographically validate that something does not exist?

What Is an RRSIG Record?

RRSIG means Resource Record Signature.

It stores a digital signature associated with a particular RRset.

Suppose a signed zone contains:

example.com. 300 IN A 192.0.2.10

DNSSEC adds an RRSIG covering the A RRset.

Conceptually:

A RRset
   |
   v
Private key signs canonical RRset data
   |
   v
RRSIG

The resolver receives:

A RRset
+
RRSIG

and uses the appropriate DNSKEY public key to verify the signature.

Conceptually:

RRset + RRSIG
      |
      v
    DNSKEY
      |
      v
Cryptographic verification

An RRSIG identifies important information including:

• The record type it covers
• DNSSEC algorithm
• Number of labels
• Original TTL
• Signature expiration time
• Signature inception time
• Key tag
• Signer’s name
• Cryptographic signature

The validity period is particularly important.

DNSSEC signatures are not valid forever.

RRSIG Inception and Expiration

An RRSIG includes:

Signature Inception
Signature Expiration

Conceptually:

Before inception
     |
     X
Signature not yet valid

Inception
     |
     v
VALID WINDOW
     |
     v
Expiration

After expiration
     |
     X
Signature no longer valid

A validating resolver checks whether the signature is valid for the relevant time.

This means correct system time matters to DNSSEC validation.

A seriously incorrect clock can cause signatures to appear:

not yet valid

or:

expired

even when the zone itself has been configured correctly.

What Is a DNSKEY Record?

A DNSKEY record publishes a public key used in DNSSEC authentication.

The authoritative zone uses the corresponding private key to create signatures.

The public key is published in DNS.

Conceptually:

Private Key
    |
    | signs
    v
   RRset
    |
    v
  RRSIG


Public Key
    |
    v
  DNSKEY
    |
    | verifies
    v
  RRSIG

The private key must remain protected.

The public DNSKEY is intentionally distributed through DNS so validators can use it.

A simplified DNSKEY presentation format looks like:

example.com. IN DNSKEY flags protocol algorithm public-key

The major fields include:

Flags
Protocol
Algorithm
Public Key

DNSKEY records are defined by RFC 4034.

Public Key vs Private Key

DNSSEC relies on asymmetric cryptography.

The key pair contains:

Private Key
Public Key

The private key is used for signing.

The public key is used for verification.

Conceptually:

AUTHORITATIVE SIDE

RRset
  |
  v
Private Key
  |
  v
RRSIG


VALIDATOR SIDE

RRset + RRSIG
      |
      v
Public DNSKEY
      |
      v
Verification

The private key should never be published in DNS.

The DNSKEY record contains the public key.

KSK vs ZSK

DNSSEC discussions frequently distinguish between:

KSK

and:

ZSK

These mean:

KSK — Key Signing Key

ZSK — Zone Signing Key

Traditionally, their operational roles are:

KSK
 |
 v
signs DNSKEY RRset

while:

ZSK
 |
 v
signs other authoritative RRsets

This produces an architecture such as:

KSK
 |
 v
DNSKEY RRset
 |
 +---- KSK public key
 |
 +---- ZSK public key
            |
            v
         zone RRsets

However, there is an important technical nuance:

DNSSEC validation does not fundamentally require KSK and ZSK to be separate keys.

The distinction is largely an operational key-management model.

A single key can technically perform both roles.

RFC 4033 explicitly notes that designating keys as KSK or ZSK is an operational matter and that one key can be used for both functions.

Therefore:

KSK/ZSK separation

is common operational practice, not a cryptographic requirement for every DNSSEC deployment.

Why Separate KSK and ZSK?

Historically, separating the roles can simplify key management.

A ZSK can potentially be rotated more frequently without requiring changes to the parent zone’s DS record.

The KSK is associated with the secure delegation relationship represented through the parent DS record.

Conceptually:

Parent Zone
    |
    v
   DS
    |
    v
Child KSK
    |
    v
DNSKEY RRset
    |
    v
Child ZSK
    |
    v
Zone Data

This separation can reduce the coordination required with the parent during routine zone-signing key changes.

Modern DNSSEC operations can also use other key-management models, including combined-signing-key approaches.

What Is a DS Record?

DS means Delegation Signer.

It is one of the most important records in DNSSEC because it connects a signed child zone to its parent.

Suppose:

example.com

is signed.

Its DNSKEY records exist inside the example.com zone.

But a validating resolver still needs an authenticated reason to trust the relevant child DNSKEY.

The parent .com zone can publish a DS record associated with a DNSKEY in the child zone.

Conceptually:

.com
 |
 | DS for example.com
 v
example.com
 |
 v
DNSKEY

The DS record contains information derived from the child’s DNSKEY, including a digest.

The resolver can compare the DS relationship with the child DNSKEY and continue the authentication chain.

Where Does the DS Record Live?

This is a crucial DNSSEC detail.

The DNSKEY belongs to the child zone.

The DS record belongs to the parent side of the delegation.

For:

example.com

conceptually:

.com zone
   |
   +---- DS example.com
            |
            v
      example.com zone
            |
            +---- DNSKEY

Therefore, enabling DNSSEC at a DNS hosting provider is not always sufficient by itself.

The secure delegation must also be correctly represented in the parent.

For registered domains, this commonly involves providing DNSSEC/DS information through the domain registrar, which then participates in publishing the DS through the registry infrastructure.

The exact workflow depends on the DNS provider, registrar, registry, and domain.

What Information Is in a DS Record?

A DS record contains fields including:

Key Tag
Algorithm
Digest Type
Digest

Conceptually:

example.com. IN DS
    KEYTAG
    ALGORITHM
    DIGEST-TYPE
    DIGEST

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

A validator can therefore establish the relationship:

Parent DS
    |
    | matches digest of
    v
Child DNSKEY

If that relationship cannot be validated where a secure delegation is expected, the DNSSEC chain can break.

DNSSEC Chain of Trust

The chain of trust is the central DNSSEC concept.

For a typical Internet validation path, the resolver begins with a trusted DNSSEC key for the root zone.

From there:

Root
 |
 | DS
 v
TLD
 |
 | DS
 v
Domain
 |
 v
DNSKEY
 |
 v
RRSIG
 |
 v
DNS RRset

For a domain such as:

www.example.com

the conceptual validation path is:

Root Trust Anchor
       |
       v
Root DNSKEY
       |
       v
DS for .com
       |
       v
.com DNSKEY
       |
       v
DS for example.com
       |
       v
example.com DNSKEY
       |
       v
RRSIG
       |
       v
www.example.com RRset

Each validated step provides authenticated information needed to validate the next step.

That is why DNSSEC is described as a chain of trust.

The Root Trust Anchor

Every chain needs a starting point.

A validator cannot prove the authenticity of every key by asking DNS indefinitely because that would create a circular trust problem.

It therefore begins with a trust anchor.

For normal public Internet DNSSEC validation, the root zone trust anchor is the foundation of the chain.

Conceptually:

Configured Trust Anchor
        |
        v
      Root
        |
        v
       TLD
        |
        v
      Domain

The trust anchor must be obtained and maintained through a trusted mechanism.

Once the validator trusts the root, DNSSEC allows trust to be extended downward through authenticated delegations.

The Chain Is Not Simply “DS Signs DNSKEY”

A common simplification says:

DS signs DNSKEY

That is technically misleading.

A DS record is not itself a digital signature.

Instead, it contains a digest associated with a child DNSKEY.

The parent zone’s DS RRset is signed by the parent zone’s DNSSEC key.

The child DNSKEY is then matched against the authenticated DS.

A more accurate model is:

Parent DNSKEY
      |
      v
verifies RRSIG covering
      |
      v
Parent DS RRset
      |
      v
DS digest matches
      |
      v
Child DNSKEY
      |
      v
verifies child signatures

That distinction is important when understanding DNSSEC validation correctly.

DNSSEC Validation States

A validating resolver does not simply classify everything as:

valid

or:

invalid

DNSSEC defines several meaningful security states.

Important states include:

Secure
Insecure
Bogus
Indeterminate

Understanding these states is essential for DNSSEC troubleshooting.

Secure

Secure means the validating resolver successfully established an authentication chain and validated the required signatures.

Conceptually:

Trust Anchor
    |
    v
Valid chain
    |
    v
Valid RRSIG
    |
    v
SECURE

This is the expected state for correctly configured signed DNS data with a valid chain of trust.

Insecure

Insecure does not mean:

DNS attack detected

It means the resolver has authenticated evidence that the delegation leads into an unsigned portion of the DNS tree.

Conceptually:

Signed parent
     |
     v
Authenticated proof
that no DS exists
     |
     v
Unsigned child
     |
     v
INSECURE

This is fundamentally different from a broken DNSSEC configuration.

An unsigned domain can resolve normally.

It simply does not receive DNSSEC authentication.

Bogus

Bogus means DNSSEC validation was expected but failed.

Examples can include:

• Incorrect DS record
• Missing corresponding DNSKEY
• Invalid signature
• Expired RRSIG
• Signature not yet valid
• Algorithm or validation problems
• Broken chain of trust

Conceptually:

Secure delegation expected
        |
        v
Validation attempted
        |
        X
Cryptographic validation fails
        |
        v
BOGUS

For users behind a validating resolver, a bogus domain can become effectively unreachable through DNS.

This is why incorrect DNSSEC deployment can create a serious outage.

Indeterminate

Indeterminate represents situations where the resolver cannot determine the security status using the available information or applicable trust configuration.

The exact handling can depend on validator implementation and local policy.

The important distinction is that:

Indeterminate

is not simply another name for:

Bogus

DNSSEC troubleshooting should preserve these distinctions.

Why a Broken DS Record Can Take a Domain Offline

Consider:

Parent zone
    |
    v
DS
    |
    v
Child DNSKEY

Suppose the DNS provider changes the child’s DNSSEC keys but the parent still publishes a DS referencing an old key.

Now:

Parent DS
    |
    X
No valid relationship
    |
    v
Current child DNSKEY

A validating resolver sees that the parent claims the child is secured by DNSSEC.

It therefore expects the chain to validate.

When validation fails:

DNSSEC status = BOGUS

The resolver should not simply ignore the failure and treat the answer as unsigned.

Doing so would defeat DNSSEC’s security model.

This is why changing DNS providers while DNSSEC is enabled requires careful DS management.

What Are NSEC Records?

DNSSEC must authenticate not only existing data but also the absence of data.

Suppose a client asks for:

does-not-exist.example.com

The authoritative server says:

NXDOMAIN

Without authenticated denial, an attacker could potentially attempt to forge a negative response.

DNSSEC therefore defines mechanisms that allow the resolver to validate nonexistence.

One mechanism is:

NSEC

NSEC records link names in a signed zone and identify record types that exist at particular names.

Conceptually:

Name A
   |
   | NSEC
   v
Next Name

This structure can provide cryptographic proof that a queried name or record type falls into a range where it does not exist.

The NSEC information itself is signed.

Therefore:

Negative answer
      |
      v
NSEC proof
      |
      v
RRSIG
      |
      v
DNSKEY validation

allows authenticated denial of existence.

The NSEC Zone-Walking Problem

Traditional NSEC has an important privacy-related characteristic.

Because NSEC records identify the next existing name in canonical DNS name order, an observer can potentially query the chain repeatedly and enumerate many names in a signed zone.

Conceptually:

host1.example
      |
      v
host2.example
      |
      v
mail.example
      |
      v
vpn.example

This behavior is often called zone walking.

DNSSEC does not consider DNS names secret by design, but zone enumeration can still be operationally undesirable.

NSEC3 was developed partly to make straightforward enumeration more difficult.

What Is NSEC3?

NSEC3 provides authenticated denial of existence using hashed owner names rather than exposing the same direct ordered list of cleartext names used by NSEC.

Conceptually:

DNS Name
   |
   v
Hash
   |
   v
NSEC3 record

This makes straightforward zone walking more difficult.

However, NSEC3 should not be described as perfect confidentiality.

If names are predictable, offline guessing or dictionary-based techniques may still reveal information.

Therefore:

NSEC3

is not equivalent to:

Encrypted DNS zone

Its primary purpose remains authenticated denial of existence with different enumeration characteristics.

How DNSSEC Validation Works

Consider a client asking for:

www.example.com A

A simplified validation process looks like this.

Step 1: Obtain the DNS Answer

The resolver obtains:

www.example.com. A 192.0.2.10

and the associated:

RRSIG

Step 2: Obtain the Child DNSKEY

The resolver obtains the DNSKEY RRset for:

example.com

Step 3: Authenticate the Child DNSKEY

The resolver obtains the DS record for example.com from the parent zone.

Conceptually:

.com
 |
 v
DS example.com
 |
 v
example.com DNSKEY

The authenticated DS information is used to establish trust in the relevant child DNSKEY.

Step 4: Continue Toward the Trust Anchor

The .com zone itself must be authenticated.

Conceptually:

Root
 |
 v
DS for .com
 |
 v
.com DNSKEY
 |
 v
DS for example.com
 |
 v
example.com DNSKEY

Eventually the chain reaches the configured root trust anchor.

Step 5: Verify the RRset Signature

Once the appropriate child DNSKEY is authenticated, it can be used to verify the RRSIG covering:

www.example.com A

If the signature verifies and all required validation conditions are satisfied:

SECURE

If validation is required but fails:

BOGUS

The Complete DNSSEC Validation Path

The complete conceptual architecture is:

ROOT TRUST ANCHOR
        |
        v
   Root DNSKEY
        |
        v
RRSIG over DS RRset
        |
        v
    DS for TLD
        |
        v
    TLD DNSKEY
        |
        v
RRSIG over child DS
        |
        v
  DS for domain
        |
        v
  Domain DNSKEY
        |
        v
RRSIG over requested RRset
        |
        v
    DNS DATA

The resolver verifies each relevant cryptographic relationship.

This is why DNSSEC is much more than simply attaching a signature to an A record.

The AD Bit

DNS responses include an important DNSSEC-related header bit:

AD

which means:

Authenticated Data

A validating recursive resolver can set the AD bit when it considers the relevant response data authenticated according to DNSSEC validation and applicable policy.

You can inspect this using:

dig example.com

A response may include flags such as:

flags: qr rd ra ad

The presence of:

ad

can indicate that the resolver performed DNSSEC validation and considers the returned data authenticated.

However, the security meaning of the AD bit depends on whether the client has a trusted relationship with the resolver delivering that result.

A bit in an untrusted or tampered-with response is not magically cryptographic proof by itself.

The DO Bit

Another DNSSEC-related flag is:

DO

meaning:

DNSSEC OK

It is carried through EDNS and signals that the requester can receive DNSSEC-related records.

With dig, use:

dig +dnssec example.com A

This requests DNSSEC records in the response where applicable.

The DO bit and AD bit perform different functions:

DO
↓
Requester indicates DNSSEC data is wanted/supported

while:

AD
↓
Validator indicates data was authenticated

Do not confuse them.

What Is the CD Bit?

DNSSEC also defines:

CD

meaning:

Checking Disabled

A client can use the CD bit when it wants a recursive resolver to return data without applying its normal DNSSEC validation rejection behavior, for example when the client intends to perform validation itself.

This is an advanced diagnostic and resolver behavior feature.

It should not be confused with:

Disable DNSSEC permanently

The bits have distinct roles:

Bit	Meaning
DO	DNSSEC OK
AD	Authenticated Data
CD	Checking Disabled

DNSSEC and DNS Caching

DNSSEC does not eliminate DNS caching.

Resolvers still cache DNS information.

This means DNSSEC operations must account for:

• DNSKEY TTLs
• DS TTLs
• RRset TTLs
• RRSIG validity periods
• Negative caching
• Resolver cache state

This becomes especially important during key rollovers.

For example, removing an old key too quickly can cause validation failures if some resolvers still depend on cached information related to that key.

DNSSEC changes must therefore be planned with caching in mind.

TTL and RRSIG Expiration Are Different

This distinction is essential.

A DNS RRset has a TTL controlling its cache lifetime.

An RRSIG also contains:

Signature Inception
Signature Expiration

These are not the same concept.

Conceptually:

TTL
 |
 v
How long cached DNS data
is considered fresh

while:

RRSIG validity window
 |
 v
When cryptographic signature
is considered valid

A zone operator must manage both.

A record can be refreshed from authoritative DNS yet still fail validation if its signature has expired.

DNSSEC Key Rollover

Cryptographic keys should not be treated as permanent.

DNSSEC therefore requires operational procedures for key rollover.

Two commonly discussed operations are:

ZSK rollover
KSK rollover

The exact procedure depends on the signing architecture, DNS software, automation, TTLs, and key-management strategy.

The fundamental challenge is avoiding a moment when validators see:

signature

but cannot authenticate the key required to verify it.

ZSK Rollover

In a traditional split KSK/ZSK design:

KSK
 |
 v
DNSKEY RRset

ZSK
 |
 v
Other zone RRsets

A ZSK rollover can often be performed entirely within the child zone without changing the parent DS record.

Conceptually:

Old ZSK
   |
   v
Introduce New ZSK
   |
   v
Transition signatures
   |
   v
Allow caches to update
   |
   v
Retire Old ZSK

Timing matters because DNS caches may contain old keys, old signatures, or both.

KSK Rollover

KSK rollover can require more coordination because the parent DS record may reference the key used as the secure entry point.

Conceptually:

Old KSK
   |
   v
Parent DS

becomes:

New KSK
   |
   v
Updated Parent DS

A poorly coordinated transition can break the chain:

Parent DS
    |
    X
Child DNSKEY

That can make the domain bogus to validating resolvers.

Modern managed DNS platforms often automate significant parts of DNSSEC signing and rollover, but administrators should still understand the trust relationship before changing providers, registrars, or DNSSEC settings.

DNSSEC Algorithm Rollover

DNSSEC keys use defined cryptographic algorithms.

Changing from one algorithm to another is more complex than simply replacing a key while keeping the same algorithm.

During an algorithm transition, validators must be able to follow a valid authentication path throughout the change.

This is one reason DNSSEC rollovers should follow documented procedures rather than improvisation.

The currently deployed algorithm should also be selected according to modern DNSSEC operational recommendations rather than relying indefinitely on legacy algorithms.

How to Test DNSSEC with dig

The most useful starting command is:

dig +dnssec example.com A

For a signed domain, you may see:

A
RRSIG

in the answer.

But simply seeing an RRSIG does not prove the complete DNSSEC chain is valid.

It proves DNSSEC signature material was returned.

Validation requires establishing the chain of trust.

Query DNSKEY

Use:

dig +dnssec example.com DNSKEY

A signed zone should return its DNSKEY RRset.

Conceptually:

example.com
    |
    v
DNSKEY RRset
    |
    +---- Key A
    |
    +---- Key B

Depending on the signing architecture, there may be one or multiple DNSKEY records.

Do not assume every zone must expose exactly two keys.

Query the Parent DS Record

For:

example.com

query:

dig +dnssec example.com DS

The DS data belongs on the parent side of the delegation.

You are looking for the relationship:

Parent DS
    |
    v
Child DNSKEY

If a DS exists but no corresponding valid DNSKEY relationship can be established, the domain can fail DNSSEC validation.

Query a Validating Resolver

You can query a known validating recursive resolver:

dig @1.1.1.1 example.com A

or:

dig @8.8.8.8 example.com A

Then inspect whether the response contains:

ad

when validation succeeds.

For more explicit DNSSEC data:

dig @1.1.1.1 +dnssec example.com A

Remember that +dnssec requests DNSSEC records; it does not mean your local dig process independently validated the complete chain merely because an RRSIG appears.

Why dig +dnssec Is Not the Same as Validation

This is a common troubleshooting mistake.

Running:

dig +dnssec example.com

sets the DO bit so DNSSEC records can be returned.

You might receive:

A
RRSIG

But:

RRSIG present

does not automatically mean:

RRSIG validated

To establish validity, a validator needs to authenticate the relevant DNSKEY through the chain of trust and cryptographically verify the signature.

Therefore:

DNSSEC data exists

and:

DNSSEC validation succeeded

are different statements.

Common DNSSEC Failure: DS/DNSKEY Mismatch

One of the most serious DNSSEC failures is:

Parent DS
    |
    X
Child DNSKEY

This can happen after:

• Changing DNS providers
• Rotating keys incorrectly
• Publishing the wrong DS
• Removing the old key too early
• Registrar configuration mistakes

A validating resolver sees that the parent expects a secure child.

But it cannot authenticate the child’s key.

Result:

BOGUS

Users behind validating resolvers may receive:

SERVFAIL

rather than the domain’s normal answer.

Common DNSSEC Failure: Expired RRSIG

DNSSEC signatures have expiration times.

If a zone operator fails to refresh signatures, an RRSIG can expire.

Conceptually:

RRset
  |
  v
RRSIG
  |
  v
Expiration passed
  |
  X
Validation

The DNS records may still exist on the authoritative server.

The IP address may still be correct.

The server may still be online.

Yet DNSSEC-validating resolvers can reject the data because its signature is no longer valid.

This is why automated signing infrastructure must be monitored.

Common DNSSEC Failure: Signature Not Yet Valid

The opposite problem can also occur.

If:

Current validator time
<
RRSIG inception time

the signature is not yet valid.

Possible causes include:

• Signing timing errors
• Clock problems
• Incorrectly generated signatures
• Deployment mistakes

Accurate timekeeping is therefore operationally important for DNSSEC.

Common DNSSEC Failure: Removing DNSSEC at the DNS Provider but Leaving DS at the Parent

This is a classic outage scenario.

Suppose the parent still contains:

DS

but the child no longer publishes valid DNSSEC data.

The resolver sees:

Parent says:
"This child is secured"

but the child cannot satisfy the secure delegation.

Conceptually:

Parent
  |
  v
 DS
  |
  X
No valid child DNSSEC chain

Result:

BOGUS

This is very different from a properly unsigned delegation where the parent provides authenticated proof that no DS exists.

Common DNSSEC Failure During DNS Provider Migration

Suppose:

Old DNS Provider
     |
     v
Old DNSKEY
     |
     v
Parent DS

You migrate authoritative DNS to:

New DNS Provider
     |
     v
New DNSKEY

but the parent still has:

DS for old key

Now:

Parent DS
    |
    X
New DNSKEY

Validation can fail.

Therefore DNSSEC must be included explicitly in any authoritative DNS migration plan.

Do not treat it as an afterthought after changing nameservers.

DNSSEC Migration Planning

A safe migration requires understanding:

Current authoritative provider
Current DNSKEY
Current parent DS
New provider DNSSEC model
New DNSKEY
DS update procedure
TTL/cache state
DNSSEC validation

A simplified workflow is:

Audit existing DNSSEC
        |
        v
Understand provider migration procedure
        |
        v
Prepare new authoritative zone
        |
        v
Coordinate DNSSEC trust transition
        |
        v
Update delegation / DS as required
        |
        v
Validate chain
        |
        v
Retire old infrastructure safely

The exact sequence depends on the providers involved.

Do not blindly delete DS records or disable DNSSEC without understanding the transition state.

DNSSEC Troubleshooting Workflow

When a domain fails only on some DNS resolvers, DNSSEC should be one of the possibilities investigated.

Use the following process.

Step 1: Test Normal Resolution

dig example.com A

Check whether you receive:

NOERROR

or:

SERVFAIL

A SERVFAIL can have many causes, so it is not proof of DNSSEC failure by itself.

Step 2: Request DNSSEC Data

dig +dnssec example.com A

Inspect:

RRSIG

and the response flags.

Step 3: Query the DNSKEY RRset

dig +dnssec example.com DNSKEY

Confirm that the signed child zone publishes the expected DNSKEY data.

Step 4: Query the Parent DS

dig +dnssec example.com DS

Determine whether a DS exists.

The important relationship is:

Parent DS
     |
     v
Child DNSKEY

Step 5: Compare Validating Resolvers

Test:

dig @1.1.1.1 example.com A

and:

dig @8.8.8.8 example.com A

If validating resolvers consistently return SERVFAIL while an authoritative query returns data, investigate DNSSEC.

Step 6: Query the Authoritative Server

Find the authoritative nameservers:

dig example.com NS

Then query one directly:

dig @AUTHORITATIVE_SERVER example.com A +dnssec

This helps separate:

Authoritative serving problem

from:

Validation-chain problem

Step 7: Inspect Signature Timing

Inspect the RRSIG information.

Check:

Inception
Expiration
Algorithm
Key Tag
Signer

A signature outside its validity window can cause validation failure.

Step 8: Investigate Recent Changes

Ask:

Did we change DNS provider?
Did we change registrar?
Did we enable DNSSEC?
Did we disable DNSSEC?
Did keys rotate?
Did nameservers change?
Did the DS record change?

DNSSEC failures often follow configuration transitions.

DNSSEC Diagnostic Map

Domain returns SERVFAIL
        |
        v
Does authoritative DNS answer?
    |                |
   NO               YES
    |                |
    v                v
Fix authoritative   Check DNSSEC
DNS/service             |
                        v
                  Is DS published?
                    |       |
                   NO      YES
                    |       |
                    v       v
                Likely    Does DS match
                unsigned  valid child key?
                            |       |
                           NO      YES
                            |       |
                            v       v
                         Broken   Check RRSIG
                         chain    validity
                                    |
                                    v
                             Verify signature
                             and chain

This workflow prevents administrators from randomly changing A records when the real problem is cryptographic validation.

DNSSEC and Network Security

DNSSEC should be understood as one layer of a broader security architecture.

It protects the authenticity and integrity of DNS data.

It does not replace:

• TLS
• HTTPS
• Firewalls
• Access control
• Endpoint security
• Network segmentation
• Monitoring
• Secure routing
• Application authentication

For broader defensive architecture, see Network Security Basics and Firewalls Explained.

A simplified layered model is:

DNSSEC
   |
   v
Authenticated DNS data

TLS
   |
   v
Authenticated/encrypted application connection

Firewall
   |
   v
Traffic policy

Application Security
   |
   v
Authorization and data protection

Security depends on the complete stack.

DNSSEC Does Not Prevent Every DNS Attack

DNSSEC is powerful, but its security guarantees have boundaries.

DNSSEC does not inherently:

• Encrypt DNS queries
• Hide which domain a user is resolving
• Stop DDoS attacks
• Secure a compromised registrar account
• Secure a compromised authoritative DNS account
• Fix weak domain-management practices
• Replace TLS certificates
• Prevent malicious domains from existing
• Protect an application after DNS resolution
• Guarantee that the server behind a valid DNS record is secure

For example, if an attacker legitimately compromises the authoritative DNS control plane and obtains the ability to produce valid signed data through the operator’s signing system, DNSSEC alone cannot magically distinguish the attacker’s newly authorized data from intended operator changes.

DNSSEC protects the authenticity of the signed DNS data relative to the trust chain.

Operational security still matters.

DNSSEC and HTTPS

Suppose DNSSEC validates:

www.example.com
      |
      v
192.0.2.10

That tells the validator that the DNS data is authentic according to DNSSEC.

It does not automatically authenticate the HTTPS server.

TLS still performs its own authentication.

Conceptually:

DNSSEC
   |
   v
Authenticate DNS mapping
   |
   v
Connect to server
   |
   v
TLS
   |
   v
Authenticate/encrypt HTTPS session

DNSSEC and TLS solve related but distinct security problems.

DNSSEC and DANE

DNSSEC also provides the trust foundation for technologies such as DANE — DNS-based Authentication of Named Entities.

DANE can publish TLS-related authentication information in DNS through records such as:

TLSA

Because ordinary DNS data alone is not cryptographically trustworthy, DANE relies on DNSSEC authentication.

Conceptually:

DNSSEC
   |
   v
Authenticated DNS
   |
   v
TLSA
   |
   v
DANE

DANE is a separate topic and deserves its own detailed guide, but it demonstrates why DNSSEC can act as infrastructure for higher-level security mechanisms.

DNSSEC Deployment Checklist

Before enabling DNSSEC:

✓ Confirm authoritative DNS supports DNSSEC
✓ Understand provider signing model
✓ Identify registrar DS workflow
✓ Verify supported algorithms
✓ Understand key rollover process
✓ Monitor RRSIG expiration
✓ Document migration procedure
✓ Test with validating resolvers
✓ Know how to remove DNSSEC safely

After enabling DNSSEC:

✓ DNSKEY is published
✓ RRSIG records exist
✓ Parent DS is correct
✓ DS matches intended DNSKEY
✓ Chain reaches trusted root
✓ RRSIG validity periods are correct
✓ Validating resolvers return expected answers
✓ AD status appears where appropriate
✓ Monitoring detects validation failures

DNSSEC Provider Migration Checklist

Before changing authoritative DNS providers:

✓ Audit existing DS records
✓ Record current DNSKEYs
✓ Understand old provider's DNSSEC mode
✓ Understand new provider's DNSSEC mode
✓ Determine DS transition procedure
✓ Verify nameserver migration plan
✓ Account for DNS caching
✓ Keep old service available as required
✓ Validate new DNSSEC chain
✓ Remove obsolete trust data only at the correct stage

Never assume:

Changing nameservers

automatically and safely handles:

DNSSEC DS transition

for every provider combination.

Frequently Asked Questions About DNSSEC

What is DNSSEC?

DNSSEC is a set of DNS security extensions that uses cryptographic signatures to provide data-origin authentication, integrity protection, and authenticated denial of existence for DNS data.

Does DNSSEC encrypt DNS?

No.

DNSSEC authenticates DNS data but does not provide confidentiality.

What is a DNSKEY record?

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

What is an RRSIG record?

RRSIG stores a digital signature covering a DNS RRset.

What is a DS record?

A DS, or Delegation Signer, record exists at the parent side of a delegation and contains information derived from a DNSKEY in the child zone. It helps establish the DNSSEC chain of trust.

Does a DS record contain the private key?

No.

Private signing keys must remain protected.

Does DS directly sign DNSKEY?

No.

The DS is a resource record containing a digest associated with a child DNSKEY. The parent zone signs the DS RRset with its own DNSSEC key.

What is the DNSSEC chain of trust?

It is the cryptographic authentication path connecting a configured trust anchor through DNSKEY and DS relationships to the signed DNS data being validated.

What is the DNSSEC root trust anchor?

It is trusted DNSSEC information for the root zone used as the normal starting point for public Internet DNSSEC validation.

What is a KSK?

KSK means Key Signing Key. In the traditional operational model, it is used to sign the DNSKEY RRset and is associated with the secure delegation relationship.

What is a ZSK?

ZSK means Zone Signing Key. In the traditional operational model, it signs other authoritative RRsets in the zone.

Does DNSSEC require separate KSK and ZSK keys?

No.

The distinction is operational. DNSSEC validation can work with a key that performs both roles.

What is NSEC?

NSEC provides authenticated denial of existence and can prove that a DNS name or record type does not exist.

What is NSEC3?

NSEC3 provides authenticated denial using hashed owner names, making straightforward zone enumeration more difficult than traditional NSEC.

Does NSEC3 completely hide DNS names?

No.

It should not be treated as encryption or complete protection against name discovery.

What does Secure mean in DNSSEC?

The validating resolver successfully authenticated the required DNS data through a valid chain of trust.

What does Insecure mean?

It means the validator has authenticated evidence that the relevant branch is unsigned. It does not mean DNSSEC validation failed.

What does Bogus mean?

It means DNSSEC validation was expected but failed.

Why does DNSSEC failure cause SERVFAIL?

A validating recursive resolver must not silently accept data that fails required DNSSEC validation. SERVFAIL is commonly returned when the resolver cannot provide a validated answer.

Can an incorrect DS record break a website?

Yes.

If a parent publishes a DS but the child DNSKEY cannot satisfy the secure delegation, validating resolvers can reject the domain’s DNS data.

Can a website work for some users but fail for others because of DNSSEC?

Yes.

Users behind validating resolvers may fail while users using non-validating infrastructure may still receive DNS answers.

What does the AD bit mean?

AD means Authenticated Data. A validating resolver can set it when it considers the relevant DNS data authenticated.

What does the DO bit mean?

DO means DNSSEC OK. It indicates that the requester can receive DNSSEC-related records.

What does the CD bit mean?

CD means Checking Disabled. It can request that a recursive resolver not perform its normal DNSSEC validation checking for the query.

Does dig +dnssec validate DNSSEC?

Not by itself.

It requests DNSSEC-related records. Seeing an RRSIG does not prove that the complete chain of trust was successfully validated.

How do I check a domain’s DNSKEY?

Use:

dig +dnssec example.com DNSKEY

How do I check the DS record?

Use:

dig +dnssec example.com DS

How do I request DNSSEC data for an A record?

Use:

dig +dnssec example.com A

Can DNSSEC signatures expire?

Yes.

RRSIG records contain inception and expiration times.

Does TTL equal RRSIG expiration?

No.

TTL controls DNS caching freshness, while RRSIG inception and expiration define the cryptographic signature validity window.

Is DNSSEC necessary for HTTPS?

HTTPS does not require DNSSEC. TLS has its own authentication system. DNSSEC and HTTPS protect different layers and can be used together.

Does DNSSEC stop DNS cache poisoning?

DNSSEC is designed to allow validating resolvers to detect forged or modified signed DNS data that cannot be authenticated through the DNSSEC chain of trust.

Does DNSSEC stop DDoS attacks?

No.

DNSSEC is not a DDoS-prevention mechanism.

Conclusion

DNSSEC adds a cryptographic trust layer to the Domain Name System.

Its core purpose is not encryption.

It provides:

Data Origin Authentication
          +
Data Integrity
          +
Authenticated Denial of Existence

The essential architecture can be summarized as:

TRUST ANCHOR
     |
     v
   DNSKEY
     |
     v
     DS
     |
     v
Child DNSKEY
     |
     v
   RRSIG
     |
     v
    RRset

For the public DNS hierarchy, this becomes:

Root Trust Anchor
        |
        v
       Root
        |
        v
        TLD
        |
        v
      Domain
        |
        v
Signed DNS Data

The most important records are:

DNSKEY → publishes public DNSSEC keys

RRSIG  → carries signatures over RRsets

DS     → connects parent and child trust

NSEC   → authenticates nonexistence

NSEC3  → authenticated denial using hashed names

Administrators should also understand the four important validation states:

Secure
Insecure
Bogus
Indeterminate

A correctly unsigned domain is not the same thing as a broken signed domain.

That distinction is crucial.

The most dangerous DNSSEC configuration problem is often a broken relationship between:

Parent DS

and:

Child DNSKEY

because a validating resolver sees that security is expected but cannot establish the required chain.

For practical troubleshooting, start with:

dig +dnssec example.com A
dig +dnssec example.com DNSKEY
dig +dnssec example.com DS

Then compare recursive and authoritative answers and examine the complete trust chain rather than assuming the presence of an RRSIG proves successful validation.

Continue with DNS Explained for the DNS foundation and DNS Caching and TTL Explained for RRsets, resolver caching, negative caching, Serve Stale, and DNS propagation behavior.

For the broader networking and security layers, continue with TCP/IP Explained, Network Security Basics, and Firewalls Explained.