mirror of
https://github.com/hickory-dns/hickory-dns.git
synced 2026-04-25 03:05:51 +03:00
[GH-ISSUE #2851] When validating DNSSEC, signed domains with no keys get rejected #1073
Labels
No labels
blocked
breaking-change
bug
bug:critical
bug:tests
cleanup
compliance
compliance
compliance
crate:all
crate:client
crate:native-tls
crate:proto
crate:recursor
crate:resolver
crate:resolver
crate:rustls
crate:server
crate:util
dependencies
docs
duplicate
easy
easy
enhance
enhance
enhance
feature:dns-over-https
feature:dns-over-quic
feature:dns-over-tls
feature:dnsssec
feature:global_lb
feature:mdns
feature:tsig
features:edns
has workaround
ops
perf
platform:WASM
platform:android
platform:fuchsia
platform:linux
platform:macos
platform:windows
pull-request
question
test
tools
tools
trust
unclear
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/hickory-dns#1073
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @msrd0 on GitHub (Mar 14, 2025).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2851
Describe the bug
When validating DNSSEC, currently the following happens:
The last is definitely a weird edge case, but other resolvers (I tried cloudflare
1.1.1.1and dns.sb2a09::) that check DNSSEC pass, so hickory should probably pass the check as well.The domain I queried has the following DNSSEC visualisation by dnsviz.org:
To Reproduce
Expected behavior
I expected that hickory behaves similar to other dns servers, i.e. returns a record instead of SERVFAIL. This is what e.g. dns.sb does:
System:
Version:
Crate: hickory-dns
Version:
1660f95981(currently latest commit on main)Additional context
I discovered that while testing that #2428 is fixed.
@divergentdave commented on GitHub (Mar 14, 2025):
I can also reproduce this issue with the validating recursor. Here are some debug-level logs from this query.
Logs
The line
nsec3 proof for maxemann96.de., returning Bogus: no valid servicing wildcard prooflooks suspicious. Note that we already have recursor conformance tests covering insecure zones that nevertheless include DNSKEY record, seeresolver::dnssec::scenarios::insecure::no_ds_record_nsec3etc. I tried queryingDS maxemann96.de, and Hickory DNS returns SERVFAIL for that as well. Here's what Google Public DNS returns, FWIW.@divergentdave commented on GitHub (Mar 14, 2025):
Okay, looking at case 3 in
validate_nodata_response(), I think there are two things wrong here. First, we dofind_covering_record(...).iter().all(...)when checking if we should returnInsecureon an opt-out insecure delegation, but that would evaluate to true when we don't find a covering record, which is too permissive. Secondly, the predicate in the.all()combinator is checking if the covering NSEC3 record includes a DS RRset and is an opt-out NSEC3 record. The first condition is irrelevant, because we're looking at a covering NSEC3 record, not a matching NSEC3 record. The existence of the covering record means there's no authoritative data for the query, and the opt-out flag means there could be an insecure delegation as an exception.