How DNS Cache Poisoning Attacks Work

DNS cache poisoning attacks try to fool applications into connecting to a malicious IP address by flooding a DNS resolver cache with fake addresses corresponding to requested domain names. Due to the way DNS works, if the attacker succeeds in filling the cache with false data, the resolver might return a spoofed address instead of querying for the real one. As a result, the user might connect to a malicious site at the address returned from the cache. While relatively difficult to perform, such DNS spoofing attacks can’t be completely prevented with current web technologies, making them a dangerous tool in the hands of cybercriminals.

DNS Caching: Insecure by Design

The Domain Name System (DNS) provides a hierarchical, distributed directory service for mapping Internet domain names to addresses. DNS is a fundamental part of Internet infrastructure, but also one of the oldest Internet protocols still in use. In fact, DNS dates right back RFC 882 and RFC 883 from 1983, where the very concept of domain names for ARPANET was first proposed. The decentralized design of DNS introduced a hierarchical query structure combined with multiple levels of caching to speed up request processing. 

Security, however, was not a vital consideration in the nascent Internet. DNS was designed to be as simple and efficient as possible in a limited environment of trusted actors communicating over slow links with infrequent domain name updates. Today, with public access to the Internet on a massive scale, the domain name system is fundamentally vulnerable. The original protocol did not protect against spoofing, and while RFC 5452 (Measures for Making DNS More Resilient against Forged Answers) did introduce some protection, DNS still provides no privacy controls. DNS communication is usually sent unencrypted in UDP packets without any authentication (unless DNSSEC is enabled for authentication), making it relatively easy to spoof DNS responses. TCP is also used for some tasks, and some resolver implementations require TCP for all DNS communications. 

How Domain Name Resolution Works

Domain name information is ultimately stored in DNS entries on authoritative nameservers for specific domains. To decentralize this information, DNS server responses are cached by intermediate resolvers in the DNS hierarchy. The caching period is determined by the TTL (Time-To-Live) parameter set in the response. Until that time elapses, a nameserver will answer DNS requests for a given domain name using the cached information, without escalating the query up the hierarchy.

For instance, if you enter www.example.com in your web browser, the operating system will query its configured resolver for the IP address for that domain. If the resolver has the query in its cache, it will respond directly. Otherwise, the query is sent to one of the root name servers, which may respond directly or refer the resolver to a more authoritative server for the .com domain. This is continued for subsequent servers until an IP address is finally received.

Because DNS is a distributed system, resolving a query usually requires communication between servers. To provide some level of protection against spoofing, valid responses sent between servers must meet three basic requirements:

• The response must include the unique transaction ID (TXID) sent in the query.
• The response must come from the IP address the query was sent to.
• The response must be sent to the UDP port the query was sent from (initially this was always port 53, now port randomization is used).

DNS Spoofing

DNS spoofing attacks exploit the extensive reliance on cached data for domain name resolution. They work by filling (poisoning) the resolver cache with false DNS information in the hope that it will be sent as valid responses to requesting clients. Two main attack approaches are described below. For a detailed technical description of DNS poisoning attacks against three popular DNS server implementations, see The Hitchhiker’s Guide to DNS Cache Poisoning.

Basic Cache Poisoning

The simplest DNS poisoning attack starts with the attacker sending a query to the targeted resolver, asking for the address of the domain they want to spoof. Assuming the domain is not already cached, the resolver begins its cycle of queries in the DNS hierarchy.

Before a valid reply can arrive, the attacker bombards the resolver with spoofed responses containing false DNS information for the domain. As noted above, to be accepted as valid communication from the relevant authoritative server, responses must use the right IP address, UDP port, and transaction ID. The attacker can spoof the IP address, but the port and transaction ID must be brute-forced by sending responses with all possible combinations of these values. For the attack to succeed, the attacker must find an accepted combination before an answer arrives from the legitimate server, so such attempts would usually be accompanied by a denial-of-service attack (DoS) to delay the response. 

This basic poisoning attack is only feasible if the domain is not already cached, so it usually won’t work for popular domains that make the most attractive targets. While it may be possible to overwrite cached DNS records, this requires a separate attack against a specific resolver implementation.

Advanced Cache Poisoning Using Additional Information

Another, more advanced kind of attack uses additional information in DNS responses to trick the resolver into treating the attacker’s machine as the authoritative nameserver. The attack starts in a similar way to the basic example above, but the attacker deliberately asks for a non-existent subdomain, forcing the resolver to search in vain for an authoritative server. The spoofed responses contain additional information, pretending to be from servers that don’t have the answer but indicate the attacker’s IP address as the authoritative server for the main domain.

If successful, this attack can set the stage for further spoofing, as the victim’s resolver now treats the attacker’s machine as the authoritative DNS server for this domain, potentially replacing the valid one in its cache. Whether this works depends on the level of trust in the original cache entry – answers received directly are more trusted than additional information, so this is more likely to work for subdomains than widely known major domains.

Dealing with the DNS Poisoning Threat

Domain name resolution is a crucial part of the inner workings of the Internet, so any successful attack can exploit the user’s trust in a known domain to install malware, perform phishing, set up man-in-the-middle attacks, and so on. Unfortunately, because DNS is fundamentally insecure, there is no universal protection from all cache poisoning attack vectors. However, some mitigation is possible until more secure name resolution protocols are adopted.

Cache poisoning relies on the attacker delaying DNS server responses, so using a fast and DoS-resistant DNS resolver can go a long way towards preventing successful attacks. For end-users, this means it is much safer to use a secure DNS server run by a major internet service provider, such as Google’s public DNS at 8.8.8.8 and 8.8.4.4 or Cloudflare’s public DNS resolver at 1.1.1.1. Such big-name providers have the technical know-how and resources to securely configure DNS and absorb even large-scale DoS attempts. By contrast, smaller service providers or organizations than run their own DNS servers are less resilient, and thus more susceptible to DNS poisoning.

While port randomization, packet flood detection, and other practices recommended in RFC 5452 have made DNS spoofing much harder, it remains a viable threat until more secure technologies are adopted. Currently in the news is the planned adoption of DNS over HTTPS (DoH), already backed by the likes of Google, Microsoft, and Mozilla. This will encapsulate the current DNS protocol inside secure HTTPS communication and enforce the use of major DNS resolvers. While DoH is controversial for many reasons, it currently seems the most practical way to bring security and privacy to DNS for the general public. To include security features in the protocol itself, DNSSEC is also being gradually adopted by major ISPs.