SAD DNS: A New Twist on a Classic DNS Poisoning Attack

At ACM CCS 2020, researchers from UC Riverside and Tsinghua University presented a new attack against the Domain Name System (DNS) called SAD DNS (Side channel AttackeD DNS). The attack revives DNS cache poisoning by exploiting features of the networking stack in modern operating systems such as Linux. Cloudflare was part of the coordinated disclosure effort, and the 1.1.1.1 Public Resolver has since been hardened against the attack.

How DNS Pairing Works

DNS translates human-readable domain names into IP addresses. The protocol exchanges messages between clients, recursive resolvers, and authoritative nameservers. Most of these exchanges still occur over UDP, which is stateless and unauthenticated. Any party can send a response with a forged source address and port.

To pair a response with an outstanding query, DNS relies on randomness in the message. The transaction ID in the first two bytes of the message must match between query and response. This introduces only 16 bits of entropy, meaning fewer than a hundred thousand possibilities. The query name and type are also checked, but these are easily guessable and add no entropy.

The attack targets the communication between recursive resolvers and authoritative nameservers. While much of the industry has focused on encrypting traffic between users and resolvers, the resolver-to-authoritative path remains largely UDP-based.

Evolution from Kaminsky's Attack

Before 2008, recursive resolvers typically used a single source port (usually port 53) for all queries. To poison a cache, an attacker only needed to guess the 16-bit message ID. The Kaminsky attack exploited this by flooding a resolver with forged responses for all possible message IDs. The first response to arrive with the correct ID would be cached.

Resolvers responded with source port randomization, expanding the search space from tens of thousands to over a billion guesses. The IETF also published RFC 5452 on hardening DNS against guessing attacks. DNSSEC-signed domains were never vulnerable because their answers are digitally signed, but even in 2020 DNSSEC is not universal.

Fragmentation-Based Bypass

In 2012, researchers found a way to defeat source port randomization using UDP fragmentation. All the randomness in a DNS poisoning attack sits at the beginning of the message, in the UDP header and DNS header. If the response datagram is split into two fragments, the second fragment contains no randomness beyond its IP-ID. The attacker only needs to forge the second fragment and ensure it arrives before the legitimate one.

This technique requires two preconditions: the response must actually be fragmented, and the forged fragment must pass section counts and the UDP checksum. More recent work showed how an attacker can force fragmentation at a controlled point by forging a UDP packet that influences the maximum transmissible unit (MTU) discovery mechanism between two servers.

Fragmentation-based attacks have become less practical as DNS providers move to reject fragmented DNS packets, a goal of DNS Flag Day 2020.

The ICMP Side Channel

The SAD DNS researchers found a different way to defeat source port randomization. Instead of guessing which ports are open, the attacker discovers which ones are safely closed, thereby eliminating them from consideration. An ICMP "port unreachable" message reveals when a UDP port is closed.

This approach breaks against resolvers that use connected UDP sockets, which bind the source address and port at the OS layer. The attacker cannot directly observe whether a probe to a connected socket produces an ICMP reply. The researchers overcame this using ICMP rate limiting as a side channel:

don't let private information influence publicly measurable metrics

The attack exploits how rate limits leak information. An attacker sends spoofed UDP packets from the victim nameserver's address to the target resolver. If a port is closed, the resolver sends an ICMP reply back to the victim and the rate counter increments. If the port is open, no reply is generated. The attacker cannot observe these replies directly, but can influence the shared rate counter. By sending a verification packet from its own address, the attacker can check whether the rate limit has been hit, leaking a single bit about the counter's state. Repeated queries let the attacker determine whether a specific port is open or closed.

In practice, three hurdles complicate the attack:

  • Discovering the target IP addresses requires either known infrastructure such as a forwarder or observing resolver egress addresses through attacker-controlled zones.
  • The ICMP rate limit must be high enough to permit fast scanning while the target query is still pending. The researchers suggest extending the window by triggering the victim's response rate limiting (RRL), though only about 16% of nameservers implement RRL.
  • Busy resolvers have ephemeral ports constantly opening and closing, producing false positives that slow the scan.

Mitigations and Outlook

Cloudflare's additional protection for 1.1.1.1 is straightforward: if the resolver detects an ID enumeration attempt, it stops accepting guesses and switches to TCP. This limits the attacker's attempts even if it guesses both IP address and port correctly.

The broader lesson is that hiding source IPs and port numbers is security through obscurity. Without cryptographic authentication, spoofing will always threaten DNS resolvers. Work continues on several complementary fronts:

  • DNSSEC, which directly addresses spoofing with digital signatures.
  • RFC 7873 (DNS Cookies) to add entropy to DNS messages.
  • RFC 7766 making DNS over TCP support mandatory.
  • Exploration of stronger transports such as TLS for resolver-to-authoritative communication.

Operators of DNS forwarders and recursive resolvers should take these steps:

  • Upgrade the Linux kernel with commit b38e7819cae946e2edf869e604af1e65a5d241c5 (included with v5.10), which uses unpredictable ICMP rate limits.
  • Block outgoing ICMP "port unreachable" messages with iptables or lower the ICMP rate limit on Linux.
  • Keep DNS software up to date.