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 receive such fake data. It can be used for very effective phishing attacks (often called pharming) and to spread malware. It can also be used in man-in-the-middle attacks – the attacker may connect to the legitimate server in the background and simply eavesdrop on communication.

Such attacks are not easy to perform but they are feasible. All current defense methods against this attack vector simply make it more difficult but not impossible. The only ultimate resolution is to globally replace DNS with DNSSEC (Domain Name System Security Extensions), which is a protocol proposed in 2005 that uses public-key cryptography. However, due to the complexity of the infrastructure, it is still far from completion and most clients still use the regular DNS protocol.

How the Domain Name System Works

The DNS protocol is one of the oldest protocols of the Internet. Its first specifications, RFC 882 and RFC 883, were published in November 1983. At that time, the Internet was a network used by academic institutions and there were no reasons to worry about the security of the protocol. Therefore, DNS was created to be as simple as possible, which is why it is easy to fool.

The DNS system is based on iterative and recursive DNS requests also called queries. Each Internet client has a configured DNS resolver 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 has no relevant DNS information cached:

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. The 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 can tell you that the authoritative 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 can tell you that 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 may either also be the authoritative nameserver for something.example.com or it may further redirect the DNS resolver to another server, and the process may continue.

Each of the answers received as seen above comes with a TTL (time-to-live) value which instructs the DNS resolver to cache the response for some time. Such 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 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 key DNS records that we are focusing on is the basic A record used for most cases and the NS record that 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 the fact that DNS servers usually communicate using the UDP protocol. This means that 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.

There are three basic facts that make forging a response more difficult:

• Every query is sent with a transaction ID (TXID). 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 third item above 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 waits for queries on port 53 but it can send responses from any port:

1. The ns.example.com server waits 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 sends a response from its port 53 to your DNS resolver at port 12345.

Simple DNS Cache Poisoning

The basic flow of a DNS spoofing attack is as follows. Let us say that you use 1.2.3.4 as your DNS resolver and the attacker wants to inject false data for www.example.com into its cache. For a simple attack, we must assume that 1.2.3.4 was not asked about www.example.com for some time and therefore has no data about it in its cache.

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

This attack succeeds only if the attacker is faster than the authoritative nameserver. For this to be possible, the attacker must have a lot of resources (to send a lot of UDP packets very quickly) and the authoritative nameserver must be slow. In such cases, attackers often perform a denial of service attack on the authoritative nameserver to slow down its answer.

While such simple DNS cache poisoning is possible, it is very impractical because the attacker usually wants to poison a very common domain, which is often already cached in the DNS resolver. The DNS resolver will not accept any data that is already cached. However, there is a way to overwrite existing cached data. This, however, often depends on the DNS resolver implementation, therefore the attacker must know what DNS server software is used at 1.2.3.4.

Advanced DNS Cache Poisoning

Advanced DNS poisoning attacks use the fact that a DNS response may contain additional information, which is used in queries. When a DNS resolver asks another DNS server for some information, it may receive an answer that simply 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 with our example above:

1. The attacker sends a query to the 1.2.3.4 DNS resolver asking about the IP address of something12345.example.com, knowing that something12345.example.com does not exist.
2. The 1.2.3.4 DNS resolver does not have data in its cache for the nonexistent domain, so it attempts to ask the authoritative nameserver of example.com about it. The real answer would 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 1.2.3.4 DNS resolver now may think that the authoritative nameserver for example.com is www.example.com and that its IP address is an address controlled by the attacker (12.34.56.78). This further simplifies more attacks because the attacker’s server is now perceived as an authoritative nameserver and is therefore asked first about all the subdomains of example.com.

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

Luckily, the DNS resolver takes the data from the additional section and replaces existing data for www.example.com only in some cases: it depends on a level of trust with which the existing data was stored. DNS resolvers assign trust levels depending on how and from where 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. Therefore, for major domains, this may not work. However, it may work for subdomains, which are often provided originally using 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 above that the authors used to successfully poison common DNS software.

How To Secure DNS Servers

As an owner of a website or a web application, you cannot do anything to secure them against DNS cache poisoning. However, in such a case you are also often the owner of the domain and you store its IP information in an authoritative nameserver. There are two approaches that businesses use: they either host their own authoritative DNS servers or use service providers to host them.

Since such DNS spoofing attacks rely on the fact that the attacker must provide a fake response before the authoritative nameserver provides its legitimate response, nameservers hosted by major service providers are safer than self-hosted ones. Such service providers simply have the infrastructure needed to mitigate potential denial of service attacks that are meant to slow down the nameserver response.

The burden of DNS security, in this case, lies with DNS caching and therefore with users. If, for example, the user configures a DNS resolver that belongs to a small Internet service provider, such a DNS resolver may be more susceptible to even simple DNS cache poisoning attacks. Luckily, more and more users 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 replace them using even advanced DNS cache poisoning attacks.

Another glimmer of hope lies in the increasing adoption of DNS over HTTPS. Web browser manufacturers are slowly introducing this technology, which will force all DNS queries from the browser to be securely sent to major DNS resolvers mentioned above, no matter what the user configures in their operating system. However, the real answer is the global adoption of DNSSEC, which unfortunately introduces other risks and cannot be expected any time soon.

To ease your mind, you should remember that as we mentioned at the beginning, DNS cache poisoning is not easy to perform and therefore not common. Additionally, if your website or web application always uses HTTPS (for example, by employing HSTS) it provides an extra layer of security. Even if the attacker poisons the DNS cache, they won’t have the original SSL certificate for your domain and therefore your users will most likely spot that the page that they connect to is illegitimate.

THE AUTHOR

Tomasz Andrzej Nidecki
Principal Cybersecurity Writer
LinkedIn

Tomasz Andrzej Nidecki (also known as tonid) is a Primary Cybersecurity Writer at Invicti, focusing on Acunetix. A journalist, translator, and technical writer with 25 years of IT experience, Tomasz has been the Managing Editor of the hakin9 IT Security magazine in its early years and used to run a major technical blog dedicated to email security.