DNS-CPM: DNS Cache Poisoning Mitigation

Yehuda Afek Harel Berger

Tel Aviv University Georgetown University
afek@[Link] hb711@[Link]
Anat Bremler-Barr
Tel Aviv University
arXiv:2501.13540v1 [[Link]] 23 Jan 2025

anatbr@[Link]

Abstract and privacy enhancements [5, 6] add to this ever-increasing

complexity, demanding a structured, comprehensive approach
We present a novel yet simple and comprehensive DNS
to effectively address emerging challenges.
cache DNS Cache Poisoning Mitigation (DNS-CPM), de-
In a DNS cache poisoning attack, an attacker injects false
signed to integrate as a module in Intrusion Prevention Sys-
information into a DNS resolver’s cache. This manipulation
tems (IPS). DNS-CPM addresses statistical DNS poisoning
causes the resolver to return the wrong IP address for a target
attacks, including those documented from 2002 to the present,
domain name, redirecting users to malicious websites with-
and offers robust protection against similar future threats. It
out their knowledge. The attack can serve as a gateway to
consists of two main components: a detection module that
phishing [7], credential theft [8], malware infections [9], and
employs three simple rules, and a mitigation module that
other online threats. DNS cache poisoning remains one of the
leverages the TC flag in the DNS header to enhance security.
most persistent DNS-based attacks [8–11], despite multiple
Once activated, the mitigation module has zero false positives
attempts at mitigation [12, 13].
or negatives, correcting any such errors on the side of the
detection module. There are two primary types of DNS poisoning attacks. The
We first analyze DNS-CPM against historical DNS ser- first and more popular method involves delivering spoofed au-
vices and attacks, showing that it would have mitigated all thoritative responses to a resolver by faking the IP address of
network-based statistical poisoning attacks, yielding a suc- an authoritative name server, and guessing parameters such as
cess rate of only 0.0076% for the adversary. We then simulate the DNS transaction ID and source port to match a correspond-
DNS-CPM on traffic benchmarks (PCAPs) incorporating ing query issued by the resolver. The second uses advanced
current potential network-based statistical poisoning attacks, methods—like BGP hijacking [14] or MITM attacks [15]—to
and benign PCAPs; the simulated attacks still succeed with a bypass these guesswork steps, but is more complex to execute
probability of 0.0076%. This occurs because five malicious and therefore less common. Our study focuses on the former,
packets go through before DNS-CPM detects the attack and more prevalent type of attack.
activates the mitigation module. In addition, DNS-CPM com- Proposed in 1997, the DNS Security Extensions (DNSSEC)
pletes its task using only 20%–50% of the time required by protocol was designed to eliminate DNS cache poisoning at-
other tools (e.g., Suricata or Snort), and after examining just tacks through cryptographic authentication. However, with
5%–10% as many packets. Furthermore, it successfully iden- limited global adoption (<30%)1 and dependence on author-
tifies DNS cache poisoning attacks—such as fragmentation itative server implementation, DNSSEC has yet to achieve
attacks—that both Suricata and Snort fail to detect, underscor- universal protection. Partial mitigations, such as increased
ing its superiority in providing comprehensive DNS protec- randomness [13] and machine learning [16], address earlier
tion. attack vectors but prove less effective against more advanced
threats [17, 18].
In the absence of a universal solution, DNS vulnerabilities
1 Introduction are addressed reactively: when a new DNS cache poisoning
attack is discovered, it usually receives a Common Vulnera-
One of the cornerstones of our digital world is the Domain bilities and Exposures (CVE) identifier, prompting vendors
Name System (DNS) [1, 2], which translates human-readable to release updates. This reactive cycle requires ongoing vigi-
domain names into IP addresses. As the Internet’s reliance lance and frequent patches to maintain security.
on DNS grows, so does the complexity of this essential ser-
vice. Continual extensions, refinements [3, 4], and security 1 [Link]

1
 In this paper we address the challenges posed by DNS in Section 6. A list of the CVEs that our system would have
cache poisoning attacks, with a novel mitigation system called made superfluous is provided in Section 7. A comparison of
DNS Cache Poisoning Mitigation (DNS-CPM). The system our system to Suricata and Snort is presented in Section 8. A
consists of two components: a detection module (Section 4.1) discussion on our system can be found in Section 9. We con-
and a mitigation module (Section 4.2). The detection mod- clude our work and suggest future work in Section 10. Ethical
ule applies three simple rules, derived from a comprehen- considerations are elaborated in Section 11, and compliance
sive analysis of DNS cache poisoning attacks throughout with open science policy is provided in Section 12.
history, effectively capturing the unique attributes of statisti-
cal DNS cache poisoning. The mitigation module uses the TC
flag in the DNS header to force suspicious request/response 2 Background
transactions to switch from UDP to TCP—a more secure,
connection-oriented protocol whose stateful handshake and 2.1 DNS resolution and poisoning attacks
sequence number management prevent spoofing (in addition
When a DNS resolver receives a client query for domain D it
to unauthorized data injections, and session hijacking). An
first checks if D is in its cache; if not, it initiates a resolution
earlier deployment of a prototype of DNS-CPM, could have
process querying different name servers (NS) in the hierarchi-
blocked with high likelihood all the attack vectors explored
cal DNS system, until it reaches the authoritative NS which
in this study, including CVEs that were discovered from 2012
holds the authority for answering queries about D. Then, the
until 2024. (Employing the rules that are based only on the
authoritative NS sends a response with the IP address asso-
2002 attack, could have prevented 60% of subsequent DNS
ciated with D, back to the querying resolver. Upon receiving
cache poisoning vector attacks up to 2024.) Two important
the response, the resolver validates that the response UDP
practical properties that follow from our two-stage system
packet has the correct source port, transaction ID (TXID),
are; (1) ensuring that suspected DNS cache poisoning packets
domain name (D), and that the source IP address is the IP
are verified through a TCP session in the mitigation module,
address of the authoritative NS. If validation succeeds the
effectively eliminating possible false positives from the first
resource record (RR) in the response packet is inserted into
stage; and (2) allowing the detection module to err in the
the cache, with the corresponding time-to-live (TTL) value,
false-positive direction to minimize false negatives, which
and the corresponding IP address (A or AAAA type part of
decreases the attacker’s success rate to less than 1%. Our
the record) is delivered to the client.
system mitigates attacks and vulnerabilities described in aca-
In a cache poisoning attack an attacker inserts into the
demic literature and in DNS cache poisoning-related CVEs
resolver cache an incorrect mapping of a domain name to
(e.g., [19, 20]).
an IP address of a malicious server (e.g., mimicking central
The approach of building a system to prevent new attack
bank server). In the main variant of network based poisoning
vectors is also evident in the industry. For example, Akamai
attacks this is done by tricking the resolver to accept a fraud-
reported that their retrospective analysis enabled their defense
ulent response as if it came from the legitimate authoritative
systems to block future attack vectors, although they did not
NS with the intended malicious mapping. Mounting such an
provide specific details about the solution [21].
attack for domain D involves variations on these steps:
In summary, the contributions of this work are:
1. (optional) Remove a record for D from the resolver
• Quick and accurate detection with Minimal Over- cache, if such exists. This new step introduced here
head. Detecting poisoning attacks in under 1 second, to strengthen the attack. It can be achieved with the
after observing the first five packets. CachFlush technique of [22].
• Mitigation with Zero False Positives. DNS-CPM 2. Trick the resolver to query the authoritative NS of
leverages the TC bit to switch suspected responses from D, expecting a response with the IP address of D.
UDP to TCP, blocking only responses that indeed mas- This is achieved by a malicious client querying the
querade the legitimate authoritative server. resolver for the IP address of D, which is not in its
cache due to step 1, or other methods, such as query-
The remainder of this paper is organized as follows. Back-
ing a fake subdomain of D which is not in the cache [13].
ground for this work is provided in Section 2, including the
process of DNS resolution, the attacker’s threat model, and 3. While the resolver is expecting a response from the
the types of attacks examined in our work. Section 3 presents authoritative NS, provide it with a forged response with
the historical DNS cache poisoning attacks and mitigation the source IP of the authoritative NS.
methods as related work. Our methodology is given in Sec- 4. For the forged response in step 3 to be accepted by the
tion 4, including the detection and mitigation modules, their resolver it must have the correct port-number, TXID,
theoretical analysis, and implementation. The metrics used to and domain D, in addition to the correct IP address of
assess our system are also presented in this section. The exper- authoritative NS. The port number and TXID, which are
iments are described in Section 5. The results are presented randomly generated by the resolver, are not known to

2
 the attacker who has to guess them. future queries for subdomains of [Link] may return
