DNS cache poisoning

What is DNS cache poisoning?

DNS cache poisoning is a type of DNS spoofing attack where the attacker stores fake data in a DNS resolver cache. All clients that use this DNS cache then get fake data and use it to connect to an attacker-controlled resource instead of the legitimate one.

DNS cache poisoning is considered a type of man-in-the-middle attack (MITM) – attackers get the ability not only to send the victim to a fake website but also to connect to the legitimate server in the background and eavesdrop on sensitive information. The same technique can be used for very effective phishing attacks (often called pharming) and to spread malware.

How does the domain name system work?

To understand DNS cache poisoning, we first need to see how the domain name system (DNS) works. The DNS protocol is one of the oldest protocols on the Internet. Its first specifications, RFC 882 and RFC 883, were published in November 1983. At that time, the Internet was a network used only by a handful of academic institutions, and there were no reasons to worry about cybersecurity. This is why the DNS internet protocol was created to be as simple as possible – and why it has major vulnerabilities and is easy to fool.

The DNS system is based on iterative and recursive DNS requests, also called queries or lookups. Each Internet client has a DNS resolver configured in its operating system. When you want to know the IP address for www.something.example.com, this is what happens if your DNS resolver doesn’t have the relevant DNS information in its cache:

1. The client asks its local operating system DNS resolver for the IP of www.something.example.com (recursive query).
2. The local operating system DNS resolver asks the configured closest DNS resolver for the IP of www.something.example.com (recursive query).
3. That DNS resolver contacts the root server of the global DNS system and asks (iterative query) “what is the IP of www.something.example.com?”
4. The root server responds: “I don’t know, but I know the authoritative domain nameserver for the com zone is …”
5. The DNS resolver contacts the authoritative nameserver for com and asks (iterative query) “what is the IP of www.something.example.com?”
6. The authoritative nameserver for com responds: “I don’t know, but I know the authoritative nameserver for example.com is …”
7. The DNS resolver contacts the authoritative nameserver for example.com, and asks (iterative query) “what is the IP of something.example.com?”
8. The authoritative nameserver for example.com could already be the authoritative nameserver for something.example.com, in which case it will respond with an address. Otherwise, it will redirect the DNS resolver to another server, and the process will continue.

Note: A recursive DNS query is when the DNS resolver queries DNS servers until it can provide a certain answer. An iterative DNS query is when the DNS server returns an answer without querying other DNS servers, even if it cannot provide a certain answer.

Each answer comes with a TTL (time-to-live) value that instructs the DNS resolver to cache the response for a specified time. Responses cannot be cached permanently because IP addresses for domain names may change, so they have to be refreshed once in a while. There is no way for an authoritative nameserver to broadcast that the data has changed, so it just needs to wait until resolvers contact it again. The DNS resolvers also don’t automatically refresh DNS information after the TTL passes but wait until someone asks for it.

The above is a very simplified view of the DNS system. There are different types of DNS entries: the basic A record, an alias record called CNAME, a record for mail servers called MX, and more. The two crucial DNS record types we are focusing on are the basic A record used for most cases and the NS record, which represents the authoritative nameserver. There are also many other intricacies involved, but they are not needed here to understand the concept of DNS cache poisoning.

How do DNS servers communicate?

The other reason why DNS cache poisoning attacks are possible is that DNS servers usually communicate using the UDP protocol, not TCP. This means there is no handshake and no authentication required. The DNS resolver sends a UDP packet with a question and waits to receive a UDP packet with an answer.

To forge a DNS response, attackers need to satisfy the following three conditions:

• Every query is sent with a transaction ID (TXID), and the response must include the same transaction ID.
• The response must come from the same IP address to which the query was sent.
• The response must come to the same UDP port from which the query was sent.

In the past, the UDP port requirement was not a problem because all DNS servers used the same UDP port to send responses, which made firewall configuration easier. However, to combat DNS poisoning, port randomization was introduced. A DNS server now listens for queries on port 53 but can send responses from any port, for example:

1. The ns.example.com server listens for a query on port 53.
2. Your DNS resolver sends a query from source port 12345 to ns.example.com:53.
3. The ns.example.com server then sends a response from its port 53 to your DNS resolver at port 12345.

Example of DNS cache poisoning

The basic flow of a DNS spoofing attack is as follows. Let’s say you use 1.2.3.4 as your DNS resolver and the attacker wants to inject false data for www.example.com into the resolver cache. For a simple attack, we must assume that 1.2.3.4 hasn’t received a query about www.example.com for some time, so it doesn’t have the requested data in its cache.

1. The attacker sends a query to the DNS resolver at 1.2.3.4, asking about the IP address for www.example.com.
2. The DNS resolver at 1.2.3.4 begins the query cycle as above, searching for the authoritative nameserver for www.example.com.
3. Before an answer can arrive from the legitimate server, the attacker floods the DNS resolver at 1.2.3.4 on all possible ports with fake answers covering all possible transaction IDs. These answers also use IP spoofing, so they seem to come from the authoritative nameserver for www.example.com.

This attack can only succeed if the attacker is faster than the authoritative nameserver. To make this, the attacker must have a lot of resources (to send a lot of UDP packets very quickly), and the authoritative nameserver must also be slow to respond. Attackers will often perform a denial of service attack on the authoritative nameserver to delay its answer.

While such simple DNS cache poisoning is possible, it’s not very useful to attackers, as they will usually want to poison a very common domain that is likely to already be cached by the DNS resolver. The DNS resolver will not accept any data that is already in its cache. Overwriting existing cache data is possible but often dependent on the DNS resolver implementation. This means the attacker must know what DNS server software is used at 1.2.3.4.

Example of advanced DNS cache poisoning

Advanced DNS poisoning attacks take advantage of additional information that DNS responses may include to help resolve queries. When a DNS resolver asks another DNS server for some information, it may receive an answer that means, “I do not know, but here is the nameserver that knows, and here is its IP address”. This method was first presented by Dan Kaminsky at Black Hat 2008 and works as follows (continuing our example above):

1. The attacker sends a query to the DNS resolver at 1.2.3.4 asking about the IP address of something12345.example.com, knowing that something12345.example.com does not exist.
2. The DNS resolver at 1.2.3.4 does not have data in its cache for the nonexistent domain, so it attempts to ask the authoritative nameserver of example.com about it. Of course, the real answer should be, “I know nothing.”
3. The attacker then floods the DNS resolver with packets of the following format:

Query Section:
  something12345.example.com IN A
Answer Section:
  NONE
Authority Section:
  .example.com IN NS www.example.com
Additional Section:
  www.example.com IN A 12.34.56.78

4. The DNS resolver at 1.2.3.4 may now think that the authoritative nameserver for example.com is www.example.com with an IP address that is supplied and controlled by the attacker (12.34.56.78). This simplifies further attacks because the attacker’s server is now treated as an authoritative nameserver and is the first to receive queries about any subdomains of example.com.

In the example above, the authority section is what is used for queries. This is how DNS servers say “someone else knows this”. The additional section is there to say “and that someone’s IP address is…”

Luckily, the DNS resolver will use data from the additional section to overwrite its existing cached records for www.example.com only in some cases, depending on the level of trust with which the existing data was stored. DNS resolvers assign trust levels depending on how and in which section the cached data was originally received. An answer received directly in the Answer Section is considered more trustworthy than an answer from the Additional Section, so this poisoning technique may not work for major domains. However, it may still work for subdomains, as subdomain information will often be originally provided in the Additional Section.

If you’re interested in the details of successful attacks on three major DNS server solutions (BIND, Unbound, and MaraDNS), there is an excellent paper called The Hitchhiker’s Guide to DNS Cache Poisoning. It explains the attack techniques and shows payloads similar to the one above, as used by the authors to successfully poison common DNS software.

