DNS Open Resolvers Best Practices

Number: TR13-002
Date: 8 April 2013

1. Audience

This report is intended for IT professionals and managers within provincial/territorial and municipal governments; critical infrastructure; and other related industries. It is assumed the reader is familiar with the basic operation of DNS. The recipients of this product may further distribute it to technical stakeholders within their organization.

2. Purpose

The purpose of this report is to provide IT security personnel with an introduction to Domain Name Systems (DNS) and DNS open resolver's security configuration best practices. The aim of this document is to assist system owners to identify potentially unsecure DNS implementations and mitigate associated security risks such as DNS cache poisoning and reflection or amplification attacks. This document may be used by system administrators; computer security incident response teams (CSIRTS), IT security operations centres and other related technology groups.

3. DNS

The Domain Name System (DNS) protocol provides a distributed, hierarchical, dynamic database whose primary function is to map hostnames (e.g.: www.publicsafety.gc.ca) to IP addresses (e.g.: 198.103.108.123). There are two types of domain name servers: authoritative and recursive. An authoritative name server will provide an original, non-cache answer for which it holds the authoritative record. A recursive name server will answer a query even if they do not hold the authoritative answer by using cached data or by repeatedly asking other name servers on behalf of their client.

DNS has been historically leveraged as an attack platform because it primarily uses UDP (User Datagram Protocol), a stateless protocol that does not use handshaking between the sender and recipient, exposing it to source spoofing and race condition type of attacks. These weaknesses, although not part of the design of the DNS protocol itself, can have an impact on the way DNS is configured and used. The most commonly observed DNS based attacks include Cache Poisoning and DNS reflector/amplification attacks, which can result in Denial of Service (DoS) condition. Despite these, DNS remains an essential part of the internet and can generally be configured to operate securely. 

Figure 1 Normal DNS Open Recursion

Normal DNS Open Recursion
Image Description

The above figure shows the following steps in normal DNS open recursion traffic.

  1. User queries a DNS open resolver for the IP address of www.xyz.domain.com.
  2. DNS open resolver forwards the query to a DNS Root server.
  3. The DNS Root server responds back with not knowing the answer, but does know .com.
  4. DNS open resolver forwards the query to the authoritative DNS server for .com.
  5. The authoritative DNS server for .com does not know the answer, but does know who the authoritative server for www.xyz.domain.com is.
  6. DNS open resolver forwards the query to the authoritative DNS server for www.xyz.domain.com.
  7.  The authoritative DNS server for www.xyz.domain.com answers with the IP address.
  8. The DNS open resolver forwards the response to the user who originally requested the information.

3.1 DNS Reflector and Amplification Attack

Reflector attacks use recursive DNS servers to reflect DNS query packets with spoofed source IP addresses to a target victim. The open resolver will then unknowingly send the DNS response message to the victim, amplifying it because of the small query – large response ratio to cause a DDoS/DoS attack. The small query packet can be up to 64 bytes while the large response packet can be up to 512 bytes, causing an amplification factor of 8:1. The amplification factor also depends on whether the attacker is leveraging an extension to the DNS protocol, Extension Mechanisms for DNS (EDNSOFootnote 1). If so, the amplification factor can be as high as 70:1. This type of attack uses multiple open resolvers to magnify the attack and overwhelm the victim and the use of spoofed source IP addresses also makes it more difficult to trace.

Figure 2 DNS Amplification/Reflector Attack

DNS Amplification/Reflector Attack
Image Description

The above figure shows the following steps in a DNS amplification/reflector attack

  1. An attacker activates a botnet.
  2. The botnet, or compromised hosts, will send multiple queries requesting the IP address of www.xyz.domain.com to multiple DNS open resolvers with a spoofed source IP address.
  3. DNS open resolver forwards the query to a DNS Root server.
  4. The DNS Root server responds back with not knowing the answer, but does know .com.
  5. DNS open resolver forwards the query to the authoritative DNS server for .com.
  6. The authoritative DNS server for .com does not know the answer, but does know who the authoritative server for www.xyz.domain.com is.
  7. DNS open resolver forwards the query to the authoritative DNS server for www.xyz.domain.com.
  8.  The authoritative DNS server for www.xyz.domain.com answers with the IP address.
  9. Multiple DNS open resolvers forwards the response back to the source IP address that was being spoofed, but who is actually the victim. Each packet reply can be amplified by a factor up to 70, causing a denial of service.

3.2 DNS Cache Poisoning Attack

DNS cache poisoning attacks occur when a fake, malicious address record for a domain has been cached by a name server. It is the result of a fake response being received before a legitimate one by the name server and matching correctly the source port, query ID, IP address and query name. This would in turn redirect users to potentially a malicious domain.

4.0 DNS Open Resolver

A DNS open resolver will resolve recursive queries from any external location even though they are not part of its administrative domain. DNS servers are usually configured to be recursive by default and are often overlooked by administrators, making them a prime target to be used by malicious actors in spoofed source IP address type of attacks.
Operating a DNS open resolver is not recommended unless its configuration and use are actively monitored to prevent abuse. There are many open or public resolvers in use on the internet such as Google's 8.8.8.8 DNS.

4.1 DNS Open Resolver Test

There are several tests to see if you are hosting an open resolver.

4.1.1 Online Tool

Measurement Factory has an online Open Resolver Test that sends a single “recursion desired” query to one or more target addresses. If the queries are forwarded to their authoritative server, the host has an open resolver running at that address.
http://dns.measurement-factory.com/cgi-bin/openresolvercheck.pl

Also available:
ISC DNS Test
https://isc.sans.edu/dnstest.html

Thinkbroadband DNS Check
http://www.thinkbroadband.com/tools/dnscheck.html

