DNSSEC NSEC3 Myths: When It Helps and When It Just Hurts Performance

NSEC3 in one screen: what it is and what it is not

DNSSEC doesn’t just sign the records you do have. It also has to provide a cryptographic proof for records you don’t have. If a
resolver asks for does-not-exist.example, you can’t just say “nope.” Without proof, an attacker could forge negative
answers and make entire names disappear.

That’s what NSEC and NSEC3 are about: authenticated denial of existence. They let an authoritative server prove—cryptographically—that
the requested name (or type) doesn’t exist in the zone.

NSEC (the straightforward one)

With NSEC, the zone contains “next” pointers in cleartext name order. A negative answer includes an NSEC record that proves:
“the requested name falls between these two existing names, therefore it doesn’t exist.” Simple, efficient, and cache-friendly.

The downside: NSEC enables trivial zone enumeration (“zone walking”). Anyone can query successive names and recover the whole set of
owner names in the zone, even if AXFR is blocked.

NSEC3 (the hashed one)

NSEC3 replaces cleartext names with hashed names. Instead of linking a.example → b.example, it links
HASH(a) → HASH(b). Negative responses include NSEC3 records containing hashed owner names. This is intended
to make zone walking harder by requiring an attacker to guess names and hash them (possibly with multiple iterations and a salt) to
match what’s in the zone.

Notice what it does not do: it doesn’t hide your zone from targeted guessing. If your names are predictable, NSEC3 turns
enumeration into a dictionary attack, not a magic cloak.

The shortest useful mental model: NSEC is faster and leaky; NSEC3 is slower and less leaky, but not secret.

The NSEC3 myths that won’t die

Myth 1: “NSEC3 prevents zone walking, so it prevents recon.”

NSEC3 prevents trivial zone walking. It does not prevent name guessing. If your organization uses
vpn, mail, autodiscover, api, dev, stage, prod,
and you think a hash is going to stop recon… I have bad news.

Attackers don’t need to walk your zone when you’ve already named things like a human. They will guess. They will brute-force.
They will use wordlists. They will use certificate transparency logs and passive DNS. NSEC3 only raises the cost of blind enumeration.

Myth 2: “More NSEC3 iterations always means more security.”

NSEC3 supports hashing with iterations. More iterations increase the cost of guessing names. They also increase your signing cost and,
depending on implementation and precomputation, can increase authoritative CPU load and operational friction.

The industry has moved away from high iterations because the real-world benefit is thin and the costs are not. High iteration counts
don’t protect you from the obvious names. They do protect you from… someone guessing your zone’s random 20-character labels. If that’s
your main threat model, great. If not, you’re paying rent for an empty apartment.

Myth 3: “NSEC3 is always ‘more secure’ than NSEC.”

Security isn’t a single axis. NSEC3 reduces information disclosure of owner names, but it increases complexity and response size. It
also expands the blast radius of misconfiguration because debugging hashed denial-of-existence is harder than reading an NSEC chain.

In reliability terms: NSEC3 is a trade. You should buy it only if you want what it sells.

Myth 4: “NSEC3 will fix SERVFAIL problems after enabling DNSSEC.”

If you’re getting SERVFAIL after turning on DNSSEC, you likely have broken signatures, missing DS records, expired RRSIGs,
a bad algorithm choice, a broken key roll, or MTU/fragmentation trouble. Switching NSEC to NSEC3 is not a repair; it’s changing
the tires because the engine light is on.

Joke #1 (short, relevant): NSEC3 is like putting tinted windows on a car with no brakes. It changes what outsiders see, not whether you stop.

Myth 5: “If we don’t use NSEC3, we’re non-compliant.”

Most compliance language cares that DNSSEC is deployed correctly and that keys are managed. NSEC3 is rarely mandated. Some orgs choose
it as a policy for “reducing enumeration.” That’s a choice, not a universal requirement.

When NSEC3 genuinely helps

1) Your zone names are genuinely unguessable and you care about name disclosure

