Instances of attackers using IP fragmentation to poison the cache of the Domain Name System (DNS) have been known for almost a decade. However, until recently, no one has conclusively studied the frequency of IP fragmentation on the Internet nor how effective known mitigation strategies are to such attacks.
In this three-part series, I will report on the findings of a study contracted by the German Federal Cyber Security Authority (BSI) and conducted between December 2019 and September 2021 on the topic of IP fragmentation and DNS traffic.
The study attempted to answer the following key questions:
- Do DNS cache poisoning attacks via fragmentation impose a real threat?
- Is it possible to mitigate such attacks?
- How effective are these mitigations?
- 0.1% of DNS traffic is fragmented, almost all of which comes from DNSSEC signed domains.
- Nameservers of high-profile domains are responding with fragments.
- More than 99% of DNS responses are via UDP.
- Most IPv4 and IPv6 responses are not at risk of fragmentation as they fall below levels set by popular operating systems.
What is IP fragmentation?
IP fragmentation is the process that breaks packets into smaller pieces (fragments) so that the resulting pieces can pass through a link with a smaller Maximum Transfer Unit (MTU) than the original packet size.
When a gateway, usually a router, splits UDP datagrams (such as DNS messages) into fragments, it adds another ID to the IP packet, which indicates the fragment’s number. On the receiving end, this information is used to reassemble fragments into datagrams first and datagrams into data afterwards.
It is this fragment ID, which makes the process of IP fragmentation vulnerable to forgery because under some circumstances it allows an attacker to ’guess’ the ID and introduce forged data into the transport without any notice.
Given today’s computing power, guessing the ID of IPv4 packets is relatively easy nowadays — the ID number space consists of 65,536 numbers that come from a known global counter.
This is not the case for IPv6 though, which has a 32-bit IP-ID value (compared to IPv4’s 16-bit value) equating to a much larger ID number space. Further, all popular operating systems assign the IP-ID randomly.
How does this relate to DNS cache poisoning?
A DNS cache poisoning attack attempts to introduce forged data into a DNS resolver’s cache. The resolver hands this data to any DNS client querying for the poisoned resource record (RR). It does not ask the authoritative DNS server for updated and likely non-forged data until the record’s time-to-live (TTL) has expired. While the forged data resides in the DNS resolver’s cache, any client using that data will likely be abused.
The attack occurs when a DNS resolver needs to look up a DNS resource from an authoritative server. Traditionally, it will use IPv4 and UDP to send the query and it expects the DNS server to do so as well when it responds. For traditional DNS cache poisoning, the attacker needs to guess the query-id (QID) used, which is a random 16-bit number.
With the help of IP fragmentation, the attacker will try to spoof the second fragment, which contains vital DNS data but none of the authenticating information.
Where does DNSSEC fit in all of this?
DNSSEC is an extension of the DNS protocol. It adds cryptographic signatures to resource records and allows a receiver, for example, a DNS resolver, to verify that the resource record has not been tampered with on its way from the authoritative DNS server to the DNS resolver. If it has, the record’s cryptographic signature does not match that which the DNS resolver calculates to be a valid signature.
While this does not allow a DNSSEC-enabled DNS resolver to detect a single forged fragment, it does allow the resolver to detect that something is wrong with the reassembled resource record as a whole and that the response must not be passed on to the client, which started the query. Obviously, a DNSSEC-enabled DNS resolver would not store an invalid DNSSEC-signed response in its cache. DNSSEC therefore would be a suitable measure to mitigate any IP fragmentation-based attack on DNS resolver caches.
However, DNSSEC-signed DNS zones are not as common as they should be. This lack of availability has been the main driver for conducting this study and looking for other measures, which help to mitigate IP fragmentation-based attacks that aim to poison a DNS resolver’s cache.
The state of IP fragmentation
One of the predominant tasks of this study was to measure the existence of IP fragmentation, ascertain its distribution among IPv4 and IPv6, and evaluate popular operating systems for their IP fragmentation vulnerability potential. The findings, summarized below, subsequently helped to evaluate which measures should be taken.
0.1% of DNS traffic is fragmented, almost all of which comes from DNSSEC signed domains
To get a real-world impression of the state of IP fragmentation, we used a European cable Internet provider’s DNS resolver infrastructure to collect actual data on DNS IP fragmentation over the course of 24 hours between 14 and 15 July 2020 (Figure 1). This resolver infrastructure is queried by millions of DNS clients throughout the day, amounting to a significant number of samples (54,023,478 IPv4 and 96,620,298 IPv6).
Overall, 0.1% of all DNS traffic collected was fragmented (55,064 IPv4 and 104,129 IPv6). Of this, approximately 97% of all IPv4 and 93% of all IPv6 fragmented responses came from domains signed with DNSSEC. This was expected, as DNSSEC-signed zones additionally send cryptographic signatures (RRSIG), causing larger responses, and as a consequence, triggering the need for IP fragmentation more often. DNSSEC in general can be seen as a technology that drives large DNS responses which may cause DNS fragmentation.
Unfortunately, this poses a risk to DNS resolvers that receive data from a DNSSEC-signed zone (larger responses) but do not validate the DNSSEC data. The rate of DNSSEC validation differs by economy, as can be seen in APNIC’s DNSSEC Validation Rate statistics.
Nameservers of high-profile domains are responding with fragments
Looking at the authoritative DNS servers that had sent fragmented DNS responses using IPv4 (Figure 2), 37 out of 741 servers were accountable for 90% of the fragmented responses. For IPv6, 133 out of a total of 1,052 servers were accountable for 90% of all fragmented responses.
Notably, high-profile domains resided among those whose DNS servers returned fragmented DNS responses.
Domains from where fragmented DNS responses have been seen:
- office.com (Microsoft)
- army.mil (US Army)
- fnfis.com (Fidelity National Information Services)
- fraunhofer.de (Europe’s largest application-oriented research organization)
- rwe.de (German Energy provider)
- agilent.com (Agilent, Research)
- checkpoint.com (Check Point Security — Firewall and VPN products)
- salesforce.com and force.com (Salesforce.com, Inc — Cloud-based customer relationship management solutions)
- fedex.com (FexEx Corporation — multinational delivery services company)
- gnome.org (Gnome Desktop Software — open-source GUI desktop for Linux and Unix)
The majority of fragmented responses were caused by queries for IPv4 and IPv6 address records (A and AAAA records), DNSSEC keys (DNSKEY) and Voice-over-IP Session Initiation Protocol (SIP) connection requests (SRV and NAPTR).
What percentage of DNS servers are sending out fragmented DNS responses?
Once we had established that IP fragmentation for DNS existed, the next step was to measure the percentage of authoritative DNS servers on the Internet sending out fragmented DNS responses.
To do so, we used the OpenINTEL platform to send queries for known domains to their authoritative DNS servers and collect fragmented DNS responses. The test also sought to look at the EDNS0 buffer size configuration of the authoritative DNS servers to find out how many administrators had lowered the permitted payload over UDP to prevent fragmentation and whether the chosen EDNS0 buffer size would have the desired effect.
We found that:
- More than 99% of the 3,893,453,582 DNS responses we collected (~73% IPv4 and ~27% IPv6), were via UDP.
- Around 0.05% of IPv4 responses and 0.1% of IPv6 responses were fragmented. In almost all such cases the response was DNSSEC-signed, coming with DNSSEC signature records. This observation aligned with identical observations measuring IP fragmentation at the ISP’s network.
- For IPv4 (Figure 3), most responses ranged from 0 to 512 bytes. These will not lead to fragmentation of DNS responses, as popular operating systems will not fragment below 552 bytes.
- A larger number of IPv6 responses (Figure 4) ranged from 512 to 1,024 bytes. Again, these will not generate fragmentation either, as the minimum MTU for IPv6 (1,280 bytes) is still above this value.
- Roughly 50% of responses received from authoritative nameservers specified, depending on the implementation in use, had a default EDNS0 maximum response size of 4,000 or 4,096 bytes. The size for IPv4 (red line) and IPv6 (blue line) is roughly the same. (Approximately 25% of IPv4 responses received from authoritative nameservers advertised an EDNS0 maximum response size of 1,472 bytes or less, which would keep responses within the default Ethernet MTU of 1,500 bytes and avoid most natural (non-attack) fragmentation. Approximately 17% of IPv6 responses received from authoritative nameservers advertised an EDNS0 maximum response size of 1,232 bytes or less, which would keep responses within the minimum IPv6 MTU of 1,280 bytes and effectively avoid fragmentation.)
- Up to 40.5% of all responses kept the maximum response size at 1,472 bytes or lower, which practically avoids most fragmentation if path MTU discovery works as it should and the MTU between the endpoints remains at 1,500 bytes.
Natural fragmentation is not a big issue in today’s Internet
Natural fragmentation, that is, not caused by an attack, is not a big issue in today’s Internet. In addition, DNSSEC is not a big driver of DNS responses that exceed the Ethernet MTU.
However, our study looked only at fragmentation for typical DNS queries, as seen during normal operation. It might still be possible for an attacker to find other, not so heavily used resource records in domains (for example, overly large TXT-record sets at the zone’s base name, the zone APEX), which could be abused to launch DNS fragmentation attacks against a DNS zone.
The data showed that approximately a quarter of the responses received indicated operators of authoritative DNS servers had already adjusted their servers’ EDNS0 settings to limit the size of DNS responses over UDP, thus effectively avoiding most fragmentation with an Ethernet MTU of 1,500 bytes. To attack these servers, an attacker would have to find ways to artificially lower the path MTU between DNS resolver and authoritative DNS server below the Ethernet MTU of 1,500 bytes.
In Part 2 of this blog post series, I will look at which DNS server operating systems are vulnerable to ICMP Path MTU spoofing, and whether operating DNS purely over TCP instead of UDP could be a viable mitigation strategy.
Study contributors: Roland van Rijswijk-Deij (NLnet Labs), Patrick Koetter and myself (sys4), and Markus de Brün and Anders Kölligan (BSI).
Carsten Strotmann is a DNS/DHCP/IPv6/Linux/Unix security trainer for Linuxhotel, Men & Mice, and Internet Systems Consortium (ISC).
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.
Interesting topic over attacks and provided solution to stop that attacks on DNS resolver.