Hosting open Domain Name Service (DNS) resolvers has long been considered bad practice because it exposes infrastructure to abuse and can lead to service deterioration including in the operating network. I’m not talking about public DNS services that are (in general) carefully operated and taken care of, but devices that typically, due to misconfigurations, are exposed as an open DNS resolver and can potentially be misused in Distributed Denial of Service (DDoS) attacks.
Researchers and operators have made efforts to reduce the number of (unnecessary) open resolvers. However, looking at the dimensions of recent attacks, the residual pool of open resolvers is noticeably more than large enough for attackers.
This prompted my colleagues and me at the University of Twente to think of how to further shrink the surface for abuse of open resolvers during DDoS attacks, specifically the amplification power. We recently experimented with open resolvers to identify amplification power diversities that we intuitively expected among open resolvers in the IPv4 address space. Among our findings, we found that we can reduce the overall potential of such attacks by 80% if we patch around 20% of the most potent amplifiers.
Analysing resolvers in the wild
The first step required finding open resolvers in the wild. One way to go about this is to use existing DNS scan projects, of which multiple are running in parallel. However, we had barriers along the way, such as dataset timeliness, and so ended up running our own scans.
Once we collected the list of open resolvers it was time to figure out the differences between them. Since there are no specific metrics for this, we used our DNS knowledge to list aspects that contribute to the amplification power of open resolvers, including:
- How DNS protocol features such as DNSSEC are supported by open resolvers.
- How they handle ANY queries.
- How they cache responses.
- TCP support for truncated answers.
You can find detailed information on how these aspects contribute to the amplification power of open resolvers in our paper.
We used these features to craft DNS queries covering various query types and settings (see Table 1 for a full list). Also, we configured the authoritative nameserver of a domain name under our control to react to incoming queries in a way that lets us assess the amplification power of open resolvers.
|#||Query Type||ENDS0 enabled||EDNS buffer size (B)||DO bit set||Amplification factor||Description|
|1||A||No||-||No||1.9||0-day churn investigation|
|2||A||Yes||4,096||Yes||8.5||DNSSEC support test|
|4||ANY||Yes||16,384||No||32.4||EDNS0 enabled ANY|
|5||ANY||Yes||16,384||Yes||38.0||EDNS0 and DO enabled ANY|
|6||ANY||Yes||16,384||No||153.7||ANY with 12KB response size|
|8||TXT||Yes||16,384||No||24.8||EDNS0 enabled TXT|
|9||TXT||Yes||16,384||Yes||31.4||EDNS0 and DO enabled TXT|
|10||TXT||Yes||16,384||No||125.9||TXT with 11KB response size|
|11-13||2 x A & ANY||No||-||No||1.9||A and ANY cache test|
|14,15||2 x ANY||No||-||No||1.9||0–TTL response caching|
Table 1 — Queries issued for systematic testing of amplification power of open resolvers.
Let’s now dive into a couple of our findings.
Redefinition of open resolvers
Traditionally, network-attached devices are considered open resolvers if they respond to ‘A’ queries. However, our study shows that being open (as in answering ‘A’ queries) is not necessarily equivalent to successfully resolving other queries. By issuing various DNS queries towards each open resolver, we noticed that queries that were part of the DNS specification from the beginning of its design, are not equally supported by resolvers.
A simple example is classic ‘TXT’ queries. We noticed that roughly 19% of open resolvers were not able to properly resolve these queries. This number drastically increases for queries that trigger bulky responses.
This was indeed what we were looking for — diversity among open resolvers in how they behave when they receive different queries, as this is a better indicator of their ability to amplify attacks.
As an extension designed to increase the security of the DNS protocol, DNSSEC is also an appealing tool for DDoS attackers. DNS answers for DNSSEC-signed domains are large and thus provide attackers with another layer of amplification. Therefore, DNSSEC-signed domains frequently appear in DNS-based DDoS attacks.
The good news is we found most open DNS resolvers are not capable of handling such queries. The bad news is that those which support DNSSEC are still enough for attackers to potentially carry out attacks even stronger than what we’ve previously seen.
DNS resolvers are supposed to retry over TCP in case they receive a truncated answer from an upstream resolver. We found slightly more than 10% of open resolvers fall back to TCP when our upstream (authoritative) nameserver sends them truncated answers. This is good news (considering ~90% of resolvers don’t fall back to TCP) for two reasons:
- It limits response sizes to what the authoritative nameserver is willing to send over UDP.
- It can be used as a mitigation mechanism to cap the amplification power of open resolvers.
What would we gain?
Given the role of highly provisioned open resolvers in destructive attacks, we investigated and quantified how far we can reduce the potential of Internet-wide amplification attacks by rooting out potent amplifiers first.
We ranked open DNS resolvers based on the highest amplification factor that they supported in our measurements. We then used this ranking to calculate an aggregate DNS-based amplification power in the IPv4 space. Our findings revealed that we can reduce the overall potential by 80% if we patch around 20% of the most potent amplifiers (see Figure 1).
Due to ethical considerations, we do not publicize the list and ranking of open resolvers in our experiment. However, we are open to collaborating with the research community and operators to actively reduce the number of active and potent open resolvers.
Ramin Yazdani is a PhD student in the Design and Analysis of Communication Systems (DACS) research group at the University of Twente, the Netherlands.
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.