[GH-ISSUE #2882] Insufficient validation of wildcard expanded positive responses #1077

New issue

Closed

opened 2026-03-16 01:33:31 +03:00 by kerem · 1 comment

kerem commented

2026-03-16 01:33:31 +03:00

Owner

Originally created by @divergentdave on GitHub (Mar 24, 2025).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2882

Describe the bug
When a response is received that is the result of wildcard expansion, no validation is performed on accompanying NSEC or NSEC3 records that verify the non-existence of a closer match for the query.

To Reproduce
I identified this while working on the invalid_nsec3_tests::wildcard_expansion integration test.

Expected behavior
Section 5.3.4 of RFC 4035 says that the non-existence of matching records or wildcard records with a closer match must be verified. Similarly, Section 7.2.6 of RFC 5155 has requirements for wildcard answer responses when using NSEC3.

Version:
Crate: hickory-proto
Version: main

Additional context
There is an early return at the top of check_nsec() that returns Ok(...) if the answer section is non-empty. For starters, we will need to get rid of this. It might make sense to do positive and negative validation on an RRset-by-RRset basis, rather than separating out the positive response validation and NSEC/NSEC3 validation.

Originally created by @divergentdave on GitHub (Mar 24, 2025). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2882 **Describe the bug** When a response is received that is the result of wildcard expansion, no validation is performed on accompanying NSEC or NSEC3 records that verify the non-existence of a closer match for the query. **To Reproduce** I identified this while working on the `invalid_nsec3_tests::wildcard_expansion` integration test. **Expected behavior** [Section 5.3.4 of RFC 4035](https://datatracker.ietf.org/doc/html/rfc4035#page-32) says that the non-existence of matching records or wildcard records with a closer match must be verified. Similarly, [Section 7.2.6 of RFC 5155](https://www.rfc-editor.org/rfc/rfc5155#section-7.2.6) has requirements for wildcard answer responses when using NSEC3. **Version:** Crate: hickory-proto Version: main **Additional context** There is an early return at the top of `check_nsec()` that returns `Ok(...)` if the answer section is non-empty. For starters, we will need to get rid of this. It might make sense to do positive and negative validation on an RRset-by-RRset basis, rather than separating out the positive response validation and NSEC/NSEC3 validation.

kerem closed this issue

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

kerem commented

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

Author

Owner

@cpu commented on GitHub (Dec 2, 2025):

I think this was handled by https://github.com/hickory-dns/hickory-dns/pull/3349 ? Please reopen with details on what's left to do if I'm mistaken!

@cpu commented on GitHub (Dec 2, 2025): I think this was handled by https://github.com/hickory-dns/hickory-dns/pull/3349 ? Please reopen with details on what's left to do if I'm mistaken!

kerem referenced this issue

2026-03-16 04:00:36 +03:00

[PR #1077] [MERGED] use RuntimeProvider in https #1948

kerem referenced this issue

2026-03-16 04:17:12 +03:00

[PR #1077] [MERGED] use RuntimeProvider in https #1951