If you use random labels (think: per-customer tokens, long UUID-ish hostnames, or privacy-preserving delegation structures), NSEC3 can
materially raise the cost of enumerating them. In those niches, NSEC’s cleartext chain is an unforced error.

2) You’re in a hostile recon environment and your naming is disciplined

Some enterprises do manage to keep predictable names out of public DNS, and only expose what must be exposed. For them, NSEC3 can be a
meaningful “make it annoying” control. Not a silver bullet. An annoyance. Annoyance has value.

3) You run a signed TLD or large public zone and you have policy pressure

In registries and some heavily scrutinized public zones, disclosure of all delegations can have business and abuse implications. Even
if enumeration is possible via other channels, NSEC3 may be adopted to avoid handing out a clean list via DNS alone.

4) You can afford the operational overhead

This is the part people skip in the security review. NSEC3 requires correct parameterization, consistent signing behavior across
authorities, and careful monitoring. If you can’t commit to that, you’re better off running NSEC correctly than running NSEC3 poorly.

Where NSEC3 hurts performance (and why)

Packet size inflation: negative answers get fat

DNSSEC already increases response size because of RRSIGs and DNSKEYs. Negative answers can be worse because denial-of-existence
proof requires additional records (NSEC/NSEC3 plus their signatures). NSEC3 responses often contain multiple NSEC3 records to cover
closest encloser proofs and wildcard denial, and each carries hashed owner names and parameters.

Big UDP responses trigger fragmentation, which triggers loss, which triggers retries, which triggers TCP fallback. You think you enabled
“more security”; you actually enabled “more state on firewalls and load balancers.”

CPU cost: hashing and signing aren’t free

NSEC3 uses hashing (SHA-1 in the original design). Authoritative servers typically precompute NSEC3 chains at signing time, but dynamic
update zones, frequent re-signing, or poor tooling can shift work into the serving path or increase signing churn.

Even when precomputed, more complicated negative proof construction increases code paths and memory access patterns. On a busy
authoritative fleet, you’ll feel it as higher CPU per query and lower cache hit rates (because there are more distinct negative proofs
flying around).

Resolver-side pain: validation and retries get uglier

Validators don’t love large, fragmented responses. They love consistent, cacheable answers. NSEC tends to provide cleaner caching
properties for nonexistence because it’s simple and stable. NSEC3’s hashed nature plus opt-out semantics (in some deployments) can
lead to more resolver work, more queries, and more time spent walking proofs.

Operational debugging: humans can’t read hashes

With NSEC, you can look at an answer and understand what’s being proven. With NSEC3, you squint at base32 blobs and wonder if you
accidentally summoned a demon.

Joke #2 (short, relevant): Debugging NSEC3 by eye is like reviewing a storage incident from raw hex dumps. Technically possible. Spiritually unwise.

Middleboxes: the part of the internet that still hates you

DNSSEC depends on EDNS(0) for larger UDP buffers. Some networks still mishandle EDNS, fragmented UDP, or large DNS responses. NSEC3 can
push you over size thresholds more often, turning “rare corner case” into “daily ticket.”

Opt-out: performance and policy footguns

NSEC3 opt-out was designed to reduce signing burden for zones with lots of insecure delegations (common in registries). It can reduce
record count and response size in those cases. It can also create misunderstandings about what is and isn’t being authenticated.
If your team can’t explain opt-out clearly, you probably shouldn’t deploy it casually.

Facts & history: how we got here