How to detect DNS cache poisoning?

The user of a DNS cache has no way of knowing if it’s been poisoned. Only the administrator of the caching server could possibly detect such an attack. A common sign of a poisoning attempt is a large number of UDP packets flooding the DNS cache from random ports, all with similar content. An IPS/IDS system can easily detect such anomalous traffic and alert the administrator.

The only way for a user to notice that their DNS cache has been targeted for a DNS cache poisoning cyberattack is that when they try to connect to a well-known website or web application via HTTPS (SSL/TLS), their browser unexpectedly displays a warning that the SSL/TLS certificate is invalid. Attackers can combine DNS cache poisoning with other man-in-the-middle techniques such as SSL hijacking (then the warning is not displayed because the fake CA confirms the certificate as valid) or SSL stripping (then the warning is not displayed because the browser uses HTTP), but if they don’t, and the warning appears, it should never be ignored, and you should never connect to the website. To check whether you are indeed dealing with DNS cache poisoning and a malicious website, change your DNS cache in your operating system configuration and see if the error persists when using a different cache.

How to prevent DNS cache poisoning?

DNS cache poisoning attacks are not easy to perform, but they are feasible. All current defense methods against this attack vector make attacks more difficult but not impossible. The only complete solution would be to globally replace DNS with DNSSEC (Domain Name System Security Extensions), which is a protocol proposed in 2005 that uses public-key cryptography and end-to-end encryption for DNS data. While DNSSEC is slowly gaining traction, the complexity of the infrastructure makes the transition process slow, and most clients still use the regular DNS protocol.

As an administrator of a website, web application, or even a web server, you cannot do much to prevent DNS cache poisoning attacks that affect your apps and other assets. However, as a web server administrator, you may also be the owner of its domain and store its IP information in an authoritative nameserver. There are two approaches that businesses use: they can either host their own authoritative DNS servers or use service providers to host them.

Since DNS poisoning attacks rely on the attacker delivering a fake response before an authoritative nameserver can provide its legitimate response, nameservers hosted by major service providers are safer than self-hosted ones. Quite simply, big service providers have the infrastructure needed to mitigate potential denial of service attacks intended to slow down nameserver responses. If you want to prevent DNS cache poisoning attacks against your domain, you are better off using a major service provider (such as Azure DNS, Cloudflare DNS, Amazon Route 53, Google Cloud DNS or others) to host your DNS information than trying to do it on your own.

Another glimmer of hope lies in the increasing adoption of DNS over HTTPS. Web browser vendors are slowly introducing this technology to force all DNS queries from the browser to be securely sent to one of the major DNS resolvers, no matter what the user configures in their operating system. While arguably better for security, this forced choice is a controversial issue in itself. The real answer is the global adoption of DNS security extensions, but this unfortunately introduces other risks and cannot be expected any time soon.

How to mitigate DNS cache poisoning?

In the case of client endpoints that access your website or web application, the burden of ensuring DNS security lies with the DNS caches they use. If, for example, the user or the administrator configures their Wi-Fi router to use a DNS resolver hosted by a small Internet service provider, that ISP’s DNS resolver may be more susceptible to even simple DNS cache poisoning attacks. Luckily, more and more are switching to major DNS resolvers such as the Google Public DNS (8.8.8.8 and 8.8.4.4) or the Cloudflare public DNS resolver (1.1.1.1). Such servers can be trusted to use robust DNS software and have most entries cached with high trust, making it difficult or impossible to overwrite them in caches, even when using advanced DNS cache poisoning attacks.

The most effective way to mitigate DNS cache poisoning consequences for your own web assets is to enforce HTTPS connections by employing HSTS. Even if a black-hat hacker poisons the DNS cache, they won’t have the original SSL certificate for your domain, so your users are more likely to spot that they are connected to a phishing website when their browser displays a warning. On the client side, a good option is to use a trusted VPN, where the DNS cache is configured on the VPN side and not on the local router.