[GH-ISSUE #2626] NSEC3: Limit number of iterations #1029

New issue

Closed

opened 2026-03-16 01:19:03 +03:00 by kerem · 5 comments

kerem commented

2026-03-16 01:19:03 +03:00

Owner

Originally created by @divergentdave on GitHub (Nov 28, 2024).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2626

There should be a limit on the number of iterations that Hickory DNS will accept in an NSEC3 record. This should probably be configurable. RFC 5155 section 10.3 suggests some upper limits, depending on the key size. It says that if the signature over the NSEC3 record is correct, and the iteration count is too high, resolvers may treat responses as insecure, skipping the iterated hash computation. RFC 9276 makes the case that iteration counts greater than zero do not meaningfully improve the ability to obfuscate domains, while they increase the impact of DoS attacks against CPU. Therefore, it recommends treating validly-signed NSEC3 records as insecure at a lower iteration count limit. It also recommends an additional iteration count threshold at which the resolver starts returning SERVFAIL responses.

Relatedly, Nsec3HashAlgorithm::hash() is implemented recursively, which means DoS attacks using high iteration counts could try to exhaust stack memory.

Originally created by @divergentdave on GitHub (Nov 28, 2024). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2626 There should be a limit on the number of iterations that Hickory DNS will accept in an NSEC3 record. This should probably be configurable. [RFC 5155 section 10.3](https://www.rfc-editor.org/rfc/rfc5155#section-10.3) suggests some upper limits, depending on the key size. It says that if the signature over the NSEC3 record is correct, and the iteration count is too high, resolvers may treat responses as insecure, skipping the iterated hash computation. [RFC 9276](https://datatracker.ietf.org/doc/html/rfc9276) makes the case that iteration counts greater than zero do not meaningfully improve the ability to obfuscate domains, while they increase the impact of DoS attacks against CPU. Therefore, it recommends treating validly-signed NSEC3 records as insecure at a lower iteration count limit. It also recommends an additional iteration count threshold at which the resolver starts returning `SERVFAIL` responses. Relatedly, `Nsec3HashAlgorithm::hash()` is implemented recursively, which means DoS attacks using high iteration counts could try to exhaust stack memory.

kerem

2026-03-16 01:19:03 +03:00

closed this issue
added the
trust
label

kerem commented

2026-03-16 01:19:20 +03:00

Author

Owner

@marcus0x62 commented on GitHub (Nov 28, 2024):

I have a patch for this that is mostly complete. I'll clean it up over the next week and get it ready for review.

@marcus0x62 commented on GitHub (Nov 28, 2024): I have a patch for this that is mostly complete. I'll clean it up over the next week and get it ready for review.

kerem commented

2026-03-16 01:19:25 +03:00

Author

Owner

@djc commented on GitHub (Jan 16, 2025):

I have a patch for this that is mostly complete. I'll clean it up over the next week and get it ready for review.

Would be nice if you can still get to this!

@djc commented on GitHub (Jan 16, 2025): > I have a patch for this that is mostly complete. I'll clean it up over the next week and get it ready for review. Would be nice if you can still get to this!

kerem commented

2026-03-16 01:19:30 +03:00

Author

Owner

@bluejekyll commented on GitHub (Mar 2, 2025):

Is this still open?

@bluejekyll commented on GitHub (Mar 2, 2025): Is this still open?

kerem commented

2026-03-16 01:19:35 +03:00

Author

Owner

@divergentdave commented on GitHub (Mar 2, 2025):

We have changed Nsec3HashAlgorithm::hash() from a recursive function to a loop, which avoids blowing the stack, but we haven't put in an upper limit on iterations yet.

@divergentdave commented on GitHub (Mar 2, 2025): We have changed `Nsec3HashAlgorithm::hash()` from a recursive function to a loop, which avoids blowing the stack, but we haven't put in an upper limit on iterations yet.

kerem commented

2026-03-16 01:19:40 +03:00

Author

Owner

@divergentdave commented on GitHub (May 20, 2025):

Fixed in #2899

@divergentdave commented on GitHub (May 20, 2025): Fixed in #2899

kerem referenced this issue

2026-03-16 03:10:43 +03:00

[PR #1029] [MERGED] Bump enum-as-inner from 0.3.0 to 0.3.1 #1893