Cache is a critical component of the overall DNS infrastructure. Various components in the hierarchy of DNS maintain their own cache to avoid reaching out to the other servers all the time. Once a nameserver receives a response, it stores in its cache for some time (TTL) so that further queries for the matching domain are served from the cache. Not only it reduces the DNS traffic but also makes the process of resolution more efficient. At the same time it introduces some risks for attack – what if someone is able to manipulate the cache with the records pointing to the address of attacker’s choice? The answer is obvious; attacker if successful in doing this can divert a lot of traffic to the sites that he controls and use it to not only collect sensitive information but also to spread malwares. 

But how can caches can be poisoned? The trick here is to fool the requestor of a DNS query into accepting a wrong response. Whenever a nameserver sends out a query to another nameserver, it expects an answer back and when the answer arrives, it does the following checks to ensure that the response matches the query: 

  • Query ID (16 bit identifier for the request) in response matches the one sent out in request
  • Response arrives on the same UDP port which was used for sending the request
  • Question section in the response matches the question of the sent query
  • Additional information in the response belongs to the same domain that was queried 

Of course an attacker must get all this right in his fake response to be successful in his attack. Unfortunately with naïve nameservers it may not be very difficult e.g. with some of the older implementations Query ID is sequentially incremented for every new query sent. If attacker gets to know a Query ID, he can make good guesses for future queries. Also, some implementations used same source port for all the queries – so no guesses required here. 

Attacker starts the game by sending a query for a domain name, that it wants to hijack, to the nameserver it wants to poison. Knowing that the nameserver will soon reach out to external nameservers for resolution, attacker starts flooding the nameserver with forged responses. Nameservers are designed to accept the first valid response – and rests of the responses are ignored. Chances of attacker’s valid looking response reaching the nameserver can be high if attacker is able to generate responses at a faster pace and knows a good starting point. 

How can we make it tough for attacker to be successful in his pursuit?

  • Query ID Randomization – By randomizing the processes of generating Query ID, attacker will be left guessing on what will be the next one.
  • Source Port Randomization – Since Query ID is just 16 bit, there are only 65K possible values. Attacker still has a good chance of matching a Query ID by generating responses at a fairly fast rate. If source port is also randomized, attacker has to deal with 4 billion possible values – now that’s some effort! 

At NetScaler we provide host of protections against DNS attacks including Query ID and Source Port randomization! Safe Internet!!