DNS cache poisoning and protocol weaknesses¶

Attack pattern¶

A resolver accepts the first answer that fits, and fitting means a sixteen-bit transaction ID, a source port, and a question section that matches the one it asked. That is the entire authentication story for plaintext DNS. Kaminsky turned it into a practical race in 2008, source port randomisation bought back roughly sixteen more bits of guessing, and fragmentation attacks have been working the margin ever since by arranging for the second fragment of a forged reply to arrive without the header that would have been checked. DNSSEC answers the right question, signing the data rather than guarding the channel, and hands over a zone-walking problem and a set of much larger responses in exchange. Encryption answers a different question again: DoT, DoH and DoQ hide the query from the path, and none of them tells the resolver whether the answer is true.

1. Exploit Protocol Weaknesses [OR]

    1.1 Cache Poisoning [OR]

        1.1.1 Exploit weak TXID entropy in DoH/DoT/DoQ resolvers [OR]
            1.1.1.1 Birthday attack on 16-bit TXID space
            1.1.1.2 Timing attacks on resolver response handling
            1.1.1.3 Fragment-based poisoning attacks

        1.1.2 Side-channel attacks on encrypted DNS [OR]
            1.1.2.1 TLS padding oracle attacks on DoT
            1.1.2.2 QUIC protocol timing analysis on DoQ
            1.1.2.3 HTTP/2 stream correlation attacks on DoH

        1.1.3 DNSSEC Exploitation [OR]
            1.1.3.1 NSEC/NSEC3 walking for zone enumeration
            1.1.3.2 RRSIG timing attacks for key recovery
            1.1.3.3 Algorithm downgrade attacks (to SHA-1 or an unsupported algorithm)

        Prerequisite: AND (Attacker can intercept traffic AND resolver lacks full DNSSEC validation)

    1.2 DDoS Amplification [OR]

        1.2.1 Abuse misconfigured encrypted DNS resolvers [OR]
            1.2.1.1 DoQ reflection with large TXT records
            1.2.1.2 DoH POST request amplification
            1.2.1.3 DoT session resumption attacks

        1.2.2 DNSSEC-based amplification [OR]
            1.2.2.1 NSEC3 response amplification
            1.2.2.2 Large RRSIG reflection attacks
            1.2.2.3 DNAME chain exploitation

        Prerequisite: AND (Open resolver available AND vulnerable payload size > 1000 bytes)

    1.3 Protocol-Specific Vulnerabilities [OR]

        1.3.1 QUIC Protocol Exploitation (DoQ) [OR]
            1.3.1.1 Connection migration hijacking
            1.3.1.2 Stream priority manipulation
            1.3.1.3 QUIC spin bit side-channel

        1.3.2 HTTP/2 Exploitation (DoH) [OR]
            1.3.2.1 HPACK header compression attacks
            1.3.2.2 Server push cache poisoning
            1.3.2.3 Stream dependency manipulation

        1.3.3 TLS Session Attacks (DoT) [OR]
            1.3.3.1 Session ticket stealing
            1.3.3.2 Pre-shared key exhaustion
            1.3.3.3 Certificate transparency log poisoning

First answer wins¶

The transaction ID is sixteen bits. Source port randomisation added about sixteen more, and both remain guesses rather than proofs.
Fragmentation sidesteps the guess entirely. A forged second fragment carries no UDP header, so the port and the transaction ID are never rechecked.
DNSSEC signs the data rather than the channel. A validated answer can still be read in transit, and an unvalidated one still travels through every resolver that declines to enforce.
NSEC3 hashes the names it denies, which slows zone walking rather than ending it. The hashes crack offline, at leisure.
Signed responses are big. RRSIG and DNSKEY records tend to make DNSSEC a better amplifier than the zone it was deployed to protect.
Encryption changes who can watch, not who can lie. DoT, DoH and DoQ each authenticate the resolver; none authenticates the answer.
Reflection needs transport that can be spoofed. QUIC caps unvalidated sends at three times what it received, and DoH wants a completed handshake first, so amplification stays largely a plaintext story on port 53.