Build Your Defences Against DNS Cache Poisoning Attacks

Read time: 3 minutes, 44 seconds

The Domain Name System (DNS) is one of the best-known protocols on the Internet. Its main function is to translate human-readable domain names into their corresponding IP addresses. It is important as all devices on the Internet derive the IP address of a particular server from the DNS regularly. The translation process through which DNS queries are exchanged between the client and the DNS server or the resolver. DNS tree is architected from the top down and is called “DNS Hierarchy, “depicted in Fig. 1.

There are two types of DNS resolvers

• Authoritative

  Authoritative name servers give answers in response to queries about IP addresses. They only respond to queries about domains to be configured to respond.

• Recursive

  Recursive resolvers provide the proper IP address requested by the client. They do the translation process by themselves and return the final response to the client.

In this article, we will be focusing on the second type, recursive DNS resolvers.

DNS Cache Poisoning Attacks

Classic DNS cache poisoning attacks (around 2008) targeted a DNS resolver by having an off-path attacker fooling a vulnerable DNS resolver into issuing a query to an upstream authoritative name server.

The attacker attempts to inject negative responses with the spoofed IP of the name server. If the rogue response arrives before any legitimate ones which matches the “secrets” in the query, then the resolver will accept and cache the rogue results.

The attacker would also need to guess the correct source/destination IP, source/destination port, and the query’s transaction ID (TxID), which is 16-bit long. When the source and destination port (i.e., 53) were fixed, 16-bit was the only randomness. Thus an off-path attacker can brute force all possible values with 65,536 responses, and a few optimizations such as birthday attacks that can speed the attack even further.

Defenses against DNS Cache Poisoning attacks

Since then, several defenses have been promoted to mitigate the threat of DNS cache poisoning. They effectively render the classic attack useless. We describe below the solutions deployed which includes randomization of:

1. The source port is perhaps the most effective and widely deployed defense as this increases the randomness to 32 bits from 16 bits. An off-path attacker would now have to guess both the source port and Transaction ID (TxID) together.

2. Capitalization of letters in domain names (0x20 encoding) – The randomness can often depend on the number of letters, which can be quite effective, especially for longer domain names. It is a simple protocol change, but it has significant compatibility issues with authoritative name servers. Thus, the most popular public resolvers do not use 0x20 encoding. For example, Google DNS uses 0x20 encoding only for allowed name servers; Cloudflare has recently disabled 0x20 encoding.

3. Choices of name servers(server IP addresses). Randomness also depends on the number of name servers. Most domains utilize less than ten name servers, summarizing to only two to three bits. It has also been shown that an attacker can generate query failures against certain name servers and effectively “pin” a resolver to the one remaining name server.

4. DNSSEC – The success of DNSSEC depends on the support of both resolvers and authoritative name servers. But, only a small fraction of domains are signed – 0.7% (.com domains), 1% (.org domains), and 1.85% for Top Alexa 10K domains, as reported in 2017. In the same study, it is stated that only 12% of the resolvers enabling DNSSEC do attempt to validate the records received. Thus, the overall deployment rate of DNSSEC is far from satisfactory.

Conclusion

DNS Cache poisoning attack is ever-changing, with new attack surfaces appearing. As we previously stated, modern DNS infrastructure has multiple layers of caching. The client often initiates a query using an API to an OS stub resolver, a separate system process that maintains OS-wide DNS cache. Stub resolver does not perform any iterative queries; instead, it forwards the request to the next layer. A DNS forwarder also forwards queries to its upstream recursive resolver. DNS forwarders are commonly found in Wi-Fi routers (e.g., in a home), and they maintain a dedicated DNS cache. The recursive resolver does the real job of iteratively querying the authoritative name servers. The answers are then returned and cached in each layer. All layers of caches are technically subject to the DNS cache poisoning attack. But we generally tend to ignore stub resolvers and forwarders, which are also equally susceptible to attacks. As the industry moves forward, we should be better prepared for such attacks and have better defenses accordingly.