How to Secure Your Network from Kaminsky's DNS Cache Poisoning Flaw

The seriousness of the recent DNS cache poisoning vulnerability, discovered by security researcher Dan Kaminsky, raises the bar for network security administrators and should provoke development of a comprehensive plan to address this insidious threat. Every enterprise has a caching DNS server and is thus a target of the Kaminsky DNS cache poisoning flaw.

A Kaminsky DNS cache poisoning attack consists of two steps:

Step No. 1: The attacker sends fake DNS queries, or questions, to internal caching DNS servers. These queries are for domains that the caching server will not have cached, so it will have to generate subsequent queries to authoritative servers on the Internet.

Step No. 2: The attacker then sends a barrage of fake answers to each fake question, attempting to spoof the answer from the authoritative server. To succeed, the attacker has to correctly guess various query parameters—such as Transaction ID and User Datagram Protocol (UDP) source port—before a valid response from the legitimate authoritative server reaches the caching DNS server. There are some additional technical details about the fake answer that will be discussed later in this article.

If the attacker succeeds in getting his or her fake answer accepted by the caching DNS server, the consequences are quite serious. The poisoned DNS entry can be used to redirect Web traffic, e-mail or any other IP application to a malicious server controlled by an attacker.  Since the DNS points users to their destinations, it is completely unaware that the traffic is being diverted.

Protecting against the Kaminsky attack

As with any security vulnerability, the best approach for protecting against the Kaminsky attack is to employ multiple defenses. In this case, traditional firewalls and intrusion prevention systems (IPS) can be part of the solution, providing an initial defensive shield that will reduce the number of fake DNS query requests and responses.

But most firewalls and IPS will not stop a fake DNS response from poisoning the DNS cache if the DNS query parameters match. This means it is a primary consideration to ensure that the DNS server itself employs the best possible defenses. Put another way, DNS security starts with the DNS server.