Standard defenses against DNS cache poisoning, such as source port randomization, significantly increase the search space for an off-path attacker. By randomizing the 16-bit source port, the total entropy becomes a combination of the 16-bit transaction ID (TXID) and the port, theoretically requiring an attacker to guess a 32-bit value. However, this is not an insurmountable obstacle. The effectiveness of this entropy is constrained by the principles of probability, specifically the Birthday Paradox., which dramatically reduces the number of packets required for a successful collision.

An attacker doesn't need to guess the exact TXID and port for a specific query. They only need to generate a flood of forged responses where one response's TXID/port combination matches any of the outstanding queries initiated by the target resolver within a given attack window. The probability of a successful collision after sending $k$ packets to a resolver with a query window of $n$ outstanding requests is significantly higher than a naive brute-force calculation would suggest.

The true innovation of the Kaminsky attack was shifting the target from an existing, likely cached record to a non-existent one. This forces the target recursive resolver to contact the authoritative nameserver, predictably opening an attack window. The attack proceeds in a specific sequence, exploiting a race condition.

The malicious payload is the key. While providing a bogus answer for the non-existent record, the attacker includes an additional record that redefines the authoritative nameserver for the parent domain. For example, the response might state that the nameserver for victim.com is now evil-ns.attacker.net, pointing to an IP address controlled by the attacker. Since the target resolver was actively seeking information within the victim.com zone, this additional data is considered relevant, or "in-bailiwick", and is accepted into the cache.

Once this malicious NS record is cached, the attacker gains control. Any subsequent query for any host within victim.com will be sent to the attacker's nameserver, allowing them to forge any IP address they wish, effectively hijacking the entire domain from the perspective of the resolver's clients.

The concept of bailiwick checking is a fundamental defense. A resolver should only cache answers that are relevant to the question asked. For example, if a resolver asks for www.example.com, it should not blindly trust an additional record in the response that defines the IP for www.google.com. That would be an out-of-bailiwick response.

The Kaminsky attack exploits the gray area. The query for random.victim.com makes information about the victim.com zone relevant. The malicious NS record for victim.com is considered in-bailiwick because it provides authoritative information about the domain being queried. The resolver sees it as a helpful delegation pointer, not a malicious injection.

This is further complicated by cache overwriting rules, defined in RFC 2181. DNS records have a 'trust' level, and a resolver's cache will typically prefer to keep existing data unless the new data has a higher trust level. However, because the initial query was for a non-existent domain, there is no existing data in the cache to have a trust battle with. The forged record is the first and only entry, so it gets written to the cache unopposed.

Modern high-performance recursive resolvers like BIND, Unbound, and Knot are particularly susceptible to creating the necessary race condition, especially in complex enterprise environments. These resolvers are designed to handle thousands of concurrent queries. In a large ERP system, for example, hundreds of clients might simultaneously query for different, non-existent internal subdomains during a service discovery failure. This high concurrency creates a wide attack window ($n$ in our earlier formula), making it easier for an attacker to land a successful collision without needing an extreme number of forged packets.