• NSEC came first: authenticated denial originally used NXT, then NSEC, which directly exposed the zone’s name ordering.
• Zone walking was not a surprise: it was an obvious property of NSEC, and the community debated whether it mattered for years.
• NSEC3 was introduced to address enumeration: it added hashing (plus salt and iterations) to make bulk disclosure harder.
• NSEC3 uses SHA-1: not because it’s “modern,” but because it was standardized when SHA-1 was the pragmatic choice for this use case.
• Iterations were a late-stage “dial”: the idea was to raise the cost of offline guessing attacks; in practice it created tuning drama.
• Large responses became the real enemy: as DNSSEC deployed, operational failures often came from UDP size/fragmentation rather than pure crypto.
• Opt-out was designed for registries: it was meant to keep NSEC3 feasible for zones with huge numbers of insecure delegations.
• Operational tooling lagged: early DNSSEC deployments suffered because monitoring and debugging workflows were immature compared to today.
• Many operators now prefer simplicity: for lots of zones, the industry lesson has been “use NSEC unless you have a reason not to.”

One quote, because it belongs in every ops discussion. Werner Vogels (Amazon CTO) said: “Everything fails, all the time.” That mindset
applies here: design DNSSEC choices around failure modes you can survive, not theoretical perfection.

Fast diagnosis playbook

The goal is not to become a DNSSEC scholar while users are timing out. The goal is to find the bottleneck fast: authoritative CPU,
packet loss/fragmentation, resolver validation failures, or bad signing state.

First: confirm if the pain is negative answers or everything

• Sample queries for existing names and NXDOMAIN names. If NXDOMAIN is disproportionately slow or triggers TCP more often, NSEC3 is a
  prime suspect.
• Look at response sizes. If you’re regularly above ~1232 bytes, you’re in the “fragmentation roulette” zone for many networks.

Second: check for fragmentation, retries, and TCP fallback

• Capture on the authoritative edge. If you see repeated queries, truncated (TC=1) responses, or lots of TCP/53 sessions, you’re
  paying the size tax.
• Check EDNS buffer behavior from real client networks. Don’t trust a single vantage point on a clean corporate LAN.

Third: validate the DNSSEC chain and negative proofs

• Use a validating resolver and tools that show you the denial-of-existence proof. Confirm RRSIG validity and correct NSEC3 coverage.
• Look for key roll or signature expiration mistakes. They masquerade as “performance” because they trigger retries and fallback paths.

Fourth: isolate server-side cost

• Watch authoritative CPU and qps under load. If CPU rises with NXDOMAIN rate, you may be doing dynamic NSEC3 work or suffering cache misses.
• Check if your signer is thrashing (too frequent re-signing, too many keys, too short signature validity, or poor NSEC3 parameter changes).

Practical tasks: commands, outputs, and decisions

These are real tasks you can run during an incident or a calm Tuesday. Each includes: command, example output, what it means, and what
decision you make.

Task 1: Compare positive vs negative response size and flags

cr0x@server:~$ dig +dnssec +bufsize=1232 www.example.com A @ns1.example.net

; <<>> DiG 9.18.24 <<>> +dnssec +bufsize=1232 www.example.com A @ns1.example.net
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4812
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
www.example.com. 300 IN A 203.0.113.10
www.example.com. 300 IN RRSIG A 13 3 300 20260204000000 20260114000000 12345 example.com. ...

;; Query time: 18 msec
;; MSG SIZE  rcvd: 412

cr0x@server:~$ dig +dnssec +bufsize=1232 does-not-exist.example.com A @ns1.example.net

; <<>> DiG 9.18.24 <<>> +dnssec +bufsize=1232 does-not-exist.example.com A @ns1.example.net
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 1129
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1

;; AUTHORITY SECTION:
example.com. 300 IN SOA ns1.example.net. hostmaster.example.com. 2026020401 3600 900 1209600 300
example.com. 300 IN RRSIG SOA 13 2 300 20260204000000 20260114000000 12345 example.com. ...
6JQ2K7...example.com. 300 IN NSEC3 1 0 10 A1B2C3D4 6K5... NS SOA RRSIG DNSKEY NSEC3PARAM
6JQ2K7...example.com. 300 IN RRSIG NSEC3 13 3 300 20260204000000 20260114000000 12345 example.com. ...
9F8P1...example.com. 300 IN NSEC3 1 0 10 A1B2C3D4 B0T... A AAAA RRSIG
9F8P1...example.com. 300 IN RRSIG NSEC3 13 3 300 20260204000000 20260114000000 12345 example.com. ...