5. If the attacker’s forged response is accepted by the re- malicious IP addresses under the attacker’s control.
solver, it is injected to the cache, saving fake mapping
of D in the cache (directly, or via a glue record [13]).
2.2 Threat Model
We distinguish between four major types of statistical poi- This paper considers the threat of off-path network based DNS
soning attack; S, SFrag , BFrag , SOoB , some of the type may cache poisoning attacks, targeting resolvers during the DNS
vriants on the steps: resolution process. We consider attackers mounting attacks
In type S (see Figure 1) in step 4 above, the attacker is of types S, SFrag , BFrag , SOoB , as described above in 2.1. The
trying many combinations of the (source) port number and resolver employs randomization techniques such as using
TXID in the hope that one of them will have the correct random source ports/DNS TXID3 to prevent an attacker from
number. If neither of the two may be obtained then it has guessing these parameters. To counteract this approach, the
1
232
possibilities, and if one of two may be acquired by the attacker uses the techniques described above in 2.1.
attacker then there are still 2116 possibilities. The attacker Our threat model assumes the attacker brute-force predicts
strategy is to send many combinations in the hope to hit the the DNS TXID and source port, and also the resolver lacks
correct one in order to succeed in the poisoning. Each forged additional security measures that could prevent such attacks
response guesses correctly either the TXID or the port number (e.g., DNSSEC). Also, the attacker is assumed to use the UDP
with probability (if nothing else is known) 2116 or both with transport protocol, except if forced otherwise by DNS-CPM.
probability 2132 2 . Attacks involving man-in-the-middle (MITM) positions,
In type SFrag , fragmentation is used as follows [24]: The BGP hijacking (e.g., [27–29]), or direct compromise of the
attacker first runs step 4, in which it sends a forged 2nd frag- resolver are out of scope for this study. we do not specifically
ment containing the mapping it wants to be cached. Then, it consider DNS cache poisoning attacks on clients, e.g., for-
follows step 2 by tricking the resolver to query authoritative warders, (e.g., [30, 31]), which generally have less impact,
NS with a query whose response size does not fit into one as they target a single client. Moreover, attacks on the DNS
UDP packet thus requiring fragmentation. While fragmented client can be mitigated by using our system with slight mod-
packets do not carry the port number nor the TXID, except for ifications. For example, embedding a syn-cookie in DNS-
the first fragment, they do carry a fragmentation ID (IPID) a CPM’s TCP connections [32, 33] can prevent the acceptance
16 bit number. When the first fragment from the authoritative of the attacker’s fake responses by the client. Additionally,
NS arrives at the resolver, it appends the already existing 2nd we exclude attacks that focus on improper processing of DNS
fragment if their IPIDs match. The response thus constructed responses [20]. These attacks exploit syntactic vulnerabil-
from the two fragments is delivered to the resolver which ities [34] and therefore require different mitigation strate-
then inserts the poisonous mapping of the 2nd fragment into gies [35], which are beyond the scope of this paper.
the cache. In this variant the attacker thus needs to send 216
different IPIDs 2nd fragment in order to succeed.
In type BFrag , the same procedure as with SFrag is followed 3 Related Work
except that it is a bullseye (B) attacker, which knows the IPID
number by other means and no guessing is required. 3.1 DNS Cache Poisoning Attacks Evolution
In type SOoB , the attacker exploits DNS resolvers that im- In this section, we present the DNS cache poisoning attacks
properly handle DNS records in a response that pertain to from the academic literature (see Table 1). For brevity, we
domains outside the authority of the domain that was queried mention the type of the attacks in parentheses (e.g., 2008 [13]
—a situation referred to as "out-of-bailiwick (OoB)." In this (S)). The first documented DNS cache poisoning attack dates
attack, in step 4, the attacker includes in the forged response back to 1993 [12], and involved creating a fake DNS response
an OoB record with the mapping it wishes to insert into the that arrives before the legitimate response. However, since this
cache (e.g., a mapping for [Link] while the original query attack is performed within the resolver itself, and our threat
was for [Link]. The .com domain is out of bailiwick model assumes an attacker residing outside the resolver, we
for .net). Due to inadequate validation, the resolver may erro- did not consider its implications in our study. Subsequently,
neously cache the additional OoB mappings. Consequently, two S type attacks were documented by Sacramento [36] and
2 However, in the past, the attacker could have used the birthday attack [23] Klein [37]. Both attacks assumed that the attacker knows the
in which it tricks the resolver into sending several requests concurrently for source port of the resolver because it is constant or can be
the target domain to the authoritative NS, then the probability of success in
1 1 3 Another existing security measurement is randomizing the capitalization
guessing a matching response is significantly increased to 700 to 400 due to
the birthday paradox. This birthday paradox attack has been patched since of letters in the domain name [25] using the 0x20 bit, which is validated by
2003 by all major DNS vendors and in any event with our mitigation, its the resolver if employed. However, there is no sufficient evidence for 0x20 bit
1
success would have been reduced to roughly 500 . global utility. Also, for short domain names, its effectiveness is limited [26].

3
 Paper Type #Pkts DNS-CPM
Schuba et al. [12] 1993 - 1 -
DNS
Hierarchy V. Sacramento [36] 2002 S 216 Rℓ1
(Q) [Link] (Q) [Link] Klein, Amit [37] 2007 S >100 Rℓ1
Src port: 888, Dest Port: 53 Src port: 7777, Dest Port: 53
TXID: 3456 2
TXID: 8999
Kaminsky, Dan [13] 2008 S 200 * q Rℓ1
1 3
Herzberg et al. [18] 2012 S 216 Rℓ1
Herzberg et al. [18] 2012 SFrag 216 Rℓ2
Client Herzberg et al. [38] 2013 BFrag 1 Rℓ2
5 DNS 4
Resolver Auth Herzberg et al. [39] 2013 SFrag ∼ 211 Rℓ2
(R) [Link] (R) [Link] Server
Ans: [Link] Ans: [Link] Herzberg et al. [40] 2013 S, SFrag 216 Rℓ1
Src port: 53, Dest Port: 888 Src port: 53, Dest Port: 7777
TXID: 3456 TXID: 8999 Zheng et al. [41] 2020 BFrag 1 Rℓ2
Man et al. [42] 2020 S 216 Rℓ1
(R) [Link]
4
Ans: [Link] Dai et al. [43] 2021 SFrag 64 Rℓ1
Src port: 53, Dest Port: ?
TXID: ? Klein et al. [44] 2021 S 216 Rℓ1
Jeitner et al. [45] 2022 S 216 Rℓ1
Jeitner et al. [45] 2022 S 216 Rℓ1
Li et al. [17] 2023 SOoB 216 Rℓ3
Attacker's
Server Heftring et al. [46] 2023 SFrag 216 Rℓ2
Li et al. [19] 2024 S 216 Rℓ1
Figure 1: Simple DNS Cache Poisoning Attack In a typi-
cal DNS cache poisoning attack (type S), the following steps Table 1: Significant DNS Cache Poisoning Attacks. The
occur. (A) A client controlled by the attacker queries a DNS ’Type’ column describes the type of the attack. Two major
resolver for a domain such as [Link]. (2) If the resolver types are described - Bullseye (B) and Statistical (S). B refers
does not have the response in its cache, it follows the DNS to an attack in which the targeted resolver sees only one
hierarchy to resolve the query. (3) At the bottom of the hier- packet the attacker generates. S denotes an attack in which
archy, the resolver queries [Link]’s authoritative server. (4) the attacker sends multiple packets to the resolver. A sole S
In parallel, both the correct response from the authoritative refers to an attack that involves TXID/Port guessing, SFrag
server and a set of fake responses from the attacker reach the denotes a fragmentation attack using multiple packets, BFrag
resolver. The attacker attempts to guess necessary parame- refers to a fragmentation attack using a single packet, and
ters—such as the transaction ID (TXID) or the source port SOoB refers to "Out-of-Bailiwick", the creation of packets that
of the resolver—to successfully poison the cache. It sends violate the Bailiwick rule. The number of packets used for the
multiple responses based on the parameters it needs to guess. attack is described in the #Pkts column. The q value refers
(5) If one of the attacker’s packets has the correct parameters to the number of queries during the attack. The last column
and arrives before the legitimate response, the resolver caches presents the DNS-CPM rules discussed in Section 4.
the fake response and returns it to the client.

for [Link], [Link], and so on. For each query, the at-
determined from other sources. In both the attacker uses brute- tacker guesses 200 TXIDs and sends fake responses to the
force guessing on the TXID and sends fake responses with resolver using these guessed TXIDs. Each forged response
each possible TXID to the resolver in parallel with the legit- includes glue records for the authoritative name server of the
imate response. At the time the attacks were published, the target domain (e.g., [Link]) that map this name server to
security measures included only semi-randomization of the a malicious IP address controlled by the attacker.
Transaction ID (TXID). Therefore, the attacker only needed Following Kaminsky’s attack, a new countermeasure was
to guess the 16-bit TXID correctly. implemented that involved randomizing both the transaction
The next attack to consider is Dan Kaminsky’s renowned ID (TXID) and the source port of resolver queries, requiring
DNS cache poisoning attack from 2008 [13] (S). In this at- an attacker to guess 32 bits to successfully spoof a response.
tack, the attacker assumes that the resolver’s source port is Subsequent attacks aimed to reduce this guessing requirement
known and aims to poison the cache with malicious informa- back to 16 bits by eliminating the need to guess one of these
tion. To achieve this, and bypass the limitation that the victim values. The first notable attempt to address this challenge
domain can be poisoned only when the TTL of the domain is was by Hertzberg et al. [18] (S), who focused on scenarios
expired, the attacker generates a large volume of queries to where the resolver is behind a Network Address Translation
non-existent subdomains of the target domain. For example, if (NAT). They developed methods to pin or predict the NAT
the target domain is [Link], the attacker queries the resolver port, thereby reducing the need to predict both the TXID and

4
the source port. In a subsequent study, Hertzberg [40] (S, in which an attacker induces a CDNS (a DNS server that
SFrag ) described attacks where the name server’s port is calcu- analyzes incoming queries and conditionally forwards them
lated using a query-generating zombie host. The attacker then to designated resolvers or forwarders for tailored responses
sends manipulated responses, needing to guess only 16 bits. based on its policy) to query its own domain. The attacker
Man et al. [42] (S) proposed an attack involving a Distributed then sends a spoofed response, which includes an NS record
Denial of Service (DDoS) on the authoritative server, com- that delegates a top-level domain (TLD) to the attacker’s
bined with a UDP/ICMP port scan to uncover the resolver’s authoritative server—a clear violation of the "out of bailiwick"
source port mechanism, followed by sending fake responses rule. As a result, the CDNS caches this incorrect delegation
with different TXIDs. Klein et al. [44] (S) demonstrated how to the attacker’s server.
an attacker could determine the resolver’s source port by an-
alyzing the state of the pseudo-random number generator,
3.2 Related Poisoning Prevention Systems
then only guessing the TXID to run a cache poisoning attack.
Jeitner et al. [45] (S) identified weaknesses in routers with Throughout the years, several efforts have focused on hard-
built-in DNS resolvers, including predictable ID generation ening the DNS protocol against attacks. Probably the most
and constant source ports, which attackers could exploit by famous one is DNSSEC [47], which started back in 1997.
varying TXIDs or source ports. In the Tudoor attack [19] (S), This defense allows for the cryptographic authentication of
the attacker first sends a benign query to the resolver. Subse- DNS records, thus preventing DNS cache poisoning attacks
quently, the attacker sends multiple DNS queries embedding via counterfeit packets. DANE [48–50] utilizes the structure
port numbers within the domain name to identify the correct of DNSSEC to authenticate domains using TLS certificates.
source port of the resolver. After determining the correct port, The adoption of these solutions is limited by the global imple-
the attacker only needs to guess the TXID of the original be- mentation of DNSSEC in resolvers, which is less than 30%4 .
nign query by sending multiple fake responses with different DNSCurve [51], introduced in 2009, attempted to encrypt
TXIDs. DNS traffic to prevent interception of queries and responses,
An alternative approach to DNS cache poisoning lever- but it was not widely adopted. Since then, other approaches
ages IP fragmentation to bypass the need for guessing the have tried to make DNS more resilient to privacy and secu-
Transaction ID (TXID) or source ports. Hertzberg et al. [38] rity issues [6, 52–54]. DNS over HTTPS5 (DoH) [54] allows
(BFrag ) pioneered this method by analyzing how resolvers DNS queries and responses to be sent over secure HTTPS
generate IP identification (IPID) values; by predicting the traffic and has been implemented since 2018 by services from
IPID sequence, an attacker can send a single malicious sec- Google, Amazon, and Cloudflare. Although it allows safer
ond fragment that the resolver mistakenly reassembles with transit of DNS queries, there is no transparency in how DNS
a legitimate first fragment, leading to cache poisoning. In queries are processed on the sender’s side6 . Although DOH
subsequent work, Hertzberg et al. [39] (SFrag ) introduced a can prevent attacks on the traffic between clients and resolvers,
technique involving multiple second fragments with different it does not prevent the poisoning of the resolver’s cache. Thus,
IPIDs, allowing the attacker to manipulate the resolver into DOH does not prevent the attacks examined in our work.
reassembling a legitimate first fragment with a fake second Other works have abstracted the DNS protocol to detect
fragment by increasing the chances of IPID collision. Zheng anomalous or malicious DNS traffic. One of the earliest efforts
et al. [41] (BFrag ) expanded on fragmentation attacks by in- in this direction assessed DNS cache poisoning attacks [56],
volving both a forwarder (a DNS server that forwards DNS focusing solely on Kaminsky’s attack using the probabilistic
queries to external servers for resolution) and a resolver: in model checker PRISM [57]. A similar approach was presented
their attack, the attacker sends a malicious second fragment to in [58]. The SPIN model checker [59] was utilized in another
the forwarder, which then reassembles it with a legitimate first study with finite state machine models in [60] to detect ab-
fragment before forwarding it to the resolver. Dai et al. [43] stracted (but non-specific) DNS cache poisoning attacks.
(SFrag ) demonstrated that an attacker can induce fragmenta- A DNS cache poisoning mitigation was devised by Laraba
tion using ICMP packets and then send a malicious second et al. [61] using Petri nets [62] and P4 programmable switches.
fragment directly to the resolver; when the resolver processes However, it addressed only simple DNS cache poisoning,
a legitimate query, it reassembles the response using the at- similar to Kaminsky’s attack [13].
tacker’s fragment, resulting in cache poisoning. Heftrig et Other approaches have employed machine learning algo-
al. [46] (SFrag ) described an attack targeting DNSSEC re- rithms to detect DNS attacks. For instance, Anax [63] used
sponses. By first triggering fragmentation and then sending a 4 [Link]
counterfeit DNSSEC second fragment, the attacker causes the 5 HTTPS itself may prevent users from accessing a malicious website

resolver to include the fake fragment in the reassembled re- without a valid certificate. However, as noted by Doe [55], DoH does not
sponse from the authoritative server, thus poisoning the cache offer this safeguard. Furthermore, the resolver—which is the focus of this
paper—is not secured when handling HTTPS traffic.
even in the presence of DNSSEC. 6 [Link]

The last approach was demonstrated by Li et al. [17] (SOoB ), [Link]

5
a machine learning (ML) approach based on heuristics from TXID, within a small window of time. When this number
300,000 servers around the world to detect cache poisoning crosses a threshold (a system parameter, e.g., 5) for the
attacks. More details can be found in [64]. same DNS query, we flag these responses as a potential
All the above-mentioned works analyzed the attacks poisoning attack and pass them to the mitigation module.
through heuristics, patterns, and machine-learning ideas to
tackle different DNS cache poisoning attacks. However, no 2. Fragmentation (Rℓ2): The second dominant behavior
solution tried to cover all DNS cache poisoning attacks at of DNS cache poisoning is sending fake second frag-
once. In the current work, we suggest such a solution with a ment packets in response to pre-requested DNS queries.
set of three simple rules and a mitigation technique. When the first fragment of a packet is obtained, it is
passed to the mitigation module. Any other fragments
are discarded to prevent fragmentation-based attacks.
4 Poisoning Attacks Detection and Mitigation
3. Out of Bailiwick (Rℓ3): We refer here to the ’out of
We present a DNS cache poisoning attack prevention system bailiwick’ case, where the domain being queried falls
consisting of two modules: rule-based detection (Section 4.1) outside the authority of the DNS server responding to
and mitigation (Section 4.2). Once the mitigation has kicked the request. Packets that meet this rule are identified as
in the module is highly accurate, with zero false positives and potential attack packets as well and are passed to the
zero false negatives, meaning it prevents all spoofed DNS mitigation module.
responses from poisoning the cache and allows those com- The last column of Table 1 summarizes the matching of an
ing from an authentic IP address (of the authoritative server) attack and a rule, based on their DNS cache poisoning attack
to be delivered as is to the resolver. Furthermore, since the type. The efficient implementation of the rules is presented in
mitigation kicks in after 5 attacker packets, the probability of Section 4.5.
successful poisoning is 5 * the probability of each of the five
packets guessing correctly both the port and TXID. This is
equal to 0.00152%. For efficiency, mitigation is applied selec- 4.2 Mitigation Module
tively to responses flagged as suspicious by the detection mod- When a response is suspected of being a poisoning its content
ule. Although the detection module may occasionally err in is being erased and the corresponding query/response con-
the false positive direction, overall it does not result in block- versation is moved from DNS over UDP to DNS over TCP,
ing a legitimate response since these flagged responses are by setting the TC flag to true on the response that is being
passed to the mitigation module, which ultimately blocks only forwarded to the target resolver. This way the resolver has a
the actual spoofed responses. This property allows us to min- higher guarantee that it communicates with an authentic IP
imize the false negatives of the detection module and reach address due to the three-way handshake of TCP, thus miti-
a close-to-perfect recall rate. After describing the two mod- gating poisoning that does not come from the intended name
ules, we delve into the algorithmic approach of the detection server itself. The TC flag [65] was originally designed to
module and present our complete mitigation system, DNS- indicate that a packet was truncated due to the packet’s length
CPM (Section 4.3-4.5). Finally, we discuss the metrics used (i.e., the packet is larger than the maximum transmission unit
to evaluate our system (Section 4.6). (MTU)) and thus should be discarded by the resolver, and be
requested again over TCP. While previous works [32, 33, 66]
4.1 Detection Module used the TC flag to defend from various attacks, to the best of
our knowledge, it has not yet been systematically applied to
According to Table 1, the type of 60% of the DNS attacks mitigate DNS cache poisoning attacks. The TC flag was used
examined in our work involves guessing either the TXID randomly for clients suspected of being hijacked [66] or to
or source ports (type S), 216 possibilities for each. An addi- mitigate spoofed DNS DDoS attacks [32, 33]. In contrast, the
tional 28% use the second fragment as an attack vector (type TC bit is used here to systematically protect resolvers from
SFrag /BFrag ). The two exceptions, are Schuba et al. and Li et DNS cache poisoning attacks.
al.; the Li et al. attack exploits incorrect Bailiwick rule en- Practically, when a suspicious response is identified, its
forcement (type SOoB ), while the Schuba et al. attack, though TC flag is set to true (TC=1). Additionally, all data of the
listed, is outdated and not feasible today. answer, authoritative (auth), and additional (add) parts of the
Based on this trend, we devised three rules, each designed answer are removed from the response7 . A recent measure-
to detect a different type of potential DNS cache poisoning ment of DNS resolvers by APNIC Labs [68] used ad-based
attack:
7 In the case of Rℓ2, the fragment contains partial information. Since only

the first fragment is sent to the mitigation module, we can derive the required
1. Excessive Guessing of TXID/Port (Rℓ1): We monitor field values from the question section within this fragment to generate the
the number of DNS response packets that differ from truncated response (e.g., qname, TXID, etc.). To the best of our knowledge,
each other only in one common field—the port or the there is no documentation in the official RFCs [65, 67] specifying which

6
measurement techniques to investigate the use of informa- To address this, we review solutions presented in previ-
tion from truncated packets. By examining the queries of ous works. An interesting algorithmic approach was used
approximately 394 million users around the world (primarily by Afek et al. [71] and Nadler et al. [72] to identify anoma-
querying their default ISP’s resolvers, with estimated hun- lous behavior in networks using Heavy Hitters. Specifically,
dreds of thousands of unique resolvers), APNIC found that Afek et al. [71] used it for DNS DDOS attack detection, and
0.05% of these queries used information from truncated pack- Nadler et al. [72] for DNS tunneling attack detection. Both
ets, even though such data should be disregarded. To mitigate works utilized the constant size memory of heavy hitters to
the use of potentially compromised data, we erase any data address large amounts of traffic. Another useful approach was
from truncated packets before forwarding the packet to the demonstrated in DNSGuard [73], an ML-based technique for
intended resolver. Additionally, APNIC observed that 2.67% mitigating DNS attacks, using Count-Min Sketch [74] (CMS).
of resolvers do not resend a TCP query to the authoritative
server after receiving a DNS response with the TC flag set Thus, we compare three different algorithms previously
to true. For comparison, Moura et al. [69] found a lower rate used for frequency estimation in DNS attacks: Count-Min
of 1.78% among resolvers in the Netherlands. An alternative Sketch (CMS), Fixed-size Distinct Weighted Sampling (dw-
mitigation option that might have addressed the issue with sHH), and Fixed-threshold Distinct Weighted Sampling (WS).
these non-cooperating resolvers could have involved setting Count-Min Sketch (CMS) is a compact data structure used
the TTL value to zero, signaling that the information in the to estimate item frequencies in a data stream. It consists of a
packet immediately expires. However, more than 8% of re- table with multiple rows, each linked to a unique hash func-
solvers ignore this explicit expiration signal by extending tion, and multiple columns representing counters. When an
the response’s TTL [70], limiting the applicability of this item arrives, it is hashed using each function, and the resulting
approach. Thus, our system is not 100% compatible with re- hash values indicate which counters to increment. The item’s
solvers that do not initiate a TCP session when receiving a frequency is estimated by taking the minimum value among
truncated packet. these counters. CMS’s memory usage depends on the desired
error rate (ε) and confidence level (1 − δ), which determine
The mitigation module may send multiple packets (attacker
the number of hash functions (depth, d) and counters per hash
packets) with the TC flag set to true to the resolver. Because
function (width, w). An illustration of CMS is presented in
the resolver validates both the TXID and the source port, most
Fig. 2.
of these packets will not match the original query and will
be discarded. The resolver will accept only the packets that Fixed-size Distinct Weighted Sampling for Heavy Hit-
match both parameters. Once a matching packet is accepted, ters (dwsHH) identifies frequently occurring items (heavy
the resolver opens TCP sessions with the authoritative NS. hitters) in a data stream using a fixed memory size. It main-
Even if the attacker matches both parameters, the transition tains a weighted sample of items based on their frequency.
to TCP ensures that the resolution process is robust against When a new item arrives, the algorithm decides whether to
cache poisoning (e.g., requiring the correct sequence number, add it to the sample, depending on its weight and the sample’s
window length). current state. The memory usage is influenced by the cache
size (k), the sampling window length (ℓ), and the logarithm
of the monitored item count (m). The sample dynamically
4.3 Rℓ1 Algorithmic Approach updates, keeping the most significant items while minimizing
memory use.
In Rℓ1, we detect a high volume of packets with identical
fields, except for the port or TXID. From Table 1, we see that Fixed-threshold Weighted Sampling (WS) identifies sig-
the typical packet count for the S type is 65,535—reflecting nificant or "heavy" items in a data stream using a fixed thresh-
all possible values for either the port or TXID8 . Therefore, old (τ). Items are sampled if their weight or frequency exceeds
in Rℓ1, a method is essential to differentiate benign DNS this threshold, which helps focus on important items without
query responses—which are usually limited to one or two tracking every item in the stream. Upon the arrival of a new
packets—from malicious cases, where thousands of responses item, its weight is compared to τ; if it exceeds the threshold,
may appear for the same query. Our objective is to develop it is added to the sample. This method optimizes memory and
an efficient, resource-light solution with a low error rate. computation by focusing on items that significantly affect
data distribution, reducing errors in frequency estimation for
fields must be extracted from the truncated packet. We assume that the DNS less significant items.
layer in the truncated packet provides the necessary information to initiate a
new TCP session with the authoritative server. The comparison of the three algorithms is based on memory
8 Historically, in attacks such as those by [13, 36, 37], the randomness of
usage, error rates, and inference time for various numbers
both TXID and port was minimal, allowing shorter exhaustive searches. More
recent attacks (e.g., [19, 45]) circumvented guessing the TXID and source
of domains (10, 100, 1000, and 10K). The full analysis can
port but still required navigating through the full range of 65,535 possible be found in Appendix A. We describe here the comparison
TXID or port guesses. compactly, in Table 2.

