NSEC Walkability: a beginner's guide

NSEC (Next Secure) records are part of how DNSSEC proves that a DNS name doesn't exist. When you ask a DNSSEC-signed zone for `madeup.example.com` and the name truly isn't there, the authoritative server can't just say "no, never heard of it" — it has to prove the non-existence cryptographically. The standard way to do that (RFC 4034) is to return an NSEC record chaining the two real names that bracket where `madeup` would fall alphabetically. Ask enough negative questions, and an attacker can walk the whole chain and enumerate every subdomain in the zone, without ever having permission to transfer it.

You should care because NSEC walking turns your DNSSEC deployment into an accidental subdomain directory. Enterprises typically have dozens to hundreds of internal-sounding subdomains (`vpn`, `jenkins`, `staging-api`, `payroll-uat`, `customer-db-backup`) they never intended to advertise publicly. A walkable zone hands that entire map to any attacker with a script. The replacement standard, NSEC3 (RFC 5155), hashes the names before chaining them — making zone walking computationally much harder. NSEC3 with an opt-out flag and a high iteration count is the modern baseline; plain NSEC is a holdover from the pre-enumeration-attack era.

The four things every NSEC walkability check looks at:

• NSEC vs NSEC3. Is the zone using the old NSEC (directly walkable) or the newer NSEC3 (hashed)?

• NSEC3 parameters. Iteration count, salt, and opt-out flag. High iterations + random salt make offline cracking expensive; opt-out reduces the attack surface.

• Zone-wide vs per-subdomain. Some organizations sign public subdomains but leave internal ones unsigned; others sign everything, which maximizes the walking yield.

• Actual walkable evidence. Does a small number of negative queries return a chain that enumerates even the first few neighbor names? One is enough to confirm walkability.

Three questions an NSEC walkability check answers:

• Could an attacker walk my DNSSEC zone to learn every subdomain I've provisioned?

• Have my NSEC3 parameters been set to meaningful iteration counts and salt, or left at defaults?

• Am I accidentally advertising internal hostnames (VPN endpoints, admin panels, staging environments) that were never meant to be public?

The cost of a walkable zone is silent reconnaissance: an attacker knows every subdomain you have, including the ones you'd rather they didn't. The fix is to upgrade to NSEC3 with hardened parameters (IETF guidance recommends zero iterations and an empty salt under the latest review, balancing enumeration resistance against resolver load), and to audit your zone regularly to confirm the hardening is still in place after DNS-provider migrations. Most managed DNS providers (Cloudflare, Route 53, Google Cloud DNS) default to NSEC3 with reasonable parameters; self-hosted BIND and Knot deployments are where walkability most often slips in.

In one sentence: Grade zone-enumeration risk from NSEC3PARAM configuration

Assesses whether a DNSSEC-signed zone is vulnerable to zone walking (full enumeration of record names) by analyzing NSEC3PARAM configuration per the official internet standard and the official internet standard. Extends the DNS-DNSSEC check with an explicit walkability risk grade so security teams can quantify enumeration exposure without needing to interpret raw DNSSEC (Domain Name System Security Extensions) parameters.

Don't worry if some of the words above are still unfamiliar — there's a plain-language glossary at the bottom of this page, and most of the terms link to their own beginner guides if you want to learn more.

Here's what's actually happening behind the scenes when you call this endpoint:

Queries the NSEC3PARAM record at the zone apex via DNS-over-HTTPS. Parses algorithm, flags (including opt-out bit), iteration count, and salt. Returns a risk grade of walkable (no NSEC3 — full enumeration possible), partial (NSEC3 present but weak parameters such as zero iterations with empty salt, or opt-out enabled exposing unsigned delegations), or mitigated (salt present and parameters within the official internet standard recommended bounds). Also reports whether the zone uses NSEC (fully walkable) or NSEC3.

If you're using an AI assistant through MCP, you don't need to understand any of the technical details — the assistant calls the tool and translates the result for you.

Let's skip the marketing fluff and answer the only question that actually matters: why should you, a real human with a real to-do list, care about the NSEC Walkability tool? Here's the plain-English version, written the way you'd hear it from a friend who happens to do this for a living.

NSEC walking lets attackers enumerate every name in a DNSSEC-signed zone — exposing staging servers, internal subdomains, and attack surface that zone operators assumed was private. the official internet standard (2022) recommends iteration count 0 and discourages opt-out. This endpoint grades a zone against those recommendations without requiring manual DNSSEC (Domain Name System Security Extensions) parameter interpretation.

Picture this in real life. Imagine a security engineer. Here's the situation they're walking into: Audit DNSSEC-signed zones to ensure they use NSEC3 with the official internet standard-compliant parameters and do not expose staging or internal subdomain names to enumeration. Without the right tool, that person would be stuck copy-pasting between five browser tabs, reading documentation written for engineers, and crossing their fingers that the answer they cobble together is correct. With the NSEC Walkability tool, the same person gets a clear answer in seconds — no spreadsheets, no guessing, no waiting for someone on the infrastructure team to free up.

