{"id":3625,"date":"2014-05-13T21:16:16","date_gmt":"2014-05-13T21:16:16","guid":{"rendered":"https:\/\/live-infoblox-blog.pantheonsite.io\/?p=3625"},"modified":"2025-04-02T11:32:06","modified_gmt":"2025-04-02T18:32:06","slug":"finding-and-fixing-open-dns-resolvers","status":"publish","type":"post","link":"https:\/\/www.infoblox.com\/blog\/ipv6-coe\/finding-and-fixing-open-dns-resolvers\/","title":{"rendered":"Finding and Fixing Open DNS Resolvers"},"content":{"rendered":"

DoS Attacks Leveraging Open DNS Resolvers<\/h2>\n

The Domain Name System (DNS)<\/strong><\/a> has been the target of many types of attacks in recent years.\u00a0 Authoritative DNS servers are exposed to the Internet and generally allow queries from all IP addresses.\u00a0 However, DNS resolvers are typically internal to an organization and allow queries only from the internal clients they serve.\u00a0 DNS resolvers that allow queries from all IP addresses and are exposed to the Internet can be attacked and used to conduct Denial of Service (DoS) attacks on behalf of the hacker.\u00a0 Following is a picture of how an attack on an open DNS resolver could take place and result in a DNS traffic amplification attack.<\/p>\n

\"Open<\/p>\n

Step 1) The attacker places a very large DNS record on an authoritative DNS server that is accessible from the Internet. \u00a0This record also has a very long Time-To-Live (TTL) value.\u00a0 The attacker could also send a query for a well-known large response such as a query for ANY from isc.org.<\/p>\n

Step 2) The attacker sends a spoofed DNS query for this DNS record to the open DNS resolver.\u00a0 The open DNS resolver is not checking the source IP address of the query so it accepts the query and performs the DNS recursive lookup on the behalf of the client.<\/p>\n

Step 3) The open DNS resolver fetches the large DNS record and caches that entry for the very long TTL duration.\u00a0 At this point, the attacker can remove the DNS record from the authoritative DNS server.<\/p>\n

Step 4) The attacker continues to send small spoofed queries to the open DNS resolver for that cached record.\u00a0 Those queries have a source address of the victim\u2019s IP address.\u00a0 The open DNS resolver fails to check the query IP address and sends the large DNS cached record to the victim\u2019s IP address.\u00a0 The attack continues as long as the attacker sends the fake queries.<\/p>\n

A crafty attacker could achieve up to an 80:1 amplification potential by taking advantage of EDNS0\u2019s (RFC 2671) larger response packet size.\u00a0 An army of attackers leveraging a set of open DNS resolvers could generate gigabits of DoS traffic.\u00a0 In fact, the largest DNS DDoS attack targeting\u00a0Spamhaus<\/a>\u00a0in March of 2013 generated a whopping\u00a0300Gbps<\/a>.<\/p>\n

These types of attacks and how to protect against them are well documented in IETF RFC 5358,\u00a0Preventing Use of Recursive Nameservers in Reflector Attacks<\/a>.<\/p>\n

Do You Have an Open DNS Resolver?<\/h2>\n

We first need to figure out if we are vulnerable to such type of attack.\u00a0 The first step would be to assess if any of our DNS resolvers are connected to the Internet or are reachable from the Internet.<\/p>\n

In most enterprise environments, the DNS resolvers are on the internal network and provide recursive DNS query support to internal hosts.\u00a0 However, today\u2019s networks aren\u2019t so clear cut with all resources safely tucked away inside the internal IT environment behind a tightened down firewall.\u00a0 Today\u2019s networks are turned inside out so that external mobile workers, partners, and customers can reach the services in the data center.\u00a0 Cloud-based services also virtualize the location of services that historically were located within the internal server farms.<\/p>\n

Another way to determine if you have an open DNS resolver that is susceptible to this type of attack is by leveraging tools like NetMRI<\/strong><\/a> to analyze your DNS traffic patterns for anomalies.\u00a0As Thomas Jefferson might have said, \u201cEternal vigilance is the price of liberty<\/a>\u201d.\u00a0 Therefore, we need to be aware of how our IT systems are behaving.<\/p>\n

If your DNS resolvers are exposed to the Internet and reachable by an attacker as described above, then you will definitely need to take steps to lock it down and prevent it from being used for a DoS attack.<\/p>\n

Internet Community Support<\/h2>\n

There are several sources of information on this issue publically available.<\/p>\n

The\u00a0Open Resolver Project<\/a>\u00a0is attempting to document the list of DNS servers that accept recursive queries from the Internet.\u00a0 They have a detailed\u00a0breakdown<\/a>\u00a0of the number of DNS servers that are misconfigured or exhibiting specific behaviors.\u00a0 Their data shows that there are over 20 million open DNS resolvers on the Internet.<\/p>\n

If you don\u2019t know what DNS Resolver you are using, you can open up a browser and go to\u00a0http:\/\/myresolver.info<\/a>\u00a0and it will output your public IP address and what DNS recursive resolver you seem to be using.<\/p>\n

US-CERT has provided guidance for U.S. federal government organizations to help them secure their DNS servers from behaving as open recursive DNS resolvers.\u00a0 This\u00a0helpful guide<\/a>\u00a0goes into how to secure many of the popular DNS services.<\/p>\n