;; Query time: 44 msec
;; MSG SIZE  rcvd: 1216

What it means: NXDOMAIN is ~3x bigger and slower, and it’s flirting with the 1232-byte buffer limit.

Decision: Treat negative answers as the primary performance risk. Start testing truncation and fragmentation next.

Task 2: Check truncation behavior (TC bit) with a smaller EDNS buffer

cr0x@server:~$ dig +dnssec +bufsize=512 does-not-exist.example.com A @ns1.example.net

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 9001
;; flags: qr aa tc rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: Message truncated

What it means: With a smaller buffer, the server sets TC=1 and expects the client to retry over TCP.

Decision: If many clients effectively behave like this (broken EDNS, small buffers), you’ll see TCP spikes. Plan mitigations.

Task 3: Confirm TCP fallback works and measure it

cr0x@server:~$ dig +tcp +dnssec does-not-exist.example.com A @ns1.example.net

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 7711
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1
;; Query time: 96 msec
;; MSG SIZE  rcvd: 1216

What it means: TCP works but costs ~2–5x latency vs UDP in many environments.

Decision: If you’re pushing clients to TCP frequently, you’re building latent outages. Reduce response sizes or improve path MTU behavior.

Task 4: Inspect NSEC vs NSEC3 presence in the zone

cr0x@server:~$ dig +dnssec example.com NSEC3PARAM @ns1.example.net

;; ANSWER SECTION:
example.com. 300 IN NSEC3PARAM 1 0 10 A1B2C3D4
example.com. 300 IN RRSIG NSEC3PARAM 13 2 300 20260204000000 20260114000000 12345 example.com. ...

What it means: The zone is using NSEC3 with algorithm 1, flags 0, iterations 10, salt A1B2C3D4.

Decision: If iterations are high “because security,” revisit. If you don’t have a concrete threat model, prefer low iterations or NSEC.

Task 5: See whether negative answers include multiple NSEC3 records

cr0x@server:~$ dig +dnssec +norecurse nohost.sub.example.com A @ns1.example.net

;; AUTHORITY SECTION:
... NSEC3 ...
... NSEC3 ...

What it means: You’re getting closest-encloser proofs and wildcard denial proofs. This is normal, and it increases size.

Decision: Expect NXDOMAIN to be heavier than positive answers. If this is a high-volume query pattern (typos, scanners), optimize for it.

Task 6: Check authoritative server QPS and CPU during NXDOMAIN bursts

cr0x@server:~$ sudo rndc stats
cr0x@server:~$ sudo tail -n 12 /var/named/data/named_stats.txt
++ Incoming Requests ++
[View: default]
                17642 QUERY
                 8810 NXDOMAIN
++ Name Server Statistics ++
               1420010 IPv4 requests received
                  9901 TCP requests received

What it means: NXDOMAIN is a huge fraction, and TCP requests are non-trivial.

Decision: Treat NXDOMAIN as load. Consider response rate limiting for abusive patterns, tighten wildcard usage, and reduce negative response size.

Task 7: Check for DNS UDP fragmentation on the server interface

cr0x@server:~$ sudo tcpdump -ni eth0 port 53 and udp -vv -c 6
tcpdump: listening on eth0, link-type EN10MB
12:00:01.100000 IP 198.51.100.20.53534 > 203.0.113.53.53: UDP, length 67
12:00:01.100500 IP 203.0.113.53.53 > 198.51.100.20.53534: UDP, length 1492
12:00:01.100520 IP 203.0.113.53 > 198.51.100.20: ip-proto-17 fragment 1492:1480@0+
12:00:01.100540 IP 203.0.113.53 > 198.51.100.20: ip-proto-17 fragment 220@1480

What it means: You are sending fragmented UDP responses. Some networks drop fragments. That becomes random DNS failure.

