Search... ⌘ K
Get Started Contact Sales

What Are NSEC and NSEC3 Records?

Last updated

NSEC (Next Secure) and NSEC3 (Next Secure version 3) records give DNSSEC a signed way to say “this name or record type does not exist.” This is called authenticated denial of existence. It stops an attacker from faking a “does not exist” answer to hide a real service. Classic NSEC can expose every name in a zone, and NSEC3 hides names behind hashes.

DNSimple’s name servers use NSEC with compact denial of existence (RFC 9824). This proves that a name doesn’t exist without revealing any other names in your zone.

The challenge of denial of existence in DNSSEC

In traditional (unsigned) DNS, if you query for a non-existent domain or record, the authoritative server responds with an “NXDOMAIN” (Non-Existent Domain) or “NODATA” (No Data) answer.

With DNSSEC, however, a validating resolver needs to trust this denial cryptographically. Otherwise, an attacker could claim a domain does not exist to redirect traffic or hide a legitimate service.

NSEC and NSEC3 records provide this cryptographic proof of non-existence.

What is an NSEC record?

In a traditionally signed zone, NSEC records form a chain of all the existing names in the zone, linked in canonical DNS name order. Canonical order sorts names by label from right to left, so a parent comes before its subdomains. For example, example.com comes before alpha.example.com, which comes before beta.example.com.

Each NSEC record lists three details:

  1. The name of the current record
  2. The name of the next authoritative record in the zone’s canonical DNS name order
  3. A list of DNS record types that exist for the current name

How NSEC works for non-existence

When a validating resolver queries for a non-existent name (for example, beta.example.com in a zone that has alpha.example.com and gamma.example.com as existing names, sorted in canonical order):

  1. The authoritative server responds with an NSEC record for the closest existing name immediately before beta.example.com in the zone’s canonical DNS name order (which would be alpha.example.com).
  2. This NSEC record specifies the name of the next existing authoritative record in that sorted order (which would be gamma.example.com).
  3. Since beta.example.com falls between alpha.example.com and gamma.example.com, and the NSEC record is signed with an RRSIG, the resolver can cryptographically prove that beta.example.com does not exist in the zone.

The “zone walking” problem with NSEC

While NSEC provides authenticated denial of existence, it has a significant privacy drawback: zone walking. Because NSEC records link every existing name in the zone in a sorted list, anyone can repeatedly query for non-existent names and reconstruct the entire list of valid names in a zone by following the NSEC links. This can reveal sensitive organizational structure or internal hosts.

What is an NSEC3 record?

NSEC3 (Next Secure version 3) records were developed to address the zone walking problem of NSEC while still providing authenticated denial of existence. NSEC3 achieves this by using cryptographic hashing.

Instead of linking actual domain names, NSEC3 records link hashed versions of the domain names. This makes zone walking much harder.

How NSEC3 works for non-existence

When a validating resolver queries for a non-existent name:

  1. The resolver hashes the queried name.
  2. The authoritative server sends back an NSEC3 record whose hashed owner name and “next hashed name” fall on either side of that hash. A complete proof usually includes up to three NSEC3 records, which also identify the closest existing parent name and rule out a wildcard match.
  3. Each NSEC3 record is accompanied by an RRSIG signature, allowing resolvers to validate its authenticity.
  4. Because the queried name’s hash falls in a gap between two existing hashes, the resolver can prove the name does not exist, without learning the names in the zone.

NSEC3 parameters

The parameters in an NSEC3PARAM record at the zone apex define how a zone’s NSEC3 records are built. These include:

  • Hash algorithm: The hashing algorithm used. SHA-1 is the only algorithm defined for NSEC3.
  • Flags: Options like “Opt-Out” (see below).
  • Iterations: How many extra times the hash function is applied. Current guidance (RFC 9276) is to use 0, because extra iterations add little protection and slow down validation. Some resolvers treat zones with high iteration counts as unsigned.
  • Salt: A value added to the name before hashing. RFC 9276 recommends using no salt.

NSEC3 “Opt-Out”

NSEC3 includes an “Opt-Out” flag that allows zones with many insecure (unsigned) delegations to opt out of publishing NSEC3 records for those insecure child zones. This can simplify zone management but introduces a slight validation difference for non-existent names within those opt-out zones.

NSEC vs. NSEC3: key differences

While both NSEC and NSEC3 provide authenticated denial of existence, they differ significantly in their approach and implications:

  • Zone walking prevention: This is the primary distinction. Traditional NSEC is vulnerable to zone walking because it links actual domain names in a sorted list, which can expose all names in a zone. NSEC3 links cryptographic hashes of domain names, making it much harder to discover all names.
  • Record linkage: NSEC directly links the current domain name to the next domain name in canonical order. NSEC3 links the hashed version of the current domain name to the hashed version of the next domain name.
  • Privacy: Traditional NSEC reveals all names in the zone. NSEC3 obscures domain names behind hashes.
  • Complexity: NSEC is generally simpler to implement and manage. NSEC3 is more complex due to the introduction of hashing, salt, iteration counts, and the Opt-Out feature.
  • Performance: NSEC can be faster for resolvers as it involves less computation. NSEC3 validation can be slightly slower due to the hashing.

Compact denial of existence at DNSimple

DNSimple’s name servers sign denial answers at the moment they answer the query, using compact denial of existence (RFC 9824). Instead of pointing to the real neighboring names in your zone, the server returns an NSEC record that covers only the name that was asked for. This proves the name doesn’t exist without revealing the other names in your zone, so zone walking isn’t possible.

You can see this when you query a name that doesn’t exist in a DNSSEC-enabled zone hosted at DNSimple and ask for DNSSEC data (for example, with dig +dnssec):

  • The response status is NOERROR with no answer, instead of NXDOMAIN.
  • The NSEC record’s “next name” starts with \000., followed by the name you queried.
  • The NSEC type list includes NXNAME, which signals that the name doesn’t exist. Some versions of dig show it as TYPE128.

Queries that don’t ask for DNSSEC data still get NXDOMAIN. Public validating resolvers, such as Google Public DNS and Cloudflare’s 1.1.1.1, may pass the NOERROR status on to users, so a lookup for a missing name can show “no answer” rather than “does not exist.” Both mean the name isn’t in your zone.

Learn more

To learn more about DNSSEC, see What Is DNSSEC?. To understand how RRSIG records work with NSEC/NSEC3, see What Are RRSETs and RRSIGs in DNSSEC?. If you are experiencing issues with NSEC/NSEC3 records, see Troubleshoot DNSSEC. To explore DNSSEC terms and definitions, check out our DNSSEC Glossary. For a complete overview of DNSSEC at DNSimple, see DNS Security Extensions (DNSSEC) at DNSimple.

Have more questions?

If you have further questions or need any assistance, contact our support team, and we will be happy to help.

Ready to get started with DNSSEC? Read Enable DNSSEC for detailed instructions.