Team Cymru also has a\u00a0page<\/a>\u00a0dedicated to this security issue and they have a good 5-minute\u00a0video<\/a>\u00a0that covers DNS Amplification Attacks.\u00a0 Team Cymru also provides a secure BIND configuration\u00a0template<\/a>\u00a0that compiles many DNS security best practices into one document.<\/p>\n

The\u00a0DNS Measurement Factory<\/a>\u00a0has a\u00a0page<\/a>\u00a0dedicated to open DNS resolvers and how they perform testing along these lines.\u00a0 This site contains a good paper by Duane Wessels on \u201cIs Your Caching Resolver Polluting the Internet?<\/a>\u201d\u00a0 The DNS Measurement Factory also provides several\u00a0resources and tools<\/a>\u00a0to test your DNS server externally to your organization.<\/p>\n

Preventing Open DNS Resolver Vulnerabilities<\/h2>\n

There are several ways to prevent these types of attacks if your organization has a DNS resolver that is reachable from the Internet or other untrusted networks.<\/p>\n

One way to prevent these attacks is to restrict your DNS resolvers to only accept queries from specific IP addresses.\u00a0 For example, if the DNS resolver is on the internal network and only services internal clients, then it should be configured to use a filter to only those specific IP address ranges.\u00a0 In a typical enterprise network, this would likely be the private RFC 1918 IPv4 address space or your organization\u2019s assigned global IPv6 address block.<\/p>\n

If you are using a DNS resolver that straddles the internal and external network using two different physical or logical network interfaces, then you could also configure the DNS resolver to only allow queries on the internal interface from internal hosts.\u00a0 It could be configures such that its external interface would drop all DNS queries.<\/p>\n

Another method of helping prevent these types of DoS attacks is to use Best Current Practice (BCP) #38 network ingress filtering on your network perimeter.\u00a0 If your DNS resolver is on your DMZ, then you can use filters on an external Internet router or firewall to prevent clients on the Internet from querying the DNS resolver.\u00a0 Regardless of the DNS server topology,\u00a0BCP38<\/a>\u00a0ingress\/egress filtering is strongly recommended for the many other security benefits it provides.<\/p>\n

Securing BIND 9.X DNS Servers<\/h2>\n

If your organizations uses the Internet Systems Consortium (ISC) implementation of\u00a0BIND<\/a>\u00a0for your DNS servers, then there are simple steps you can take to prevent these types of attacks.\u00a0 ISC has a page titled \u201cIs Your Open DNS Resolver Part of a Criminal Conspiracy?<\/a>\u201d which contains several good links.\u00a0 Following are the configuration settings to help secure your ISC BIND 9.x DNS servers:<\/p>\n

BIND version\u00a09.9.4<\/a>\u00a0now includes Response Rate Limiting (RRL<\/a>), which limits the number of responses returned by a DNS resolver to help mitigate these DNS amplification attacks.\u00a0 If you are running a new version of BIND (and you should always keep your software updated and patches), then you may already have this feature.\u00a0 To enable it, you would need to make this type of configuration setting in your \/etc\/named.conf file.<\/p>\n

options {\r\n  rate-limit {\r\n    responses-per-second 5;\r\n  };\r\n};<\/pre>\n
If you have an authoritative DNS server exposed to the Internet, you should implement DNSSEC<\/strong><\/a> and disable recursion to mitigate security risks effectively. Here is the configuration settings you need to make in the \/etc\/named.conf file.<\/p>\n
options {\r\n  recursion no;\r\n  additional-from-cache no;\r\n};<\/pre>\n
If you have an internal caching DNS Resolver running BIND, then the following configuration settings in the \/etc\/named.conf file can help you secure these servers.\u00a0 This configuration uses BIND views to allow queries only from the networks in the \u201callowed\u201d ACL and denies queries outside that view.<\/p>\n
acl \"allowed\" {\r\n      192.168.0.0\/16;\r\n};\r\noptions {\r\n  recursion no;\r\n  additional-from-cache no;\r\n  allow-query { none; };\r\n};\r\nview \"allowed\" in {\r\n  match-clients { allowed; };\r\n  allow-query { allowed; };\r\n  recursion yes;\r\n  additional-from-cache yes;\r\n};<\/pre>\n
Starting in BIND version\u00a09.4<\/a>, ISC the configuration options for controlling queries and recursion.\u00a0 Now there are allow-recursion, allow-query, and allow-query-cache settings in the \/etc\/named.conf file.\u00a0 BIND 9.4 also introduced the settings allow-query-on, allow-recursion-on, allow-query-cache-on to specify the network interface used for DNS queries.\u00a0 For newer BIND caching DNS Resolvers, the following configuration would help secure against open DNS resolver attacks.<\/p>\n
acl \"allowed\" {\r\n  192.168.0.0\/16;\r\n  localhost;\r\n  localnets;\r\n };\r\noptions {\r\n     allow-query { any; };\r\n     allow-recursion { allowed; };\r\n     allow-query-cache { allowed; };\r\n};<\/pre>\n
Restricting DNS Queries and Recursion on Infoblox<\/h2>\n
Infoblox DNS Serves, equipped with Advanced DNS protection<\/strong><\/a>, have always had a focus on security.\u00a0 If you are lucky enough to have Infoblox DNS appliances with Infoblox\u00a0Advanced DNS Protection<\/a>\u00a0then you have many DNS attack mitigation options at your fingertips.\u00a0 Regardless, you will still want to make sure that your Infoblox DNS servers are configured to only allow query access from the systems that you require.\u00a0 Here are the steps to restrict queries and deny recursion to an Infoblox Grid member.<\/p>\n