Decision: Reduce UDP response size (policy and signing choices), or tune EDNS/MTU strategy. Do not ignore fragments in 2026.

Task 8: Test from a validating resolver to separate “authoritative” from “validator” issues

cr0x@server:~$ dig +dnssec www.example.com A @9.9.9.9

;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2
;; ANSWER SECTION:
www.example.com. 300 IN A 203.0.113.10
www.example.com. 300 IN RRSIG A 13 3 300 20260204000000 20260114000000 12345 example.com. ...

What it means: ad indicates the resolver validated DNSSEC successfully.

Decision: If some validators show ad and others return SERVFAIL, suspect path/fragmentation or stale/broken caches, not just signatures.

Task 9: Use delv to validate and show why a name fails

cr0x@server:~$ delv +vtrace does-not-exist.example.com A @9.9.9.9
; fully validated
does-not-exist.example.com. 300 IN A ; negative response, NXDOMAIN

What it means: The negative proof validated end-to-end.

Decision: If delv fails with a signature or denial-of-existence complaint, stop performance tuning and fix correctness first.

Task 10: Verify DS at the parent (the classic “why is it SERVFAIL?” check)

cr0x@server:~$ dig +dnssec example.com DS @a.gtld-servers.net

;; ANSWER SECTION:
example.com. 86400 IN DS 12345 13 2 3A1B...C9
example.com. 86400 IN RRSIG DS 13 1 86400 20260204000000 20260114000000 9999 com. ...

What it means: The parent publishes a DS. Validators will enforce signatures for example.com.

Decision: If DS is missing or wrong, fix your delegation chain before blaming NSEC3. A wrong DS creates universal validation failure.

Task 11: Check RRSIG validity windows (clock skew and expiry)

cr0x@server:~$ dig +dnssec example.com SOA @ns1.example.net | grep RRSIG
example.com. 300 IN RRSIG SOA 13 2 300 20260204000000 20260114000000 12345 example.com. ...

What it means: Signatures have an inception and expiration time. If your signer clock is wrong or you let signatures expire, validators will fail.

Decision: If you see near-term expiry with slow re-signing, extend validity or fix signer scheduling. Correctness beats cleverness.

Task 12: Measure authoritative latency distribution under load

cr0x@server:~$ sudo dnstap-read /var/log/dnstap/dnstap.log | head -n 6
2010-01-01 12:00:01.100 CQ example.com/A udp 198.51.100.20:53534
2010-01-01 12:00:01.101 CR example.com/A NOERROR 1ms 412b
2010-01-01 12:00:02.200 CQ does-not-exist.example.com/A udp 198.51.100.21:53535
2010-01-01 12:00:02.260 CR does-not-exist.example.com/A NXDOMAIN 60ms 1216b

What it means: NXDOMAIN is slower and larger. That’s a signature (pun intended) of denial-of-existence overhead plus network effects.

Decision: If NXDOMAIN dominates tail latency, treat it as a product requirement: reduce NXDOMAIN volume (typos, scanners), or reduce proof size.

Task 13: Inspect NSEC3 parameters in BIND (if you’re signing there)

cr0x@server:~$ grep -R "nsec3param" -n /etc/bind
/etc/bind/named.conf.local:42:    auto-dnssec maintain;
/etc/bind/named.conf.local:43:    inline-signing yes;
/etc/bind/named.conf.local:44:    nsec3param 1 0 10 A1B2C3D4;

What it means: Inline signing is enabled and NSEC3 parameters are explicitly set.

Decision: If you inherited this config, challenge it. If you don’t have a reason for NSEC3, remove the param and move to NSEC (planned change), or lower iterations.

Task 14: Check for EDNS compliance issues from a “bad path” client network

cr0x@server:~$ dig +dnssec +edns=0 +bufsize=4096 does-not-exist.example.com A @ns1.example.net

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 5150
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1
;; MSG SIZE  rcvd: 1216

What it means: From this vantage point EDNS works, but that does not prove it works for mobile carriers, enterprise proxies, or legacy devices.