7
 [Link] [Link]
0 1 2
0 1 2
H1 1 0 0
H1 1 1 0

H2 0 0 1 d
H2 0 2 2
H3 1 0 0
H3 1 0 1

w CMS([Link])=1

(a) (b)

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 Hi . 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 (a). 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 (b).

Method Memory Error Inference Memory Usage Comparison

CMS w × d × ε = we O(d) 104

|counter|   Memory Usage (bytes)
1 y w 103
dwsHH O(kℓ log m) O ∑y wy + √2ℓ
k O(log N)
 
wy
WS O(τ ∑y wy · O τ−1 + √2ℓ O(τN) 102
ℓ log m)
CMS
101
Fixed-size dwsHH
Table 2: Comparison of memory usage (Memory), error rates Fixed-threshold WS
(Error), and inference time (Inference) for CMS, dwsHH, and 10 100 1000 10000
WS. Specific details are presented in Sections 4.3.1-4.3.3. Domains

Figure 3: Memory usage comparison, between CMS and

Heavy Hitters. The CMS algorithm gets high memory us-
4.3.1 Memory Usage Calculation
age but is constant. At its peak, the CMS is less memory-
1. CMS: The w and d values are fixed, and for optimum consumable than the heavy hitters.
utility (will described in Section 5), we picked d = 5, w =
200. The counter is given as an int (4 bits). The resulting
memory usage is 4k bits. 4.3.2 Error Rates Calculation

All parameters for the three algorithms are the same as in

2. dwsHH: Reasonable values used to compare are a cache the previous subsection. The comparison of error rates is
size of k = 100, a sampling window size of ℓ = 32, and presented in Fig. 4. It can be seen that the error rate of CMS
a log of monitored size m ≈ 0.1N, where N is the size (∼0.01) is less than the error rates of the heavy hitters (more
of the domains’ list. than 1 and more than 100, respectively).

3. WS: the fixed threshold τ is 0.01. Other parameters are

identical to the dwsHH. 4.3.3 Inference Time Calculation

All parameters remain consistent with those in the pre-

The comparison of memory usage is presented in Fig. 3. It vious subsections. As shown in Fig. 5, the comparison
is shown that the memory usage of CMS is high but constant, of inference times indicates that the CMS query time
and the heavy hitters’ memory usage is increasing. With a stays constant—requiring only five hash function calcula-
high number of domains (10k), the CMS utilizes less memory. tions—whereas the query time for the heavy hitters’ methods

8
 Error Rates Comparison
4.5 DNS-CPM algorithm
102
Our system’s final algorithm (full pseudo code in Appendix B)
CMS
101 Fixed-size dwsHH follows the match-action steps [75] for processing a given set
Fixed-threshold WS of DNS response packets P:
Error Rate

100
1. Get the CMS table, global counter, threshold, window
10−1
size W , an initial time t (first packet), a blank map
domainMap, and a global boolean variable action.
10−2
10 100 1000 10000
2. For each packet pi in P:
Domains

(a) If applying Rℓ1, Rℓ2, or Rℓ3 on pi matches, and pi

Figure 4: Error rates comparison, between CMS and Heavy
is not null, set the action to "truncate". Erase the
Hitters. The error rate of CMS is well under the heavy hitters,
packet’s answer/auth/add records and set the TC
in order of magnitude (∼ 0.01 vs more than 1, or more than
flag as true. Else, the action is "forward".
100).
(b) Finally, send the packet to the destination.

3. Rℓ1(Algorithm 2):
increases with the number of domains.
(a) Add the packet’s domain name to the CMS table.
Inference Time Comparison (b) Periodically, based on the counter value, check if
102
the frequency of this domain in the CMS table is
above the threshold. If so, check if this domain
Inference Time (operations)

exists in domainMap already. If so, return true.

101
Elsewhere, if it is a new domain, save the domain
in domainMap. Then, return true.
100
CMS
(c) Increment the global counter.
Fixed-size dwsHH
10−1 Fixed-threshold WS
(d) Periodically, based on the time value, check if we
10 100 1000 10000
covered the whole window W . If so, empty the
Domains CMS, zero the counter, and set t to the time of the
current packet.
Figure 5: Inference time comparison, between CMS and
Heavy Hitters. CMS’s inference time is constant at 5, where (e) Return false.
the other algorithms increase based on the number of domains. 4. Rℓ2(Algorithm 3): If the offset of the packet equals zero
and the MF flag is set to true, return true. Elsewhere, if
the offset of the packet is greater than zero, the packet is
Following the above analysis, we picked CMS for Rℓ1.
nullified. Then, return false.
Compared to the other algorithms, CMS is less memory con-
sumable with a high volume of domains, has a low error rate, 5. Rℓ3:(Algorithm 4): If the answer, authoritative, or ad-
and its reference time is constant. ditional records of pi do not comply with the Bailiwick
rule, return true. Elsewhere, return false.

4.4 Rℓ2 & Rℓ3 Algorithmic Approach 4.6 Metrics

We evaluated our system by measuring the attacker’s success
In Rℓ2, fragments are identified as potential indicators for rate (ASR), a metric used to assess the effectiveness of DNS
a DNS cache poisoning attack. Instead of storing data, we cache poisoning attempts. Given that common DNS cache
monitor the packet’s offset and the MF (More Fragments) flag. poisoning attacks typically involve sending a high volume
When the offset equals zero and the MF flag is set (indicating of packets, our goal was to determine the likelihood of an
the first fragment), fragmentation is detected. In Rℓ3, we attacker’s success. In this evaluation, we assume a 100% suc-
follow the Bailiwick rule. Any packet that does not enforce cess rate if the attacker transmits all intended packets without
this rule, is identified as suspicious. Here as well, we do not detection. However, if only a portion of the packets are sent
need to store any data for future calculation. We enforce both before detection, the success rate is scaled according to the
rules without any additional resource consumption. proportion successfully transmitted. For instance, if only 5

9
out of an intended 1000 packets are sent before detection, the second suggested by [77]. These noise packets simu-
success rate is calculated as 0.005. late a more realistic network environment where benign
We further evaluated our system’s capability to accurately traffic is sent to the resolver alongside the attacker’s pack-
distinguish between benign and malicious packets by mea- ets. Additionally, we explored different numbers of hash
suring the false positive (FP) rate, which indicates instances functions (d = 2, 3, 4, 5) and varying numbers of cells for
where benign packets are mistakenly classified as malicious. each hash function (w = 100, 200, 500), omitting lower
In cases where the system identifies a suspicious packet, it w values as they provided ineffective results.
triggers a truncated packet to the resolver to initiate a TCP
connection with the authoritative name server. This mech- 2. An experiment with an attack that mimics the 2nd frag-
anism ensures that the resolver opens a TCP connection to mentation method. This experiment tested Rℓ2.
obtain the correct resolution, which is then passed on to the
client. Only valid responses (matching a resolver’s outgoing 3. An experiment with an attack that violates the bailiwick
query) will be processed, the others will be dropped by the rule. This experiment tested Rℓ3.
resolver. As a result, each client’s query is answered reliably,
4. The last experiment utilized benign data from Mendeley
even if an attacker attempts to poison the resolver. Thus, while
Data [78], which comprises over 45 million DNS packets
false positives are analyzed, they do not actually impact the
collected over a period of 1.5 days from more than 4,000
resolution process.
users within an academic campus. This dataset, split into
multiple files by hour as described in the original study,
5 Experiments was analyzed by focusing solely on the DNS responses
received by the resolver (IP address [Link], as docu-
In this section, we present the technical aspects of DNS- mented in [78]) from servers in the DNS hierarchy. This
CPM and describe how we evaluated its performance us- focus is because responses from these servers represent
ing a simulated environment. We implemented the rules and the primary vector for potential DNS cache poisoning
their testing framework in Golang and Python. The complete attacks. After filtering, approximately 6 million packets
source code is publicly available in our GitHub repository 9 . remained. This benign dataset served to evaluate the sys-
In the simulated environment, we collected and reconstructed tem’s false positive (FP) rate, verifying that it does not
a rich set of PCAP files containing different scenarios, in- incorrectly flag benign data as malicious at an excessive
cluding interleaved attack and benign packets, and legitimate rate.
DNS traffic to assess DNS-CPM’s performance metrics. This
approach allowed us to test various configurations and condi- In all our experiments, we set the parameters to τ=5 packets,
tions in a controlled and reproducible manner. All simulations N=1 packet, and a window W =1 second. These threshold
were executed on a desktop machine with an 11th Gen Intel® and frequency-checking settings provide sufficient overhead
Core™ i7-1185G7 @ 3.00GHz processor and 32 GB of RAM. for normal DNS traffic, typically involving 1–2 responses
Using this setup, we conducted four distinct experiments to per query. The one-second window accommodates the most
evaluate different facets of DNS-CPM: proficient attack reported by Li et al. [19] (approximately 400
ms) and simplifies the noise addition calculation. Therefore,
1. An experiment that mimics an extensive set of pack- we selected a one-second window for our experiments.
ets for testing Rℓ1. To match the dominant attacks of
the S model (as past attacks [13, 36, 37] have low suc- 0.4
cess rates with today’s defense settings), we generated
a single query from the attacker to the resolver, 65,535 0.2
FP

