A vulnerability in Hickory DNS validating recursor versions 0.25.0 through 0.26.0-alpha.1, hickory-resolver 0.26.0-alpha.1 before 0.26.2, and hickory-net 0.26.0-beta.1 before 0.26.2 allows caching of DNSSEC-bogus answers with an attacker-controlled TTL up to 24 hours. This occurs because the recursor uses the untrusted TTL from the attacker-supplied record instead of a short validation-failure TTL. An attacker can exploit this by spoofing an authoritative response with an invalid signature and a long TTL, causing the bogus result to be cached for up to 24 hours.
A vulnerability in Hickory DNS components hickory-proto (versions 0.25.0 through 0.26.0-alpha.1) and hickory-net (versions before 0.26.2) causes incorrect relational operator logic in the NSEC3 record handling. This flaw allows the last NSEC3 record in a zone's hash ring to incorrectly cover every hash except its owner. An attacker capable of injecting DNS responses can exploit this to replay the NSEC3 record and its RRSIG, forging DNSSEC-validated negative responses that deny legitimate domain names.
Hickory DNS versions hickory-proto 0.25.0-alpha.1 through 0.26.0-alpha.1 and hickory-net before 0.26.2 have a logic bug in the DS-fetch path of DnssecDnsHandle. This bug causes transient DS lookup errors such as SERVFAIL, REFUSED, or timeouts to be cached as Bogus DNSSEC validation verdicts. As a result, the validator returns SERVFAIL for all names under the affected child zone until the cache entry's TTL expires.
A vulnerability in the hickory-net crate of Hickory DNS versions 0.26.0 up to but not including 0.26.2 causes the service to stop listening and return an error when receiving malformed UDP datagrams that cannot be parsed as DNS messages. Attackers who can guess the source port of a query, even without knowing the transaction ID, can send spoofed malformed responses to abort client queries, resulting in denial of service.
A vulnerability in the hickory-net crate of Hickory DNS versions 0.26.0-beta.1 up to but not including 0.26.2 allows DNSSEC validation bypass. This occurs because the Name's hash function ignores label lengths and the ValidationCacheKey compares only that hash. An attacker controlling an unsigned delegation differing only in dot positions from a signed target can cause an Insecure verdict, leading to forged DNS answers bypassing signature verification.
Hickory DNS versions hickory-net 0.26.0-beta.1 before 0.26.2 and hickory-proto 0.24.0 through 0.26.0-alpha.1 improperly compare DNSKEY public keys against DNSSEC trust anchors without verifying the DNSKEY record name. This flaw allows an attacker who can spoof or control DNS responses to replace a secure zone's DNSKEY RRset with the root zone's keys and use a large TTL to keep the malicious keys cached.
Hickory DNS versions hickory-proto through 0.26.0-alpha.1 and hickory-net 0.26.0-beta.1 before 0.26.2 have an NSEC validation flaw. This flaw causes the software to incorrectly return a secure proof for NXDOMAIN responses when the covering NSEC's Next Domain Name is a strict descendant of the query name, which actually indicates the name exists as an empty non-terminal. On-path attackers can exploit this to change a genuine signed NODATA response's unsigned rcode from NOERROR to NXDOMAIN, leading validators to accept a forged nonexistence of the queried name.
Hickory DNS versions hickory-net 0.26.0-beta.1 before 0.26.2 and hickory-proto through 0.26.0-alpha.1 improperly accept NSEC and NSEC3 DNSSEC nonexistence proofs when other records with the same owner name validate correctly. This allows attackers who can supply DNS responses to mix valid signed records with bogus NSEC or NSEC3 records of different types in the authority section, potentially forging nonexistence proofs.
Hickory DNS versions hickory-net 0.26.0-beta.1 before 0.26.2 and hickory-proto through 0.26.0-alpha.1 do not properly verify, according to RFC 6840 §4.4, that an NSEC or NSEC3 record denying a DS RRset also proves the existence of the delegation's NS record. This flaw allows attackers to reuse child-side NSEC or NSEC3 records to fake an insecure delegation and forge child-zone records.
A vulnerability in the DNSSEC validation of the Hickory DNS hickory-net crate versions 0.26.0 up to but not including 0.26.2 allows attackers who can supply DNS responses to forge the nonexistence of any resource record set (RRset). This is achieved by combining a genuine NSEC record and its RRSIG with a crafted SOA record that is accepted even if it fails validation.
Hickory DNS components hickory-net versions before 0.26.2 and hickory-proto versions 0.25.0 through 0.25.2 have a vulnerability where UDP DNS responses with an empty question section (QDCOUNT=0) bypass validation checks. This allows remote attackers who can inject spoofed UDP responses to circumvent question section matching and case-randomization checks, weakening DNS spoofing defenses.
A vulnerability in hickory-proto and hickory-net affects the NSEC3 closest-encloser proof validation process. When validating DNSSEC responses with a mismatched SOA owner in the authority section, the code enters an unbounded loop, causing memory exhaustion in release builds or a panic in debug builds. This can be triggered by specially crafted DNS responses involving NoData or NXDomain with cross-zone SOA records. The issue is fixed in hickory-net version 0.26.1.
A vulnerability in hickory-net's DNSSEC validation causes an unbounded loop during NSEC3 closest-encloser proof validation when the SOA record in a DNS response's authority section is not an ancestor of the queried name. This leads to memory exhaustion in release builds or a panic in debug builds. The issue affects versions prior to 0.26.1 and is triggered by certain NoData or NXDomain responses with mismatched SOA owners. Updating to version 0.26.1 resolves the issue.