Decision: If incidents correlate with certain networks, assume EDNS/fragmentation interference and prioritize making responses fit into safer sizes.

Three corporate mini-stories from the DNS trenches

Mini-story 1: The incident caused by a wrong assumption (“NSEC3 will stop recon, so we’re safe”)

A mid-size SaaS company had a public zone with a lot of internal convenience names accidentally published: jenkins,
grafana, vpn, staging-api. Nothing directly exploitable, but plenty of breadcrumbs.
A security review flagged “zone walking via NSEC” as information leakage.

The team’s response was fast and tidy: enable NSEC3, bump iterations “for safety,” ship it. They declared victory and moved on. No
one asked the uncomfortable question: “If someone can guess our names, what did we actually achieve?”

A few weeks later, they got a wave of targeted password spraying against the very services the zone “hid.” The attacker didn’t walk
anything. They guessed the names, validated them through DNS, and then tried common credentials. NSEC3 did its job—prevented a clean
list from being scraped—while contributing nothing against the actual threat, which was boring and predictable.

The postmortem was painful because the fix wasn’t “tune iterations.” The fix was naming hygiene and exposure control: remove internal
service names from public DNS, put admin endpoints behind VPN, and stop publishing convenience CNAMEs that map to management UIs.
NSEC3 wasn’t wrong; the assumption was.

The operational kicker: the company kept NSEC3 anyway, because removing it would look like “reducing security.” Meanwhile, on-call
quietly learned that the biggest measurable effect of the project was a jump in DNS response sizes and occasional TCP fallback.

Mini-story 2: The optimization that backfired (“crank NSEC3 iterations to the moon”)

A large enterprise with a global authoritative DNS fleet decided to standardize on NSEC3 everywhere. They were genuinely worried
about bulk enumeration of delegated subdomains and had a compliance narrative to support it.

Someone proposed raising the NSEC3 iteration count significantly “to slow down attackers.” It sounded reasonable. Hashing is cheap,
right? And their authoritative cluster had plenty of headroom in steady state.

Then came a signing event: a coordinated key rollover plus a zone content change that touched a lot of names. The signer workload
jumped. Signatures took longer to regenerate. Propagation lag increased. The team began seeing intermittent validation failures from
certain resolvers because the zone was in a half-updated state longer than expected. Users saw it as: random SERVFAIL.

The incident response focused on “resolver bugs” and “the internet is flaky,” until someone correlated the timeline with the NSEC3
parameter change. High iterations didn’t just “slow attackers”—they also slowed the organization’s own ability to recover from and
complete signing operations under churn.

They rolled back to saner parameters and introduced a rule: never change NSEC3 parameters at the same time as a key event. Also: test
signing throughput like you test storage rebuild time—under worst-case conditions, not idle happy-path.

Mini-story 3: The boring but correct practice that saved the day (tight monitoring and “fit in UDP” discipline)

A financial services company ran DNSSEC for years with minimal drama. Their secret wasn’t exotic crypto. It was discipline:
response-size monitoring, predictable key management, and a written playbook for validating failures.

They chose NSEC for most zones. For the few zones that truly benefited from NSEC3, they kept parameters conservative and avoided
gratuitous iteration counts. More importantly, they had an SLO: “DNSSEC responses must fit within a chosen UDP budget for the majority
of negative answers.” If a change pushed responses larger, it was treated like a regression.

One day, a DDoS campaign shifted from volumetric traffic to NXDOMAIN flooding against their public zone. The attack wasn’t clever; it
was high-rate junk queries designed to force expensive negative answers.

Because they had baseline metrics, they recognized the pattern within minutes: NXDOMAIN ratio spike, response size increase in tail,
TCP fallback rising, authoritative CPU trending upward. They turned on response rate limiting for abusive sources, adjusted caching
and front-door filtering, and got back to stable. No heroics. No midnight “why is DNS broken?” Slack threads.