Three questions this tool answers in plain English. If any of these have ever crossed your mind, the NSEC Walkability tool is built for you:

• Is my domain pointing to the right place right now?

• Did the DNS change I just made actually take effect everywhere in the world?

• Is anything in my DNS misconfigured in a way that could break email or break the website?

You can either click the tool and get the answer yourself, or ask your AI assistant — connected through MCP (Model Context Protocol) — to ask the question for you and translate the answer into something you can paste into Slack.

Who gets the most out of this. Founders running their own infrastructure, marketers coordinating launches, IT admins inheriting domains from a former employee, and ops engineers troubleshooting live outages. If you see yourself in that list, this is one of the EdgeDNS tools you should bookmark today.

What happens if you skip this entirely. Skip it and you're flying blind on the one piece of config that decides whether your website and email work at all. That's why running this check — even once a month — is one of the cheapest forms of insurance you can give your domain.

If you're still on the fence about whether the NSEC Walkability tool belongs in your toolbox, this section is for you. Below you'll meet three real people — a security engineer, a DNS administrator, and a penetration tester — facing three real situations where this tool turns a stressful afternoon into a five-minute task. Read whichever story sounds closest to your week.

Story 1: DNSSEC Configuration Audit

Imagine you're a security engineer. Audit DNSSEC-signed zones to ensure they use NSEC3 with the official internet standard-compliant parameters and do not expose staging or internal subdomain names to enumeration.

Why it matters: Catch walkable zones before attackers enumerate your DNS-hidden attack surface.

Story 2: Zone Migration Validation

Imagine you're a DNS administrator. After migrating to a new DNS (Domain Name System) provider, verify NSEC3PARAM is correctly set with salt and reasonable iteration count (0 per the official internet standard).

Why it matters: Prevent accidental regressions from NSEC3 (salted) back to NSEC (fully walkable).

Story 3: Red Team Pre-Engagement

Imagine you're a penetration tester. Identify zones vulnerable to walking as a reconnaissance step — walkable zones surface subdomain inventory without active probing.

Why it matters: Prioritize targets with weak NSEC3PARAM configuration during engagement scoping.

Common situations across teams. Beyond the three stories above, here are the everyday workplace moments when people across the company reach for the NSEC Walkability tool — or one of the tools right next to it in this category. If any of these are on your calendar this month, that's your sign:

• Right before launching a new website or migrating to a new host.

• After making any DNS change, to confirm the new settings are live everywhere.

• When customers report that your site or email "just stopped working" out of nowhere.

• As a recurring monthly health check to catch silent misconfigurations early.

If you can see yourself in even one of those bullets, the NSEC Walkability tool will pay for itself the first time you use it.

Still not sure? Here's the easiest test in the world. Open Claude, ChatGPT, Gemini, or any other AI assistant connected to the EdgeDNS MCP server and ask, in your own words: "Is the NSEC Walkability tool useful for my job?" The assistant will look at the tool, ask you a couple of follow-up questions about what you're trying to accomplish, and give you a straight answer in plain English. No commitment, no signup forms, no jargon.

If you've connected the EdgeDNS MCP server to Claude, ChatGPT, Gemini, Cursor, or any other AI assistant, you don't need to write any code. Just ask in plain English:

"Use the NSEC Walkability tool to check example.com and explain anything that looks wrong in plain language."

The AI will figure out which tool to call, fill in the right parameters, run it, and then explain the result back to you. No copy-pasting between tabs. No reading raw JSON. No memorizing endpoint names.

If you're a developer and want to call the endpoint from a script or your own application, here's the simplest possible example. Replace the placeholder API key with the real one from your dashboard.

There's just one piece of information you need to provide. The table below explains exactly what it is and what a real value looks like.

When you call this tool, you'll get back a JSON object with the fields below. If you're talking to it through an AI assistant, the assistant reads these for you and explains them in plain language — you don't need to memorize them.

These tools pair naturally with NSEC Walkability. If you're already running this check, the related ones often answer the next question that comes up:

• DNSSEC Check — Verify DNSSEC signing and validation

• Nameservers — List nameservers and detect DNS provider

• Zone Transfer Check — Test for DNS zone transfer vulnerability

If you're using an AI assistant through MCP (Model Context Protocol), you can ask it to run several of these in one go: "Check NSEC Walkability and the related tools for example.com and tell me what looks off."

If any words on this page felt like jargon, here's a plain-language version. Click any linked term to read a full beginner-friendly guide.

DNS (Domain Name System) — The internet's address book. When you type a website name, DNS turns it into the actual numeric address computers use to find each other.

HTTPS (secure HyperText Transfer Protocol) — HTTP with encryption — the little padlock in your browser. It means nobody between you and the website can read what you're sending.

DNSSEC (Domain Name System Security Extensions) — A way to digitally sign DNS records so attackers can't trick your computer into looking up the wrong server.

RFC (Request for Comments) — The official internet standards documents. When someone says 'RFC 8484' they mean a specific numbered standards document — in that case, the one defining DNS over HTTPS.