![](https://csdnimg.cn/release/download_crawler_static/13131610/bg4.jpg)
Figure 2: CDF of lowered MTU of a) authoritative servers
of Alexa Top 100K domains, and b) 2M open DNS resolvers
from an Internet-wide scan.
proaches proposed so far. The first approach is to lower the
Path Maximum Transmission Unit (PMTU) between the re-
cursive resolver and authoritative servers [33]. We term this
type of attack as PMTU-based defragmentation attack. By
contrast, the second approach is to send DNSSEC queries to
solicit enlarged DNS responses with DNSSEC records, so
that they reach limits of MTUs (e.g., 1,500 bytes for Ether-
net) and will be fragmented [48]. We term this type of attack
as DNSSEC-based defragmentation attack.
Limitations. Previous defragmentations have high require-
ments on the PMTU behavior of authoritative name servers,
as well as the victim domains. Specifically, PMTU-based de-
fragmentation requires an attacker to send specially-crafted
ICMP fragmentation needed error messages to an authorita-
tive server claiming a small PMTU and trick it to lower the
PMTU for a specific resolver. However, we find this is im-
practical in most cases. As shown in Figure 2, for authorita-
tive servers of Alexa Top 100K domains, only 0.7% are will-
ing to reduce their MTU to less than 528 bytes. Since DNS
responses are typically smaller than 512 bytes, it is not likely
that they will be forcibly fragmented. As for DNSSEC-based
attacks, they require non-validating recursive resolvers and
can be mitigated through proper DNSSEC deployment and
validation. Moreover, the attack only works for DNSSEC-
signed victim domains. Currently, DNSSEC deployment is
still low among domain names (e.g., less than 1.85% for
popular domains in 2017 [34]), thus the target of DNSSEC-
based defragmentation attacks is limited.
3 DNS Forwarder
Traditionally, a DNS resolution process involves a DNS
client (or stub resolver), a recursive resolver and authori-
tative servers. When a domain needs to be resolved, the
DNS client sends a query to a recursive resolver, which in
turn fetches answers from authoritative servers. For maxi-
mum protocol capability, it is recommended that DNS clients
use a full-service resolver directly [31]. However, in reality,
the DNS infrastructure has become far more complex than
Figure 3: DNS infrastructure with forwarders
this simple model, often involving multiple layers of servers.
One of the new roles introduced in the infrastructure [29,70],
as shown in Figure 3, is DNS forwarders
1
. They sit in be-
tween stub and recursive resolvers, and often serve as ingress
servers for DNS clients (e.g., home wireless routers). When
a DNS forwarder receives a query, instead of performing the
resolution recursively, it simply forwards the query to an up-
stream recursive resolver. To name a few use cases, it can
serve as a default local resolver (with caching capability) for
clients (e.g., clients using DHCP to obtain network config-
urations in LAN), perform load balancing among upstream
recursive resolvers, and can be used to enforce access con-
trol.
DNS forwarder vs. recursive resolver. In the latest RFC
on DNS terminology (i.e., RFC 8499 [50]), recursive re-
solvers are resolvers which “act in recursive mode”. When
it receives a DNS query, a recursive resolver accesses other
servers, and should respond with the final answer to the
original query. As such, recursive resolvers should handle
referrals to other servers and aliases to other names (i.e.,
CNAMEs), and aggregate the resource records into one final
answer. Recursive resolvers should also perform integrity
checks such as the bailiwick check [39] and DNSSEC val-
idation [30]. In contrast, a DNS forwarder does not recur-
sively resolve queries, and instead relies on the integrity of
its upstream server. As a result, DNS forwarders do not han-
dle referrals, and are typically not in the position to verify
the responses. Otherwise, forwarders will be repeating the
work of resolvers, e.g., checking each referral, defeating the
purpose of having another layer of indirection. As we will
articulate later, this is a key weakness of DNS forwarders
which enables our cache poisoning attack.
4 Defragmentation Attacks
Targeting DNS Forwarders
As we have seen, previous defragmentation attacks have lim-
itations regarding the ability to trigger fragmentation. In this
section, we propose a novel modified defragmentation at-
tack that works perfectly against DNS forwarders due to its
unique role in the DNS infrastructure.
1
Also defined as “FDNS” in literature.
USENIX Association 29th USENIX Security Symposium 579