The nice part: the team could justify their earlier “boring” decisions with hard data. NSEC wasn’t ideology; it was a conscious
reliability choice that kept negative answers smaller and easier to cache.

Common mistakes: symptoms → root cause → fix

1) Symptom: random timeouts, especially on mobile networks

Root cause: fragmented UDP DNSSEC responses (often NXDOMAIN with NSEC3) dropped by networks or middleboxes.

Fix: reduce response size (prefer NSEC where acceptable; reduce NSEC3 complexity; avoid oversized additional data), and test with smaller EDNS buffers.

2) Symptom: sudden increase in TCP/53 connections after enabling DNSSEC

Root cause: TC=1 truncation due to response size and resolver retry over TCP; sometimes exacerbated by small EDNS buffers.

Fix: monitor TC bit rates; tune to keep typical answers under your UDP budget; ensure authoritative TCP is scaled and protected.

3) Symptom: validators return SERVFAIL for non-existent names but existing names work

Root cause: broken denial-of-existence proofs (bad NSEC3 chain, incorrect signing, stale inline-signed state).

Fix: validate with delv +vtrace; re-sign cleanly; ensure consistent zone transfers of signed content; avoid partial parameter changes.

4) Symptom: authoritative CPU spikes correlate with NXDOMAIN floods

Root cause: expensive negative answer construction, poor caching behavior, or signing work bleeding into serving.

Fix: rate limit abusive query sources; increase caching at edges; ensure NSEC3 chains are precomputed; consider NSEC for zones where enumeration is not a concern.

5) Symptom: “We enabled NSEC3 and security says it’s better, but incidents increased”

Root cause: security control chosen without a threat model; performance regressions ignored; name disclosure risk overstated.

Fix: document why NSEC3 is needed; if you can’t, don’t use it. Prefer simpler DNSSEC where possible and focus on exposure control.

6) Symptom: intermittent SERVFAIL around key rollovers

Root cause: signer throughput and propagation lag; changing NSEC3 params during key events; signature timing windows too tight.

Fix: separate parameter changes from key rolls; extend validity windows appropriately; monitor signer queue and publication state.

7) Symptom: resolvers behave differently (some validate, some fail)

Root cause: path MTU differences, EDNS handling differences, or cached broken state; not always “resolver bugs.”

Fix: test from multiple networks; capture fragmentation; confirm DS and DNSKEY consistency; reduce response sizes to minimize path sensitivity.

8) Symptom: “Zone walking is still possible even with NSEC3”

Root cause: predictable labels allow dictionary attacks; other data sources leak names anyway.

Fix: treat public DNS as public. Remove sensitive names, randomize if appropriate, and avoid assuming NSEC3 provides secrecy.

Checklists / step-by-step plan

Decision checklist: should this zone use NSEC3?

1. List the threat: are you trying to prevent bulk enumeration of genuinely unguessable names, or just avoid embarrassment?
2. Assess naming predictability: if labels are common words, NSEC3 won’t stop guessing.
3. Estimate NXDOMAIN volume: high NXDOMAIN zones (typos, scanners, bot traffic) pay more for NSEC3.
4. Set a UDP size budget: pick a target (often 1232) and test negative answers against it.
5. Confirm toolchain maturity: can your team validate and debug NSEC3 failures quickly?
6. Have a rollback plan: parameter changes and denial-of-existence mechanisms need staged rollout and monitoring.

Rollout plan: switching NSEC ↔ NSEC3 without self-inflicted pain

1. Baseline first: measure response sizes, NXDOMAIN ratio, TCP/53 rate, and tail latency.
2. Test from multiple networks: include mobile and “enterprise proxy” paths.
3. Stage the change: canary one zone or a subset of authorities; watch TC=1 rates and fragment counts.
4. Don’t mix with key events: do not change NSEC3 params during KSK/ZSK rolls. Keep variables separate.
5. Watch negative caching behavior: check resolver query rates post-change; don’t assume caches will save you.
6. Rehearse failure: practice validating SERVFAIL and negative proof failures with your on-call team.

