DNSSEC Validation Bypass via Out-of-Zone NSEC Next Field
The BIND resolver accepts validly-signed NSEC records where the "Next Domain Name" field points outside the signer's zone.
193 records
The BIND resolver accepts validly-signed NSEC records where the "Next Domain Name" field points outside the signer's zone.
If a provably insecure domain is covered by both an NSEC and NSEC3 record at the parent, and there exist an RRSIG for only one of these types, then BIND may exit unexpectedly with an assertion while validating this proof…
The issue is unexpected program termination based on ordering and/or specific content in responses to queries for CNAME or DNAME, and A records.
It is possible for an attacker's zone to respond to a query with an RRSIG that has a smaller number of labels than the zone in which the RRSIG is contained.
A DNSSEC validating resolver that is under a random subdomain attack against a DNSSEC-signed zone can suffer from runaway memory usage.
The issue is a resource exhaustion vulnerability associated with DNSSEC validation.
An attacker who knows (or guesses) that a resolver uses RPZ with wildcard CNAME policies can craft query names long enough to trigger a NAMETOOLONG error condition during RPZ processing.
If BIND encounters a particular invalid data structure in a DNS record, it will accept the invalid data, and may subsequently abort and exit.
BIND may accept incorrect child-zone NSEC3 records as valid, which could allow an attacker to forge authenticated NXDOMAIN responses.
An unbounded resend loop vulnerability exists in the BIND 9 resolver state machine during bad-server handling, enabling a remote unauthenticated attacker to cause severe resource exhaustion by sending queries that trigge…
Undefined behavior may result due to a race condition leading to a use-after-free violation.
Multiple flaws have been identified in `named` related to the handling of DNS messages whose CLASS is not Internet (`IN`) — for example, `CHAOS` or `HESIOD`, or DNS messages that specify meta-classes (`ANY` or `NONE`) in…
A use-after-free vulnerability exists within the DNS-over-HTTPS implementation.
BIND resolvers are vulnerable to an amplified resource consumption/exhaustion attack.
BIND servers that are configured to use TKEY-based authentication via GSS-API tokens are vulnerable to excessive memory consumption when receiving and processing maliciously-constructed packets.
A use-after-return vulnerability exists in the `named` server when handling DNS queries signed with SIG(0).
Under certain conditions, `named` may crash when processing a correctly signed query containing a TKEY record.
A specially crafted domain can be used to cause a memory leak in a BIND resolver simply by querying this domain.
If a BIND resolver is performing DNSSEC validation and encounters a maliciously crafted zone, the resolver may consume excessive CPU.
The Closest Encloser Proof aspect of the DNS protocol (in RFC 5155 when RFC 9276 guidance is skipped) allows remote attackers to cause a denial of service (CPU consumption for SHA-1 computations) via DNSSEC responses in…
Certain DNSSEC aspects of the DNS protocol (in RFC 4033, 4034, 4035, 6840, and related RFCs) allow remote attackers to cause a denial of service (CPU consumption) via one or more DNSSEC responses, aka the "KeyTrap" issue…
To keep its cache database efficient, `named` running as a recursive resolver occasionally attempts to clean up the database.
If a resolver cache has a very large number of ECS records stored for the same name, the process of cleaning the cache database node for this name can significantly impair query performance.
A bad interaction between DNS64 and serve-stale may cause `named` to crash with an assertion failure during recursive resolution, when both of these features are enabled.
A flaw in query-handling code can cause `named` to exit prematurely with an assertion failure when: - `nxdomain-redirect <domain>;` is configured, and - the resolver receives a PTR query for an RFC 1918 address that woul…