POPS: From History to Mitigation of DNS Cache Poisoning Attacks

TL;DR

This paper presents DNS-CPM, a two-stage DNS cache poisoning prevention system integrated into IPS that combines a fast, rule-based detection module with a TCP-based mitigation module using the TC flag. The detection relies on three practical rules to flag poisoning attempts, while mitigation ensures only legitimate responses proceed by establishing TCP sessions, yielding near-zero false positives and negatives in practice. Through historical analysis and PCAP-based simulations, DNS-CPM demonstrates exceptionally low attacker success rates (around 0.0076%) and significantly faster operation than Suricata or Snort, with the added ability to detect fragmentation and other attacks that prior tools miss. The approach provides proactive CVE mitigation, broad DNS protection with low overhead, and a clear path toward deployment in real-world DNS infrastructures.

Abstract

We present a novel yet simple and comprehensive DNS cache POisoning Prevention System (POPS), designed to integrate as a module in Intrusion Prevention Systems (IPS). POPS addresses statistical DNS poisoning attacks, including those documented from 2002 to the present, and offers robust protection against similar future threats. It consists of two main components: a detection module that employs three simple rules, and a mitigation module that leverages the TC flag in the DNS header to enhance security. Once activated, the mitigation module has zero false positives or negatives, correcting any such errors on the side of the detection module. We first analyze POPS against historical DNS services and attacks, showing that it would have mitigated all network-based statistical poisoning attacks, yielding a success rate of only 0.0076% for the adversary. We then simulate POPS on traffic benchmarks (PCAPs) incorporating current potential network-based statistical poisoning attacks, and benign PCAPs; the simulated attacks still succeed with a probability of 0.0076%. This occurs because five malicious packets go through before POPS detects the attack and activates the mitigation module. In addition, POPS completes its task using only 20%-50% of the time required by other tools (e.g., Suricata or Snort), and after examining just 5%-10% as many packets. Furthermore, it successfully identifies DNS cache poisoning attacks-such as fragmentation attacks-that both Suricata and Snort fail to detect, underscoring its superiority in providing comprehensive DNS protection.

Figures (8)

• Figure 1: Simple DNS Cache Poisoning Attack In a typical DNS cache poisoning attack (type $S$), the following steps occur. (A) A client controlled by the attacker queries a DNS resolver for a domain such as abc.com. (2) If the resolver does not have the response in its cache, it follows the DNS hierarchy to resolve the query. (3) At the bottom of the hierarchy, the resolver queries abc.com's authoritative server. (4) In parallel, both the correct response from the authoritative server and a set of fake responses from the attacker reach the resolver. The attacker attempts to guess necessary parameters—such as the transaction ID (TXID) or the source port of the resolver—to successfully poison the cache. It sends multiple responses based on the parameters it needs to guess. (5) If one of the attacker's packets has the correct parameters and arrives before the legitimate response, the resolver caches the fake response and returns it to the client.
• Figure 2: CMS illustration. CMS is defined by a number of hashed functions $d$, and the amount of counters per hash function $w$. In the subfigures, we describe each hash function as $H_i$. When a new element is obtained, it is hashed multiple times, and each hashed value is mapped to a cell in the respective row, increasing the counter in that cell (\ref{['fig:cms']}). When an element is estimated, it is hashed using each one of the hash functions, gathering all values from the appropriate cells, and obtaining the minimum value of these cells (\ref{['fig:cms_query']}).
• Figure 3: Memory usage comparison, between CMS and Heavy Hitters. The CMS algorithm gets high memory usage but is constant. At its peak, the CMS is less memory-consumable than the heavy hitters.
• Figure 4: Error rates comparison, between CMS and Heavy Hitters. The error rate of CMS is well under the heavy hitters, in order of magnitude ($\sim0.01$ vs more than 1, or more than 100).
• Figure 5: Inference time comparison, between CMS and Heavy Hitters. CMS's inference time is constant at 5, where the other algorithms increase based on the number of domains.