Operational checklist: keep DNSSEC boring (the highest compliment)

1. Monitor DNS response sizes (especially NXDOMAIN) and percentiles, not just averages.
2. Monitor TCP/53 rates, TC bit rates, and UDP fragment counts.
3. Alert on signature expiration horizon (RRSIGs getting too close to expiry).
4. Keep signer clocks correct (NTP) and verify time sync on signers and authorities.
5. Document key roll runbooks and run them during business hours when possible.
6. Keep EDNS buffer defaults sane; avoid huge buffers that invite fragmentation on the open internet.
7. Assume NXDOMAIN floods will happen; have rate limiting and abuse controls ready.

FAQ

1) Is NSEC3 required for DNSSEC?

No. DNSSEC requires authenticated denial of existence, but that can be provided by NSEC or NSEC3. Many zones run NSEC successfully.

2) Does NSEC3 make my zone “private”?

No. It makes bulk enumeration harder, not targeted discovery. If names are guessable, they’re discoverable.

3) Why do NXDOMAIN answers get so big with DNSSEC?

Because the server must include proof. That proof includes denial records (NSEC/NSEC3) and their signatures, plus often SOA and its
signature. NSEC3 proofs can include multiple records.

4) Should I increase NSEC3 iterations for better security?

Only if you have a clear threat model that benefits from it and you’ve tested the operational impact on signing and serving. Otherwise,
keep it conservative or avoid NSEC3.

5) What’s the simplest way to tell if NSEC3 is causing performance issues?

Compare response size and latency for a few positive queries vs NXDOMAIN queries, and check if NXDOMAIN is pushing you into truncation,
fragmentation, or TCP fallback.

6) If I switch from NSEC3 to NSEC, will validators break?

They shouldn’t, as long as the zone is correctly signed and published. But the transition is operationally sensitive: roll it out
carefully and monitor validation and caching behavior.

7) Is NSEC always faster than NSEC3?

Often, yes—especially for negative responses—because proofs are simpler and typically smaller. But your mileage depends on your zone
content, server implementation, and client networks.

8) What about NSEC3 opt-out—should I use it?

Opt-out exists mainly for zones with many insecure delegations (like some registries) to reduce record count and operational burden.
It also complicates assurance semantics. If you can’t explain what it does to an auditor and to on-call, don’t use it casually.

9) Our security team wants NSEC3 to prevent “attackers learning our subdomains.” What should I tell them?

Tell them NSEC3 reduces trivial enumeration but does not prevent guessing, CT-derived discovery, or passive DNS discovery. If they still
want it, insist on a response-size budget and operational SLOs so reliability doesn’t get traded away silently.

10) What is the most common DNSSEC failure that looks like performance?

Fragmentation-driven loss and retries. It manifests as intermittent timeouts and higher tail latency, not a clean “down” event.
DNSSEC (and especially heavy negative answers) can push you into that regime.

Conclusion: what to do next (practical, not spiritual)

NSEC3 is not “DNSSEC but more.” It’s a specific trade: less name disclosure in exchange for more complexity, bigger negative answers,
and a higher chance you’ll discover that parts of the internet still can’t carry your packets reliably.

Next steps that pay rent:

1. Measure NXDOMAIN behavior in your zone: size, latency, TCP fallback rate, and fragmentation signals.
2. Decide if enumeration is a real problem for your zone. If names are guessable, solve exposure and naming, not just denial proofs.
3. Pick a UDP budget and enforce it as a regression test for DNS changes, especially DNSSEC changes.
4. If you use NSEC3, keep parameters conservative and separate parameter changes from key rollovers.
5. Operationalize validation: runbooks, multi-vantage testing, and alerts for signature expiration and TCP spikes.

Run DNSSEC like you run storage: assume failures, watch tail latency, and prefer the simplest design that meets the actual requirement.
NSEC is often that design. NSEC3 is for when you can name the enemy and accept the bill.