Open DNS Resolver Project
http://openresolverproject.org/

4.1.2 Command Line

Alternatively, depending on your platform, type either of the following commands to find out if your own local DNS resolver is open.

*nix systems
#dig +short amiopen.openresolvers.org TXT

Windows systems
$ nslookup
   > set type=TXT
   > amiopen.openresolvers.org
Ideal results will be:
"Your resolver at ip.add.re.ss is CLOSED"

Recommendations

The following recommendations may help mitigate the risk of a DNS infrastructure being used maliciously in reflector/amplification attacks. The most effective solution is to disable open recursion on DNS servers if not required and to employ the use of network ingress filtering as described in BCP 38Footnote 2/84Footnote 3.

5.1 Disable DNS Open Recursion

BIND and Microsoft are the most widely used DNS servers. Below are links describing how to disable DNS recursion:

BIND
http://www.cymru.com/Documents/secure-bind-template.html

Microsoft DNS Server
http://technet.microsoft.com/en-us/library/cc771738.aspx

5.2 Network Ingress Filtering

Network ingress filtering will go a long way in helping reduce DoS/DDoS caused by a DNS reflector/ amplification attacks. Network owners are encouraged to implement this filtering, as described in BCP 38 – Network Ingress Filtering and BCP 84 – Ingress Filtering for Multihomed Networks, to check whether the DNS request source address belongs within an assigned network range reachable via that interface. All packets that do not meet such criteria should be dropped. This will greatly reduce the success of an attacker using a spoofed external source IP address. Internal source IP address may not be prevented from using spoofed source IP address, however, would this occur, the network owner would be well positioned to mitigate and find the source of the attack.

5.3 DNS Server Configuration

Some DNS configuration best practices that organizations should consider in the context of their networking environment include:

6. Securing a DNS Open Resolver

Despite their potential use in attacks, DNS open resolvers are widely available across the Internet. The following configuration guidance may lessen the chance of an open resolver being abused.

6.1 Rate Limiting

Implement rate limitingFootnote 4 Footnote 5, or throttling, for identical response packets per second on authoritative DNS servers. This method will greatly reduce the amount of DNS response packets being sent to the victim, while still allowing legitimate traffic. Rate limiting settings will vary with each DNS server depending on its normal load and whether or not network address translation (NAT) is configured. Determine what the normal operating baseline is for your server and set the rate limit for anything beyond this threshold to be potential reflective/amplification attack traffic. The server will still respond to legitimate queries, but with short truncated responses so that the client will retry with TCP instead. 

6.2 Defending Against Cache Poisoning Attacks

6.2.1 Adding Entropy to Request Message

In order for a cache poisoning attack to be successful, the attacker must guess and match the source port, query ID, IP address and query name of the original request. Adding entropy to a request message will make it harder for the attacker to guess those values. Most modern DNS servers already employ random source ports and query ID; therefore it is imperative that DNS servers are kept up to date. Suggestions to add entropy to the request message are as follows.

Randomize source ports

Do not allow outgoing request messages to use UDP port 53. Instead, use a wide range of non-registered ephemeral ports and a random number generator. If a NAT device is used, then disable port de-randomization.

Randomize Query ID

Ensure that your DNS name server randomizes the query ID for all request messages.

Randomize case in query names

DNS name servers are usually case-insensitive, meaning that xyz.com and XYZ.com will both resolve to the same IP address. Authoritative DNS servers will also preserve the case of the query when sending a response to the recursive server. Randomizing the case, or using 0x20 bit encodingFootnote 6 Footnote 7, in the query names from the recursive server to the authoritative server will make it harder for the attacker to guess what combination will be used.

Randomize choice of name servers

DNS resolvers will typically choose the shortest path when selecting a name server. Randomizing the choice of name servers will again make it harder for an attacker to guess which server is being used when trying to poison the cache.

7. Conclusion

DNS is an important and vital part of how the internet functions. Special considerations must be taken when securing this critical service. As many other Internet technologies, DNS was not originally designed for the diverse and often hostile networking environment we are seeing today. It is therefore important to secure it using available best practices and tools. Implementing  security controls such as those presented in this document can mitigate the risks associated with abuse of the DNS infrastructure.

8. References


Note to Readers

In support of Public Safety's mission to build a safe and resilient Canada, CCIRC's mandate is to help ensure the security and resilience of the vital non-federal government cyber systems that underpin Canada's national security, public safety and economic prosperity. As Canada's computer security incident response team, CCIRC is Canada's national coordination centre for the prevention and mitigation of, preparedness for, response to, and recovery from cyber incidents on non-federal government systems. It does this by providing authoritative advice and support, and coordinating information sharing and incident response.

Please note, CCIRC PGP key has recently been updated.
http://www.publicsafety.gc.ca/cnt/ntnl-scrt/cbr-scrt/_fl/CCIRCPublicPGPKey.txt

For general information, please contact Public Safety Canada's Public Affairs division at:

Telephone: 613-944-4875 or 1-800-830-3118
Fax: 613-998-9589
E-mail: ps.communications-communications.sp@canada.ca

Footnotes

  1. 1

    http://www.rfc-editor.org/rfc/rfc2671.txt

  2. 2

    http://tools.ietf.org/html/bcp38

  3. 3

    http://www.ietf.org/rfc/rfc3704.txt

  4. 4

    http://ss.vix.com/~vixie/isc-tn-2012-1.txt

  5. 5

    http://ss.vix.su/~vjs/rl-arm.html

  6. 6

    http://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00

  7. 7

    http://courses.isi.jhu.edu/netsec/papers/increased_dns_resistance.pdf

Date modified: