[GH-ISSUE #3143] Incorrect NSEC validation #1140

New issue

Closed

opened 2026-03-16 01:43:03 +03:00 by kerem · 0 comments

kerem commented

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

Owner

Originally created by @divergentdave on GitHub (Jul 22, 2025).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/3143

I found through differential testing that Hickory DNS is not validating NSEC records correctly. In particular, validation of a wildcard no data response is wrong. I found a lot of issues when reading through verify_nsec():

The wildcard variable is not a wildcard name, but either the query name's parent or the zone name (from the SOA record). Thus, later NSEC record coverage checks using this variable produce a misleading result when validating the response I was looking at, because there were only NSEC records covering the query name and the wildcard name, not the zone name.
- The wildcard == *query.name() special case should likewise be eliminated.
We should be checking the record types at any relevant wildcard name in addition to checking the record types at the query name, if there is a matching NSEC record.
The verify_nsec_coverage closure is actually checking whether a name is either covered by an NSEC record or matches an NSEC record. We should check these conditions separately.
We should add some checks for safety that the NSEC record names and query name are all descendants of the zone name from the SOA record. I don't want a Frankenstein-ed response with NSEC records from unrelated zones to pass validation.
The proof error messages in this function are misleading, and should be rewritten.
I think we should be checking record type bit maps for CNAME as well. RFC 5155 makes this more explicit for NSEC3 validation, but I think the same logic holds here -- if there is a matching CNAME or wildcard CNAME record, and it was not returned in the answer section, the response should be treated as bogus.
Unlike verify_nsec3(), verify_nsec() does not look at the response code. We should validate this against the presence of matching or covering NSEC records (again, considering both the query name and possible wildcard names).

Originally created by @divergentdave on GitHub (Jul 22, 2025). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/3143 I found through differential testing that Hickory DNS is not validating NSEC records correctly. In particular, validation of a wildcard no data response is wrong. I found a lot of issues when reading through `verify_nsec()`: * The `wildcard` variable is not a wildcard name, but either the query name's parent or the zone name (from the SOA record). Thus, later NSEC record coverage checks using this variable produce a misleading result when validating the response I was looking at, because there were only NSEC records covering the query name and the wildcard name, not the zone name. * The `wildcard == *query.name()` special case should likewise be eliminated. * We should be checking the record types at any relevant wildcard name in addition to checking the record types at the query name, if there is a matching NSEC record. * The `verify_nsec_coverage` closure is actually checking whether a name is either covered by an NSEC record or matches an NSEC record. We should check these conditions separately. * We should add some checks for safety that the NSEC record names and query name are all descendants of the zone name from the SOA record. I don't want a Frankenstein-ed response with NSEC records from unrelated zones to pass validation. * The proof error messages in this function are misleading, and should be rewritten. * I think we should be checking record type bit maps for CNAME as well. RFC 5155 makes this more explicit for NSEC3 validation, but I think the same logic holds here -- if there is a matching CNAME or wildcard CNAME record, and it was not returned in the answer section, the response should be treated as bogus. * Unlike `verify_nsec3()`, `verify_nsec()` does not look at the response code. We should validate this against the presence of matching or covering NSEC records (again, considering both the query name and possible wildcard names).