[GH-ISSUE #3034] Recursor and forwarder drop NSEC/NSEC3 records from responses with wildcard expansion #1114

New issue

Open

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

kerem commented

2026-03-16 01:37:50 +03:00

Owner

Originally created by @divergentdave on GitHub (Jun 7, 2025).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/3034

When a response includes records resulting from wildcard expansion in a signed zone, NSEC/NSEC3 records and accompanying RRSIGs are included in the authority section to prove that the next closest encloser name does not exist, etc. The RecursiveAuthority does not currently pass these records on because they do not belong to the selected RRsets it returns with positive responses. Similarly, the ForwardAuthority filters the response records upon receiving a positive response, and does not include these records. In both cases, the authority needs to return a LookupObject, which includes one list of records and an optional LookupObject of additional section records. (Neither of the two returns anything from take_additionals()) NSEC/NSEC3 records are typically only returned when handling a name error or no data response, when they are stored within a ProtoError. A validating client downstream of either a forwarder or recursive name server would treat responses including wildcard-expanded records as bogus, since the closest encloser proof would be missing. Similar to #2781, the solution is to either change or replace LookupObject so that authorities return answer, authority, and additional records separately. This would also allow us to drastically simplify build_forwarded_response().

Originally created by @divergentdave on GitHub (Jun 7, 2025). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/3034 When a response includes records resulting from wildcard expansion in a signed zone, NSEC/NSEC3 records and accompanying RRSIGs are included in the authority section to prove that the next closest encloser name does not exist, etc. The `RecursiveAuthority` does not currently pass these records on because they do not belong to the selected RRsets it returns with positive responses. Similarly, the `ForwardAuthority` filters the response records upon receiving a positive response, and does not include these records. In both cases, the authority needs to return a `LookupObject`, which includes one list of records and an optional `LookupObject` of additional section records. (Neither of the two returns anything from `take_additionals()`) NSEC/NSEC3 records are typically only returned when handling a name error or no data response, when they are stored within a `ProtoError`. A validating client downstream of either a forwarder or recursive name server would treat responses including wildcard-expanded records as bogus, since the closest encloser proof would be missing. Similar to #2781, the solution is to either change or replace `LookupObject` so that authorities return answer, authority, and additional records separately. This would also allow us to drastically simplify `build_forwarded_response()`.