responses for this query with a different TXID, and an

authentic response from the authoritative server. Fol- 0
lowing the attack rate of approximately 400 ms as used 2 3 4 5
in [19], we timed the generation of the attack packets ac- d(#hashes)
cordingly, aiming to send all guesses quickly enough
to beat the correct response. To test whether DNS- Figure 6: FP as a Function of d Value - Interleaved Attack
CPM can identify attacks in the presence of benign & Benign Data. Different d values for CMS, and their FP rate
traffic, we added 1,000 randomly generated noise pack- for w values. The attacker got a constant 0.0076% success rate
ets—simulating valid response packets for other domains (5 packets), thus, it is not explicitly graphed. For FP rates, with
queried by other clients, with domains taken from the w = 100, the FP rate goes from 40% with 2 hash functions
Tranco list [76]—following the number of queries per (d = 2), to 25% with 5 hash functions (d = 5). With w = 200
9 [Link]
and d = 5, the FP rate is below 1%. For w = 500, it is 0%.
EE50

10
 W = 100 W = 200 W = 500 of the number of hash functions used. As discussed in Sec-
tion 6.1, this FP rate is innocuous, as the resolver successfully
Figure 7: Mutual Legend for Figures 6 and 8. retrieves the result via TCP and forwards the response to the
client.
0.01
77 In summary, the experiments demonstrated that DNS-
CPM provides precise analysis of benign traffic and DNS
FP

765
cache poisoning attacks. Using a configuration of w = 200
0.01
and d = 5, we achieved an ASR of 0.0076% and an FP rate
of 2% on clean data, and 1% on interleaved benign and ma-
76
0.01 2 3 4 5
d(#hashes)
licious traffic. To get a 0% FP, w = 500 and d = 2 can be
utilized.
Figure 8: FP as a Function of the d Value - Benign Data.
Different d values for CMS, and their FP rate for w values. It
is shown that the largest FP rates are less than 2%, decreasing 7 DNS-CPM as a Proactive CVE Mitigation
to 0% with 5 hash functions (d = 5).
In this section, we present 14 CVEs related to targeted DNS
software that DNS-CPM prevents from being exploited. Em-
6 Results ploying DNS-CPM reduces the necessity of fixing resolvers
that use vulnerable DNS software mentioned in these CVEs.
In this section, we present the results of DNS-CPM. We compiled the list of CVEs from NIST [79] by searching
for "DNS cache poisoning" [80] and "DNS spoofing" [81].
We filtered out CVEs relating to DNS clients, as we did with
6.1 Rℓ1 Experiments logic DNS cache poisoning. We also omitted cases where
Figure 6 shows the FP rates of the attack, which exceed 20% the CVE mentions DNS cache poisoning/DNS spoofing as
for a window size of w = 100. For w = 200, the FP rate is a tool for another attack without explicitly explaining how
6% with two hash functions (d = 2), decreasing to less than this attack is implemented (e.g., attacks on weak TLS/SSL
1% with five hash functions (d = 5); for w = 500, the FP certificates [82]). Additionally, we discarded CVEs related
rate is 0%. Across all experiments, the attack success rate to DNSSEC, as its utilization is out of the scope of this work
(ASR) was 0.0076% and thus was not visualized. This low due to poor distribution and reliance on authoritative servers.
ASR was since after τ = 5 packets, all subsequent packets We manually explored the given information and mapped
with the same malicious domain within a one-second window which type of attack can exploit this CVE (based on the
were identified as malicious. Note that when a suspicious types in Section 2.1). Through this mapping, we demonstrate
packet is identified by DNS-CPM, a truncated packet is sent that DNS-CPM mitigates all reported vulnerabilities associ-
to the resolver, prompting it to open a TCP connection to the ated with the following CVEs, as it has previously addressed
authoritative server. Only valid packets (based on the TXID the corresponding types of attacks. We also described the
and port) will be processed. Thus, although we document an vendor affected by each CVE. Then, we documented the rule
FP rate, there is no actual loss for benign requests wrongly of DNS-CPM that captures this CVE. Following is a brief
identified as malicious; instead, the resolver obtains the result description of each CVE:
via TCP and transfers the response to the client.
1. CVE-2023-30464 [83] is a recent CVE affecting
CoreDNS, a Golang-based DNS server library. The ex-
6.2 Rℓ2 & Rℓ3 Experiments ploitation involves sending multiple attacks with varying
TXID and source port values, leveraging the recent Tu-
DNS-CPM detects the fragmentation and out-of-bailiwick door attack [19]. This exploit is thus classified as an S
attacks, respectively. As each rule targets a single packet (Rℓ2 attack, similar to Tudoor.
on the first fragment, and Rℓ3 on the out-of-bailiwick packet),
the system found this packet instantly. 2. CVE-2023-28457 [84] was also discovered through the
Tudoor attack. In this case, vulnerabilities were found in
6.3 Begin Data Experiment Technitium DNS and Microsoft DNS, susceptible to sim-
ilar exploitation as CVE-2023-30464. This vulnerability
We analyzed the FP rate of DNS-CPM on clean, benign data is similarly classified as an S attack.
(i.e., without any attacks). Figure 8 illustrates the trends in
these FP rates. As observed, for w = 100, the FP rate on be- 3. CVE-2023-28457 [85] reveals a vulnerability in Techni-
nign data is approximately 2% across various values of d. tium DNS that allows injection of NS records, even at
However, when d = 500, the FP rate drops to 0% regardless the TLD level, due to improper validation of the baili-

11
 wick rule. This CVE is exploited through a BOOB attack, CVE Type Vendor DNS-CPM
as it involves a packet that violates the bailiwick rule.
CVE-2023-30464 [83] S CoreDNS Rℓ1
4. CVE-2021-3448 [86] discloses a vulnerability in dns- CVE-2023-28457 [84] S Microsoft Rℓ1
masq, enabling an attacker on the network to exploit a DNS, Techni-
fixed port used in query forwarding, facilitating DNS tium
cache poisoning by guessing random TXIDs. This CVE CVE-2021-43105 [85] BOOB Technitium Rℓ3
aligns with an S attack due to the guessing of TXIDs. CVE-2021-3448 [86] S dnsmasq Rℓ1
5. CVE-2020-25684 [87, 88] identifies an anomaly in dns- CVE-2020-25684 [87, 88] S dnsmasq,Cisco, Rℓ1
masq, where multiple unanswered queries are forwarded OpenWRT
to an upstream server using only 64 random source ports. CVE-2017-12132 [89] SFrag - Rℓ2
With multiple TXIDs sharing a port, the effective en- CVE-2008-3217 [90] S PowerDNS Rℓ1
tropy is reduced to 26 bits, enabling attackers to guess CVE-2008-1447 [91] S BIND, Mi- Rℓ1
the TXID-port combination through brute force, as seen crosoft DNS
in S attacks. Cisco VPN routers and OpenWRT firmware CVE-2008-1454 [92] BOOB Microsoft Rℓ3
were among the affected platforms. DNS
CVE-2008-1146 [93] S OpenBSD’s Rℓ1
6. CVE-2017-12132 [89] reveals a vulnerability in the BIND
DNS resolver within the glibc library. Exploitation uses CVE-2007-2926 [94] S ISC BIND Rℓ1
large UDP responses, leading to fragmentation, and is CVE-2002-2211 [95] S BIND Rℓ1
categorized as an SFrag attack. CVE-2002-2212 [96] S Fujitsu Rℓ1
7. CVE-2008-3217 [90] describes a flaw in source port ran- UXP/V
domization in PowerDNS, enabling TXID brute-force CVE-2002-2213 [97] S Infoblox DNS Rℓ1
attacks. This CVE is thus mapped to an S attack.
Table 3: CVEs fixed by DNS-CPM. For each CVE, we
8. CVE-2008-1447 [91] highlights vulnerabilities in the describe the attack type used to exploit it based on its descrip-
random generation of source ports and TXIDs in BIND tion, document the vendors affected by the vulnerability, and
and Microsoft DNS, classifying it as an S attack. list the corresponding rule of DNS-CPM that matches the
9. CVE-2008-1454 [92] documents a vulnerability in Mi- CVE.
crosoft DNS that allows the resolver to retrieve records
outside of the delegated authoritative domain. This vul-
8 Comparison to Other Tools
nerability is exploited via an outside-of-bailiwick rule
attack, categorized as BOOB . In this section we compare DNS-CPM to other IDS/IPS
10. CVE-2008-1146 [93] describes Klein’s attack [37] on tools, Suricata and Snort. Suricata [98] is an open-source
OpenBSD’s BIND, involving guessing 10 TXIDs for a IDS/IPS and NSM engine that uses multi-threading and
single query, thus making it an S attack. signature-based detection to monitor network activity. We
compare DNS-CPM to Suricata’s DNS rules [99, 100] from
11. CVE-2007-2926 [94] identifies a weak random number the OpenWRT ruleset, as the free version available on the Suri-
generator for TXIDs, which is susceptible to brute-force cata website [98] currently lacks these rules. All following
S attacks. Suricata rules are found to be related to DNS cache poisoning:
12. CVE-2002-2211 [95] documents a vulnerability in 1. SID:2008446 At least 100 DNS responses in 10 seconds.
BIND where attackers can send multiple queries for The responses are aggregated by only source IP. The rule
a single resource record, along with spoofed responses. also makes sure that there is at least one record in the
The attack involves sending multiple responses per query, authority part.
fitting the S attack classification.
2. SID:2008447,2008475 Kaminsky attack identification.
13. CVE-2002-2212 [96] reports the same vulnerability as These rules match sequences of A/NS responses of at
CVE-2002-2211, but for Fujitsu UXP/V. least 50 responses in 2 seconds per source IP.
14. CVE-2002-2213 [97] reports the same vulnerability as 3. SID:2013894 A tailored rule of attack on Google
CVE-2002-2211, affecting Infoblox DNS. Brazil’s domain ([Link]). This rule looks for a
Table 3 illustrates the CVEs. Similar to the case of the logic set of 100 responses in 10 seconds from the same source
DNS cache poisoning attack, rule Rℓ1 matches the majority IP. Each response should contain one record at least in
of CVEs (78%), followed by Rℓ3 (14%) and Rℓ2 (7%). the answer section and in the authority section.

12
 4. SID:2100253,2100254 Low TTL response. These rules 9 Discussion
look for responses with no authority section. The first
rule specifically looks for PTR response. Our new system, DNS-CPM, assumes that an attacker fol-
lows one of three methods—extensive traffic per one query
The last two Suricata rules were not compared to our sys- searching for port/TXID, fragmentation, or "out of bailiwick".
tem. Rules 2013894, 2100253, and 2100254 did not provide In the past, a study by Klein et al. [44] presented an attack that
sufficient packet details to enable a direct comparison with assumed the attacker knows the port or TXID from an external
our system. It’s important to note that the aggregation of Suri- source (beyond the DNS protocol itself). Based on this past
cata’s rules is based on IP addresses, while Rℓ1 performs work, an attacker can adopt a new method: first, the attacker
aggregation based on subdomains, with a timing threshold of identifies the source port the resolver uses through unspecified
1 second (compared to Suricata’s 2 seconds). techniques. Then, for multiple distinct queries, the attacker
sends a single fake response for each, in a packet that adds an
Snort [101, 102] is an open-source IDS/IPS, now main-
authority record and an additional record inside the bailiwick.
tained by Cisco, that uses a signature-based approach to detect
This way, the attacker evades our rules. By targeting hours
and respond to network threats. To compare with DNS-CPM,
with low traffic to the DNS resolver, the attacker can achieve
we identified Snort rules targeting DNS cache poisoning at-
a high Attack Success Rate (ASR). The attacker can also
tacks, which can be found by searching "DNS cache" on the
use other templates [103] as well as traditional NS/additional
Snort website and examining the "[Link]"
records.
file from the latest subscribed ruleset. Some of the rules were
Indeed, this attack does not trigger our rules. However, we
not detailed, and others were disabled by Snort, so they cannot
conducted an assessment of Tranco’s top 1000 domains [76]
be compared to DNS-CPM. Therefore, we describe four still-
using simple DNS queries and analyzed the distribution of
running rules with explicit details of DNS cache poisoning
response types, categorizing them as follows: 46% of the
attacks:
responses included only answer records, 26% included both
answer and authority records, 22% had no answer records
1. SID 2008446: This rule is triggered when the DNS re- (but had additional or authority records), and 6% featured
sponse packet contains more than zero resource records answer, authority, and additional records. This preliminary
(RRs) in both the answer section and the additional sec- assessment indicates that DNS responses exhibit a typical
tion, with over 100 such packets observed from the same statistical distribution that can be monitored, and while an
source IP within 10 seconds. attacker could potentially exploit this statistical behavior, the
method would require strict adherence to these patterns. A
2. SID 2008447: This rule indicates a DNS response indi- more in-depth analysis would be necessary to establish an
cating 3 RRs. The rule is triggered if there are more than additional statistical rule for inclusion in DNS-CPM, and
50 such packets from the same source within 2 seconds. this is left for future work.

3. SID 2008475: This rule indicates 3 A RRs. It is triggered

if more than 50 packets are observed from the same 10 Conclusion
source within 2 seconds. The rule aims to detect potential
In this study, we introduced DNS-CPM, a system designed to
A RR cache poisoning attempts.
protect resolvers against various DNS cache poisoning attacks
and mitigate exploits stemming from CVEs. We demonstrated
4. SID 2008446: The same as Suricata’s SID:2013894 rule. that DNS-CPM is more effective for this task compared
to Suricata and Snort. Its retrospective capability captures
The last rule was not compared, similar to the equivalent known DNS cache poisoning attacks and provides a founda-
Suricata rule. Also, the aggregation of Snort’s is similar to tion for mitigating future threats, similar to Akamai’s recent
Suricata’s, which is less effective than our system. announcement [21]. For instance, an attack that leverages a
In summary, we found that both Suricata and Snort pro- combination of fake second fragments and packets scanning
vide rules that somewhat resemble our Rℓ1 rule; however, source ports (2013B + 2021A) to maximize impact can be
they aggregate packets based on IP addresses, while our ap- effectively detected through the combination of Rℓ1 and Rℓ2.
proach aggregates based on subdomain names. By focusing Our simulation of real-world data further validated the sys-
on specific subdomains, our method captures attacks more tem’s performance by assessing the rate of false positives
efficiently. Furthermore, their rules trigger after a minimum generated, thus proving DNS-CPM’s applicability in practi-
of 2 seconds and 50 packets, whereas our tool operates with a cal scenarios.
1-second threshold and just 5 packets, enabling faster detec- We acknowledge several limitations of our work. First,
tion. Additionally, their rules do not account for fragmentation while our analysis focuses on DNS cache poisoning attacks,
attacks, which our tool is designed to capture. it does not immediately scale to other types of DNS attacks,

13
such as DDoS. Second, our system cannot identify attacks that [2] P. V. Mockapetris, “Rfc1035: Domain names-
involve BGP hijacking or other network protocols combined implementation and specification,” 1987.
with DNS cache poisoning. Additionally, attacks that bypass
the need to guess both the port and TXID and fall below the [3] S. Rose and W. Wijngaards, “Dname redirection in the
detection threshold will evade our system. These limitations DNS,” tech. rep., 2012.
present opportunities for future research and potential exten- [4] M. Andrews, “Negative caching of DNS queries (DNS
sions of DNS-CPM. NCACHE),” tech. rep., 1998.
[5] R. Arends, R. Austein, M. Larson, D. Massey, and
11 Ethics considerations S. Rose, “Protocol modifications for the DNS secu-
rity extensions,” tech. rep., 2005.
We evaluated DNS-CPM for false positives (FP) on real data
obtained from a published dataset on the Internet [78]. We [6] S. Bortzmeyer, “DNS query name minimisation to im-
carefully considered the ethical implications of our analysis prove privacy,” tech. rep., 2016.
and ensured that user privacy was protected. To prevent any
harm from using user data in DNS queries, we only retained [7] S. Y. Chau, O. Chowdhury, V. Gonsalves, H. Ge,
the responses received by the resolver from DNS authoritative W. Yang, S. Fahmy, and N. Li, “Adaptive deterrence of
servers, discarding the rest of the data. As a result, no IP ad- DNS cache poisoning,” in Security and Privacy in Com-
dresses or personally identifiable information (PII) from users munication Networks: 14th International Conference,
were used at any stage of the research. All the experiments SecureComm 2018, Singapore, Singapore, August 8-
of DNS-CPM were conducted in a controlled laboratory 10, 2018, Proceedings, Part II, pp. 171–191, Springer,
environment, with dedicated server. 2018.
[8] ROAR Media, “What the .lk domain registry hack
12 Open Science means for the future of cybersecurity in sri lanka,”
2021.
We fully comply with the USENIX Security 2025 Open Sci-
ence Policy by openly sharing the research artifacts associated [9] Securelist, “Massive DNS poisoning attacks in brazil,”
with this work. A comprehensive Git repository containing 2011.
all code, PCAP files, and results is available as an anonymous [10] S. Cherry, “Panix attack,” 2005.
Github repository10 . This repository ensures the reproducibil-
ity and replicability of our findings. The full repository will [11] D. Kaminsky, “Dns critical infrastructure.” Presenta-
be made permanently available after the paper’s acceptance, tion at Black Hat DC 2009, 2009.
with no licensing restrictions preventing its dissemination.
All artifacts will also be submitted to the Artifact Evaluation [12] C. Schuba and E. H. Spafford, “Addressing weaknesses
Committee for review prior to the final submission deadline. in the domain name system protocol,” Master’s thesis,
Purdue University, 1993.

13 Acknoledgements [13] D. Kaminsky, “Black ops 2008: It’s the end of the
cache as we know it,” Black Hat USA, vol. 2, 2008.
We would like to thank Prof. Amit Klein (The Hebrew Univer-
sity) and Prof. Haya Shulman (Goethe-Universität Frankfurt) [14] R. Morillo, J. Furuness, C. Morris, J. Breslin,
for fruitful discussions. Additionally, we are grateful to Prof. A. Herzberg, and B. Wang, “Rov++: Improved deploy-
Micah Sherr (Georgetown University) for providing a sup- able defense against bgp hijacking.,” in NDSS, 2021.
portive environment and the necessary equipment for this [15] M. Conti, N. Dragoni, and V. Lesyk, “A survey of man
research. This work was supported in part by an ISF Grant in the middle attacks,” IEEE communications surveys
number 1527/23, and a grant from the Blavatnik Interdisci- & tutorials, vol. 18, no. 3, pp. 2027–2051, 2016.
plinary Cyber Research Center (ICRC), Tel Aviv University,
and the Blavatnik family fund. [16] H. Berger, A. Z. Dvir, and M. Geva, “A wrinkle in time:
a case study in DNS poisoning,” International Journal
of Information Security, vol. 20, pp. 313–329, 2021.
References
[17] X. Li, C. Lu, B. Liu, Q. Zhang, Z. Li, H. Duan, and
[1] P. Mockapetris, “Domain names-concepts and facili- Q. Li, “The maginot line: Attacking the boundary of
ties,” tech. rep., 1987. {DNS} caching protection,” in 32nd USENIX Secu-
10 [Link] rity Symposium (USENIX Security 23), pp. 3153–3170,
EE50 2023.

14
[18] A. Herzberg and H. Shulman, “Security of patched [29] H. Birge-Lee, Y. Sun, A. Edmundson, J. Rexford,
DNS,” in Computer Security–ESORICS 2012: 17th Eu- and P. Mittal, “Bamboozling certificate authorities
ropean Symposium on Research in Computer Security, with {BGP},” in 27th USENIX Security Symposium
Pisa, Italy, September 10-12, 2012. Proceedings 17, (USENIX Security 18), pp. 833–849, 2018.
pp. 271–288, Springer, 2012.
[30] F. Alharbi, J. Chang, Y. Zhou, F. Qian, Z. Qian, and
[19] X. Li, W. Xu, B. Liu, M. Zhang, Z. Li, J. Zhang, N. Abu-Ghazaleh, “Collaborative client-side DNS
D. Chang, X. Zheng, C. Wang, J. Chen, et al., “Tu- cache poisoning attack,” in IEEE INFOCOM 2019-
door attack: Systematically exploring and exploiting IEEE Conference on Computer Communications,
logic vulnerabilities in DNS response pre-processing pp. 1153–1161, IEEE, 2019.
with malformed packets,” in 2024 IEEE Symposium on
Security and Privacy (SP), pp. 46–46, IEEE Computer [31] T. Ma, C. Xu, Z. Zhou, X. Kuang, L. Zhong, and L. A.
Society, 2023. Grieco, “Intelligent-driven adapting defense against
the client-side DNS cache poisoning in the cloud,” in
[20] P. Jeitner and H. Shulman, “Injection attacks reloaded: GLOBECOM 2020-2020 IEEE Global Communica-
Tunnelling malicious payloads over {DNS},” in 30th tions Conference, pp. 1–6, IEEE, 2020.
USENIX Security Symposium (USENIX Security 21),
pp. 3165–3182, 2021. [32] G. Pazi, D. Touitou, A. Golan, and Y. Afek, “Protecting
against spoofed DNS messages,” June 14 2005. US
[21] J. S. Bruce Van Nice, Mark Dokter, “Keytrap high- Patent 6,907,525.
lights the need for enduring DNS defenses for service
[33] Y. Afek, A. Bremler-Barr, and L. Shafir, “Network anti-
providers,” 2024. Accessed: 2024-08-30.
spoofing with SDN data plane,” in IEEE INFOCOM
[22] Y. Afek, A. Bremler-Barr, S. Danino, and Y. Shavitt, “A 2017-IEEE conference on computer communications,
flushing attack on the {DNS} cache,” in 33rd USENIX pp. 1–9, IEEE, 2017.
Security Symposium (USENIX Security 24), pp. 2299–
[34] MITRE, “Cwe-89: Improper neutralization of special
2314, 2024.
elements used in an sql command (’sql injection’),”
[23] P. Flajolet, D. Gardy, and L. Thimonier, “Birthday 2006.
paradox, coupon collectors, caching algorithms and [35] K. Elshazly, Y. Fouad, M. Saleh, and A. Sewisy, “A
self-organizing search,” Discrete Applied Mathematics, survey of sql injection attack detection and prevention,”
vol. 39, no. 3, pp. 207–229, 1992. Journal of Computer and Communications, vol. 2014,
2014.
[24] “Frag-dns.” [Link]
event/42/contributions/909/attachments/ [36] V. Sacramento, “Vulnerability in the sending requests
866/1568/[Link], 2022. Pre- control of bind versions 4 and 8 allows DNS spoofing,”
sentation at DNS-OARC 2022, accessed: 2025-01-19. 2002.
[25] D. Dagon, M. Antonakakis, P. Vixie, T. Jinmei, and [37] A. Klein, “Bind 9 DNS cache poisoning,” Report,
W. Lee, “Increased DNS forgery resistance through Trusteer, Ltd, vol. 3, 2007.
0x20-bit encoding: security via leet queries,” in Pro-
ceedings of the 15th ACM conference on Computer [38] A. Herzberg and H. Shulman, “Fragmentation consid-
and communications security, pp. 211–222, 2008. ered poisonous, or: One-domain-to-rule-them-all. org,”
in 2013 IEEE Conference on Communications and
[26] Sophos News, “Serious security: How deliberate typos Network Security (CNS), pp. 224–232, IEEE, 2013.
might improve dns security,” January 2023.
[39] A. Herzberg and H. Shulman, “Vulnerable delegation
[27] T. Dai, P. Jeitner, H. Shulman, and M. Waidner, “From of DNS resolution,” in Computer Security–ESORICS
ip to transport and beyond: cross-layer attacks against 2013: 18th European Symposium on Research in Com-
applications,” in Proceedings of the 2021 ACM SIG- puter Security, Egham, UK, September 9-13, 2013. Pro-
COMM 2021 Conference, pp. 836–849, 2021. ceedings 18, pp. 219–236, Springer, 2013.

[28] H. Ballani, P. Francis, and X. Zhang, “A study of pre- [40] A. Herzberg and H. Shulman, “Socket overloading for
fix hijacking and interception in the internet,” ACM fun and cache-poisoning,” in Proceedings of the 29th
SIGCOMM Computer Communication Review, vol. 37, Annual Computer Security Applications Conference,
no. 4, pp. 265–276, 2007. pp. 189–198, 2013.

15
[41] X. Zheng, C. Lu, J. Peng, Q. Yang, D. Zhou, B. Liu, [53] T. Reddy, D. Wing, and P. Patil, “DNS over datagram
K. Man, S. Hao, H. Duan, and Z. Qian, “Poison over transport layer security (dtls),” tech. rep., 2017.
troubled forwarders: A cache poisoning attack target-
ing {DNS} forwarding devices,” in 29th USENIX Se- [54] P. Hoffman and P. McManus, “DNS queries over
curity Symposium (USENIX Security 20), pp. 577–593, HTTPS (DoH),” tech. rep., 2018.
2020. [55] E. Blidborg, Cache Poisoning in DNS over HTTPS
clients. PhD thesis, KTH, Stockholm, Sweden, 2020.
[42] K. Man, Z. Qian, Z. Wang, X. Zheng, Y. Huang, and
H. Duan, “DNS cache poisoning attack reloaded: Revo- [56] N. Alexiou, S. Basagiannis, P. Katsaros, T. Dashpande,
lutions with side channels,” in Proceedings of the 2020 and S. A. Smolka, “Formal analysis of the kaminsky
ACM SIGSAC Conference on Computer and Commu- DNS cache-poisoning attack using probabilistic model
nications Security, pp. 1337–1350, 2020. checking,” in 2010 IEEE 12th International Sympo-
sium on High Assurance Systems Engineering, pp. 94–
[43] T. Dai, H. Shulman, and M. Waidner, “DNS-over-TCP
103, IEEE, 2010.
considered vulnerable,” in Proceedings of the Applied
Networking Research Workshop, pp. 76–81, 2021. [57] M. Kwiatkowska, G. Norman, and D. Parker, “Prism:
Probabilistic symbolic model checker,” in Interna-
[44] A. Klein, “Cross layer attacks and how to use them (for tional Conference on Modelling Techniques and Tools
DNS cache poisoning, device tracking and more),” in for Computer Performance Evaluation, pp. 200–204,
2021 IEEE Symposium on Security and Privacy (SP), Springer, 2002.
pp. 1179–1196, IEEE, 2021.
[58] T. S. Deshpande, Formal Analysis of DNS Attacks
[45] P. Jeitner, H. Shulman, L. Teichmann, and M. Waidner, and Their Countermeasures Using Probabilistic Model
“{XDRI} attacks-and-how to enhance resilience of res- Checking. PhD thesis, State University of New York at
idential routers,” in 31st USENIX Security Symposium Stony Brook, 2013.
(USENIX Security 22), pp. 4473–4490, 2022.
[59] G. J. Holzmann, “The model checker spin,” IEEE
[46] E. Heftrig, H. Shulman, and M. Waidner, “Poster: Off- Transactions on software engineering, vol. 23, no. 5,
path DNSSEC downgrade attacks,” in Proceedings of pp. 279–295, 1997.
the ACM SIGCOMM 2023 Conference, pp. 1120–1122,
2023. [60] W. Zhanga, M. Yanga, X. Zhanga, and H. Shia, “Model
checking the DNS under DNS cache-poisoning attacks
[47] R. Arends, R. Austein, M. Larson, D. Massey, and using spin,” SCIENCEASIA, vol. 42, pp. 49–55, 2016.
S. Rose, “DNS security introduction and requirements,”
tech. rep., 2005. [61] A. Laraba, J. François, I. Chrisment, S. R. Chowdhury,
and R. Boutaba, “Detecting multi-step attacks: A mod-
[48] R. Barnes, “Use cases and requirements for DNS-based ular approach for programmable data plane,” in NOMS
authentication of named entities (dane),” tech. rep., 2022-2022 IEEE/IFIP Network Operations and Man-
2011. agement Symposium, pp. 1–9, IEEE, 2022.

[49] O. Gudmundsson, “Adding acronyms to simplify con- [62] J. L. Peterson, “Petri nets,” ACM Computing Surveys
versations about DNS-based authentication of named (CSUR), vol. 9, no. 3, pp. 223–252, 1977.
entities (dane),” tech. rep., 2014.
[63] M. Antonakakis, D. Dagon, X. Luo, R. Perdisci,
[50] L. Zhu, D. Wessels, A. Mankin, and J. Heidemann, W. Lee, and J. Bellmor, “A centralized monitoring in-
“Measuring dane tlsa deployment,” in Traffic Monitor- frastructure for improving DNS security,” in Recent Ad-
ing and Analysis: 7th International Workshop, TMA vances in Intrusion Detection: 13th International Sym-
2015, Barcelona, Spain, April 21-24, 2015. Proceed- posium, RAID 2010, Ottawa, Ontario, Canada, Septem-
ings 7, pp. 219–232, Springer, 2015. ber 15-17, 2010. Proceedings 13, pp. 18–37, Springer,
2010.
[51] M. Dempsky, “DNScurve: Link-level security for
the domain name system,” Work in Progress, draft- [64] Y. Jin, M. Tomoishi, and S. Matsuura, “A detection
dempsky-dnscurve-01, 2010. method against DNS cache poisoning attacks using
machine learning techniques: Work in progress,” in
[52] Z. Hu, L. Zhu, J. Heidemann, A. Mankin, D. Wessels, 2019 IEEE 18th International Symposium on Network
and P. Hoffman, “Specification for DNS over transport Computing and Applications (NCA), pp. 1–3, IEEE,
layer security (tls),” tech. rep., 2016. 2019.

16
[65] P. Mockapetris, “Domain Names - Implementation and DNS queries-and-responses,” in 2024 IEEE Sympo-
Specification.” Request for Comments (RFC), Novem- sium on Security and Privacy (SP), pp. 253–253, IEEE
ber 1987. Obsoleted by RFC 2181, RFC 4033, RFC Computer Society, 2024.
4034, RFC 4035, RFC 3597, RFC 1123.
[78] M. Singh, M. Singh, and S. Kaur, “10 Days DNS Net-
[66] P. Vixie and V. Schryver, “DNS response rate limiting work Traffic from April-May, 2016,” 2019.
(DNS RRL), 2012.”
[79] “National Institute of Standards and Technology.”
[67] P. Vixie, O. Gudmundsson, M. Majkowski, and [Link] Accessed: September 29,
E. Lewis, “Extension Mechanisms for DNS 2024.
(EDNS(0)).” RFC 6891, 2013.
[80] “Vulnerability search results for DNS cache poisoning.”
[68] APNIC, “Revisiting DNS and UDP trunca- [Link]
tion.” [Link] isCpeNameSearch=false&query=dns+cache+
revisiting-dns-and-udp-truncation/, July poisoning&results_type=overview&form_type=
2024. Accessed: 2024-08-27. Basic&search_type=all&startIndex=0, 2024.
Accessed: 2024-09-29.
[69] G. C. Moura, M. Müller, M. Davids, M. Wullink, and
C. Hesselman, “Fragmentation, truncation, and time- [81] “Vulnerability search results for DNS spoofing.”
outs: are large dns messages falling to bits?,” in Pas- [Link]
sive and Active Measurement: 22nd International Con- isCpeNameSearch=false&query=dns+spoofing&
ference, PAM 2021, Virtual Event, March 29–April 1, results_type=overview&form_type=Basic&
2021, Proceedings 22, pp. 460–477, Springer, 2021. search_type=all&startIndex=0, 2024. Accessed:
2024-09-29.
[70] P. Bhowmick, M. I. Ashiq, C. Deccio, and T. Chung,
“Ttl violation of DNS resolvers in the wild,” in Inter- [82] National Vulnerability Database, “CVE-2008-3280,”
national Conference on Passive and Active Network 2008. Accessed: 2024-09-29.
Measurement, pp. 550–563, Springer, 2023.
[83] “CVE-2023-30464: Apache airflow XSS vulner-
[71] Y. Afek, A. Bremler-Barr, E. Cohen, S. L. Feibish, ability.” [Link]
and M. Shagam, “Efficient distinct heavy hitters CVE-2023-30464, 2023.
for DNS ddos attack detection,” arXiv preprint
arXiv:1612.02636, 2016. [84] “CVE-2023-28457: Docker CLI vulnerability.” https:
//[Link]/vuln/detail/CVE-2023-28457,
[72] Y. Ozery, A. Nadler, and A. Shabtai, “Information-
2023.
based heavy hitters for real-time DNS data exfiltration
detection,” 2024. [85] “CVE-2021-43105.” [Link]
detail/CVE-2021-43105, 2021.
[73] G. Duan, Q. Li, Z. Zhang, D. Zhao, G. Xie, Y. Yang,
Z. Yuan, Y. Jiang, and M. Xu, “DNSGuard: In-network [86] “CVE-2021-3448.” [Link]
defense against DNS attacks,” IEEE Transactions on detail/CVE-2021-3448, 2021.
Dependable and Secure Computing, 2024.
[87] “CVE-2020-25684.” [Link]
[74] G. Cormode, “Count-min sketch.,” 2009. detail/CVE-2020-25684, 2020.
[75] N. McKeown, T. Anderson, H. Balakrishnan, [88] J. tech, “DNSpooq,” 2021.
G. Parulkar, L. Peterson, J. Rexford, S. Shenker, and
J. Turner, “Openflow: enabling innovation in campus [89] “CVE-2017-12132.” [Link]
networks,” ACM SIGCOMM computer communication detail/CVE-2017-12132, 2017.
review, vol. 38, no. 2, pp. 69–74, 2008.
[90] “CVE-2008-3217.” [Link]
[76] V. L. Pochat, T. Van Goethem, S. Tajalizadehkhoob, detail/CVE-2008-3217, 2008.
M. Korczyński, and W. Joosen, “Tranco: A research-
oriented top sites ranking hardened against manipula- [91] “CVE-2008-1447.” [Link]
tion,” arXiv preprint arXiv:1806.01156, 2018. detail/cve-2008-1447, 2008.

[77] X. Li, D. Wu, H. Duan, and Q. Li, “DNSBOMB: A new [92] “CVE-2008-1454.” [Link]
practical-and-powerful pulsing dos attack exploiting detail/cve-2008-1454, 2008.

17
 [93] “CVE-2008-1146.” [Link] • Fixed-threshold WS: The memory usage is calculated
detail/cve-2008-1146, 2008. as O(τ ∑y wy · ℓ log m). With τ = 0.01:

[94] “CVE-2007-2926.” [Link] For 10 domains: 0.01 × 10 × 32 × log(1) = 3.2 bytes

detail/cve-2007-2926, 2007. For 100 domains: 0.01 × 100 × 32 × log(10) = 32 bytes
[95] “CVE-2002-2211.” [Link] For 1K domains: 0.01×1K ×32×log(100) = 640 bytes
detail/cve-2002-2211, 2002. For 10K domains: 0.01×10K ×32×log(10) = 9.6K bytes

[96] “CVE-2002-2212.” [Link] The comparison of memory usage is presented in Fig. 3.

detail/cve-2002-2212, 2002.
A.0.2 Error Rates Calculation
[97] “CVE-2002-2213.” [Link]
detail/cve-2002-2213, 2002. • Count-Min Sketch (CMS):
e 2.718
[98] OISF, “Suricata,” 2024. ε= ≈ ≈ 0.01
w 200
[99] Suricata, “Suricata DNS events,” 2018. • Fixed-size dwsHH: The error formula is given by:

[100] Suricata, “Suricata emerging DNS events,” 2017. 1 wy

Error = wy + √
k∑y 2ℓ
[101] J. Koziol, Intrusion detection with Snort. Sams Pub-
lishing, 2003. Assuming wy = 1 for all y and ℓ = k, we calculate the
error for different cache sizes k:
[102] B. Caswell, J. Beale, and A. Baker, Snort intrusion For 10 domains: 10 1 1
∑y 1 + √2×10 10
= 10 + √120 = 1 +
detection and prevention toolkit. Syngress, 2007. 1
4.47 ≈ 1 + 0.223 = 1.223
1 1
[103] A. Klein, H. Shulman, and M. Waidner, “Internet-wide For 100 domain: 100 ∑y 1 + √2×100 = 100 √1
100 + 200 =
study of DNS cache injections,” in IEEE INFOCOM 1
1 + 14.14 ≈ 1 + 0.071 = 1.071
2017-IEEE Conference on Computer Communications, For 1000 domains: 1000 1
∑y 1 + √ 1 = 1000
+
2×1000 1000
pp. 1–9, IEEE, 2017.
√1 = 1+ 1
≈ 1 + 0.022 = 1.022
2000 44.72
1 1 10000
For 10000 domains: 10000 ∑y 1 + √2×10000 = 10000 +
A Appendix - Full Analysis - Rℓ1 √ 1 1
20000
= 1+ 141.42 ≈ 1 + 0.007 = 1.007
A.0.1 Memory Usage Calculation • Fixed-threshold WS: The error bound is calculated as
wy
• Count-Min Sketch Given the large difference between τ−1 + √2ℓ = 0.01−1 + √164 = 100.125:
the ranges, we can use low values for d and w to mini- The comparison of error rates is presented in Fig. 4.
mize memory usage while still achieving effective differ-
entiation. By setting d = 5 (number of hash functions)
A.0.3 Inference Time Calculation
and w = 200 (number of counters per row), we get:
• Count-Min Sketch (CMS): The query time is O(d),
with d = 5, involving 5 hash lookups.
w × d × size of counter = 200 × 5 × 4 = 4000 bits • Fixed-size dwsHH: The query time is O(log n) for keys
not in cache, and 2 accesses for keys in the cache.
• Fixed-size dwsHH: The memory usage is calculated
• Fixed-threshold WS: The query time is O(τN):
as O(kℓ log m). Assuming k = 100 and ℓ = 32, and m ≈
0.1N: For 10 domains: 0.01 × 10 = 0.1
For 100 domains: 0.01 × 100 = 1
For 10 domains: 100 × 32 × log(1) = 3.2K bits
For 1000 domains: 0.01 × 1000 = 10
For 100 domains: 100 × 32 × log(10) = 3.2K bits For 10K domains: 0.01 × 10000 = 100
For 1K domains: 100 × 32 × log(100) = 6.4K bits
B Appendix - Full Algorithm
For 10K domains: 100 × 32 × log(1000) = 9.6K bits

18
 Algorithm 3 Rℓ2 Function - Check for Fragmentation
Algorithm 1 DNS-CPM 1: function Rℓ2(p) ▷ Initialize result as False
Require: Set of packets P = {p1 , p2 , . . . , pn }, Count-Min 2: if [Link] == 0 & [Link] == true then ▷ 1st frag
Sketch (CMS), Threshold τ, Check interval N, Counter 3: return true
count, Window size W , initial time t, domain map 4: [Link] > 0 ▷ 2nd frags
domainMap, global action 5: p ← NULL
Ensure: Global constants: CMS, τ, N 6: end if
1: for each packet pi ∈ P do ▷ Iterate through all packets 7: return false
2: if Rℓ1(pi , domainMap) or Rℓ2(pi ) or Rℓ3(pi ) then 8: end function
3: if pi ! = NULL then
4: action ← ”truncate”
5: pi .TC ← 1 ▷ Set Truncated bit
6: pi .Ans ← blank ▷ Clear answer record Algorithm 4 Rℓ3 Function - Bailiwick Rule Compliance
7: pi .Auth ← blank ▷ Clear auth record 1: function Rℓ3(p)
8: pi .Add ← blank ▷ Clear add record 2: is_valid ← true
9: end if 3: for all record ∈ [Link] do
10: else 4: if not I S W ITHIN BAILI -
11: action ← ” f orward” ▷ No rule fired WICK ([Link], [Link]) then
12: end if 5: is_valid ← false
13: Send pi to pi .dest ▷ Send packet to its destination 6: break
14: end for 7: end if
8: end for
9: if is_valid then
10: for all record ∈ [Link] do
11: if not I S W ITHIN BAILI -
WICK ([Link], [Link]) then
12: is_valid ← false
Algorithm 2 Rℓ1 Function - Probabilistic Count of Domains
13: break
1: function Rℓ1(p, domainMap) ▷ Initialize result as False 14: end if
2: [Link]([Link]) ▷ Update CMS with p 15: end for
3: if count mod N == 0 then ▷ Check frequency 16: end if
4: if [Link](p) > τ then 17: if is_valid then
5: if domainMap[[Link]] == true then 18: for all record ∈ [Link] do
6: return true 19: if not I S W ITHIN BAILI -
7: else WICK ([Link], [Link]) then
8: domainMap[[Link]] ← true ▷ Signal 20: is_valid ← false
the domain is from now suspicious 21: break
9: return true ▷ Now, truncate the packet 22: end if
10: end if 23: end for
11: end if 24: end if
12: count ← count + 1 ▷ Increment packet counter 25: if ¬is_valid then return true
13: if [Link] − t mod W > 0 then ▷ window t/o 26: else return false
14: count ← 0 ▷ init packet counter 27: end if
15: CMS ← New(CMS) ▷ init the CMS table 28: end function
16: domainMap ← domainMap ▷ init map 29: function I S W ITHIN BAILIWICK(domain, origin)
17: t ← [Link] ▷ Init the time variable 30: is_within ← false
18: end if 31: if E NDS W ITH(domain, origin) then
19: end if 32: is_within ← true
20: return false 33: end if
21: end function 34: return is_within
35: end function

19