An ‘open resolver’ is a Domain Name System (DNS) server that accepts and resolves a domain name recursively for anyone on the Internet. In this blog post, we will share the security risks of open resolvers and best practices.
At the time of writing, there were 192,920 open resolvers in India with recursion enabled. While most of these are broken Customer Premises Equipment (CPE), some are open probably due to misconfiguration on the part of the DNS administrators.
Out of the total count, 114,521 were running ‘dnsmasq’, a popular DNS server software found in CPE firmware.
What security risks do open resolvers pose?
An open resolver can be abused by threat actors to initiate a Denial of Service (DoS) attack. Simply put, running an open resolver is a bad security practice.
DNS amplification attack or a DoS attack using an open resolver?
A DNS amplification attack is a popular form of distributed denial of service (DDoS) that relies on the use of publicly accessible open DNS servers to overwhelm a victim system with DNS response traffic.
Between 15 January 2023, 15:01:17 and 10 April 2023, 01:28:31, a single instance of our honeypot received 135,972,316 DNS queries from Brazil for the domain higi.com.
Objective of the attack
On primary evidence, it is most likely that the objective of the attack is to send a large influx of DNS query traffic to the authoritative name servers of higi.com. At the time of writing, the DNS A record of higi.com had a time-to-live (TTL) value of 600 seconds.
A global coffee chain serving an open resolver ☕
It’s not just CPE boxes with broken firmware/configuration that have the problem of open resolvers. Shreshta threat analysts have detected enterprise DNS resolvers and even a global coffee chain running an open resolver!
As a recursive resolver operator, here are some of the best practices that should be followed:
- Allow access to the recursive resolver only to the authorized IP addresses/netblock.
- Response rate limiting.
- On an authoritative-only nameserver, disable recursion.
- For network operators — implement BCP 38 (Network Ingress Filtering).
We also urge recursive resolver and authoritative name server operators to explore KINDNS (which stands for Knowledge-Sharing and Instantiating Norms for DNS and Naming Security). It’s a program supported by ICANN to develop and promote a framework that focuses on the most important operational best practices or concrete instances of DNS security best practices.
We have contacted higi.com as well as the DNS administrators of the global coffee chain to share our findings.
As seen in this post, it’s important to follow best practices to eliminate the risks of running an open resolver.
Swapneel Patnekar is the CEO of Shreshta, a threat intelligence company. He has more than +15 years experience in information security. He is an APNIC Community Trainer and has delivered workshops in Myanmar, Papua New Guinea, Bangladesh and Sri Lanka. He is also a Forum of Incident Response and Security Teams (FIRST) DNS Abuse SIG member. He has also delivered technical workshops to Law Enforcement on countering cybercrime. He is a prolific speaker and frequently presents at security conferences.
Adapted from the original post on Shreshta Blog.
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.