[GH-ISSUE #2811] RRSIG verification failure #1064

New issue

Closed

opened 2026-03-16 01:30:18 +03:00 by kerem · 2 comments

kerem commented

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

Owner

Originally created by @divergentdave on GitHub (Feb 27, 2025).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2811

Describe the bug
Two tests in #2807 had to be ignored because the signature over one particular NSEC3 record cannot be verified. This is a repeatable issue. It's possible the NSEC3 or RRSIG record may be mutated between signing, server, client, and verification. It's also possible we may be constructing the to-be-signed data incorrectly during either signing or verification.

To Reproduce
Run invalid_nsec3_tests::wildcard_expansion or invalid_nsec3_tests::wildcard_no_data_error integration tests.

Expected behavior
This signature should verify, and the responses with wildcard expansion should be validated successfully.

Version:
Crate: hickory-proto
Version: see PR

Additional context
N/A

Originally created by @divergentdave on GitHub (Feb 27, 2025). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2811 **Describe the bug** Two tests in #2807 had to be ignored because the signature over one particular NSEC3 record cannot be verified. This is a repeatable issue. It's possible the NSEC3 or RRSIG record may be mutated between signing, server, client, and verification. It's also possible we may be constructing the to-be-signed data incorrectly during either signing or verification. **To Reproduce** Run `invalid_nsec3_tests::wildcard_expansion` or `invalid_nsec3_tests::wildcard_no_data_error` integration tests. **Expected behavior** This signature should verify, and the responses with wildcard expansion should be validated successfully. **Version:** Crate: hickory-proto Version: see PR **Additional context** N/A

kerem closed this issue

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

kerem commented

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

Author

Owner

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

This is happening because the name server includes one NSEC3 record twice when responding to this query. As a result, the reconstructed TBS data doesn't match for this RRset. The q04jkcevqvmu85r014c7dkba38o0ji5r.example. record serves double duty as the covering record for the next closer name, and the covering record for the wildcard name at the closest encloser. Thus, we'll need to deduplicate in get_nsec3_records().

@divergentdave commented on GitHub (Mar 24, 2025): This is happening because the name server includes one NSEC3 record twice when responding to this query. As a result, the reconstructed TBS data doesn't match for this RRset. The `q04jkcevqvmu85r014c7dkba38o0ji5r.example.` record serves double duty as the covering record for the next closer name, and the covering record for the wildcard name at the closest encloser. Thus, we'll need to deduplicate in `get_nsec3_records()`.

kerem commented

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

Author

Owner

@divergentdave commented on GitHub (Apr 25, 2025):

This was fixed in #2885. The tests are now failing for different reasons, one of them due to #2882, and one due to #2949.

@divergentdave commented on GitHub (Apr 25, 2025): This was fixed in #2885. The tests are now failing for different reasons, one of them due to #2882, and one due to #2949.

kerem referenced this issue

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

[PR #1064] [MERGED] Expose LabelIter #1939