DNS cache poisoning and BGP hijacking

Your HTTPS certificate is valid. Your server is correctly configured. But traffic meant for your domain is silently arriving at an attacker’s server — not because your code was compromised, but because either DNS or BGP was manipulated. These attacks happen at the infrastructure layer, below your application.

DNS cache poisoning: the Kaminsky attack (2008). An off-path attacker (no ability to eavesdrop traffic) can forge DNS responses by racing the real nameserver’s answer. DNS transaction IDs are only 16 bits — 65,536 possible values. If the attacker can send forged responses fast enough, they can guess the transaction ID and poison the resolver’s cache. The poisoned entry redirects all future lookups for that domain to the attacker’s IP.

Dan Kaminsky (2008) showed this was practical even with a fast resolver: by sending queries for random subdomains (a1b2.example.com, xyz9.example.com) the attacker forces many cache-miss lookups and has many guessing opportunities per second. Once poisoned, the cache serves the attacker’s IP for all users of that resolver — not just one user’s request.

Defenses against DNS cache poisoning.

Source-port randomization: The resolver uses a random UDP source port for each query, not a fixed one. This raises the entropy from 16 bits (transaction ID alone) to 32 bits (transaction ID + port), making brute-force guessing 65,536x harder. Modern resolvers enable this by default.

0x20 encoding: Randomize the capitalization of the domain name in the query — ExAmPlE.cOm — and verify the response matches the same capitalization. DNS is case-insensitive for lookups but a legitimate resolver echoes the query casing in the response. An attacker who does not see the outgoing query cannot know the casing. Adoption: under 0.4% globally (as of 2026).

DNSSEC: Cryptographically sign each RRset (DNS record set) at the zone level. The resolver validates signatures before caching. A forged response lacking the correct signature is rejected. Root zone, TLDs, and many second-level domains are DNSSEC-signed. Adoption: roots and TLDs are covered; second-level domain adoption is patchy.

BGP hijacking and route leaks. BGP (Border Gateway Protocol) is how Autonomous Systems (ASes) announce IP address blocks to each other across the Internet. An AS can announce a prefix it does not own — intentionally (hijack) or by misconfiguration (route leak). Once the bogus announcement propagates, traffic destined for the hijacked prefix is redirected to the announcing AS.

BGP hijack example: Pakistan Telecom (AS17557) accidentally announced YouTube’s prefixes (208.65.153.0/24) in 2008. The announcement propagated globally; YouTube traffic was routed to Pakistan, causing a 2-hour outage for global users.

RPKI: Resource Public Key Infrastructure. Resource holders publish Route Origin Authorizations (ROAs) in a public, cryptographically signed database. A ROA says “AS 64512 is authorized to originate prefix 192.0.2.0/24.” Routers that enforce ROV (Route Origin Validation) reject BGP announcements from unauthorized ASes.

As of 2026: ~54% of IPv4 and IPv6 prefixes have ROAs published, but only ~25% of networks enforce ROV. A ROA without ROV enforcement is useless — it marks the correct route but does not prevent the incorrect one from propagating.

BGPsec and MANRS. BGPsec cryptographically signs the AS path in BGP announcements, preventing path manipulation. CPU overhead is significant; adoption is minimal. MANRS (Mutually Agreed Norms for Routing Security) is an industry coalition where ~71% of signers commit to four practices: implement prefix filters, enforce ROV, maintain AS-WHOIS records, and notify peering partners of hijacks. MANRS has no enforcement mechanism — it is normative pressure, not technical enforcement.

TCP RST injection and RFC 5961. An attacker who can inject packets (on-path MITM) can forge a TCP RST with a sequence number in the receive window to tear down an established connection. RFC 5961 mitigations: challenge-ACK (if RST sequence number is in-window but not exact, respond with ACK of the expected next byte instead of closing; forces the attacker to guess exactly) and ACK throttling (rate-limit challenge ACKs to ~10 per 5 seconds to prevent information leakage). Only defends against off-path attackers; on-path MITM needs IPsec or TLS.