Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
When the Hickory DNS resolver follows CNAME records, it sends queries that are not necessary to answer the original recursive query. If there are any CNAME records in the authority section or additional section of the response, queries will be sent for those names. If there are any CNAME records that are not part of a CNAME chain starting from the original recursive query name, queries will be sent for those names. This increases query amplification beyond what is necessary to answer the recursive query.
Recommended action: Upgrade to 0.26.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When the hickory-resolver name server pool implementation receives an upstream response with the TC (truncated) header bit set, it re-queues the request to the same nameserver to retry with UDP transport disabled. However, the retry arm never inspects the transport that just answered and carries no iteration counter. An authoritative server that sets TC=1 on every available transport keeps the resolver spinning on one persistent TCP connection until the 5s per-request wall-clock deadline expires. Reporter Qifan Zhang, Palo Alto Networks
Recommended action: Upgrade to 0.26.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When calling Resolver::lookup() or Resolver::lookupip() on a resolver with DNSSEC validation enabled, both methods return Ok(...) if DNSSEC validation fails. It is possible but very inconvenient to check the validation status of individual records. These methods should instead return an error when DNSSEC validation determines a response is bogus.
Recommended action: Upgrade to 0.26.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.