CERT has issued an advisory, short on details about the exact nature of the problem, about a fundamental flaw in the DNS protocol which allows an attacker to poison a DNS cache. Working with the person who found the flaw, Dan Kaminsky, CERT notified vendors of the problem and is coordinating a publication of the patch. If you run a DNS server, check with your vendor to see if a patch is available.But while Kaminsky admits that DNSSEC would have prevented the problem, edifying to me, to say the least, rolling out DNSSEC is not going to be a near-term fix.

One of the main functions of DNS is to convert names like www.example.com into IP addresses and vice versa. DNS can do much more. For example, you configure DNS to tell other systems where your mail server is located and Active Directory makes extensive use of DNS to tell Windows hosts where critical services are located.

When a user types in a host name like www.example.com, if their computer doesn't know what IP address is tied to the host name, it will send the request to the DNS server it is configured to use. That name server, if it doesn't know the IP addresses associated with www.example.com, will initiate a search for the IP address. This is a process called recursive query.

Once your DNS server has the response, or DNS record, it sends it back to the client that made the request. Rather than make the same request for a host name each time a user asks, the computer and the DNS server will cache the DNS record locally so it doesn't have to make subsequent requests. On your computer, that means once your computer gets a response to a query, it won't have to ask again. At the DNS server, called a recursive or caching DNS server, it will respond to any query for www.example.com from its local cache, thereby reducing traffic and queries from multiple users. DNS records have time-to-live values, TTL, that tell the DNS client and DNS server how long to keep a DNS record in the cache before starting a new request. The TTL lets you change the IP addresses of hosts.

DNS cache poisoning is, as the name implies, an event where an attacker inserts a bogus DNS record into a caching name server to redirect users from a legitimate IP address to one controlled by the attacker. For example, let's say you want to go to www.example.com whose IP address is 192.168.1.10. You type in www.example.com into your browser, it asks the operating system to resolve the name to an IP address. If the DNS record is not in the local cache, it sends the request to a DNS server, which continues the request process. If an attacker knows that you are looking for www.example.com and can respond with a DNS record which maps the hostname to a server the attacker controls, say 10.1.1.10, then your computer will connect to the attacker's server rather than the actual server. DNS cache poisoning can be used for man-in-the-middle attacks.

To protect against trivial DNS cache poisoning, each request has a transaction ID that should be a randomly selected number. The response to a DNS request must have a matching transaction ID. In addition, the DNS request, which uses UDP as a transport, selects a source port number when making a recursive request. Assuming that the attacker can not see the actual DNS request, he will have to guess the transaction ID and the source port number that DNS server used to spoof a response.

There are a couple of problems with the DNS protocol and how it is implemented. First, the transaction ID is only 16 bits long, a relatively small number, and there are documented cases where vendors and DNS server developers didn't sufficiently randomize the transaction ID, leading an attacker to guess the next one. Another vulnerability is that some DNS servers allowed multiple requests to be simultaneously open, each with a unique transaction ID, which allows the attacker to send back multiple spoofed responses, hoping to match a transaction ID. Finally, some DNS servers either used the same UDP source port for all DNS queries or the operating system allocated source ports sequentially, allowing an attacker to guess the next source port.

Apparently Kaminsky found a way to initiate cache poisoning despite the known vulnerabilities listed above that should have been addressed. He will be releasing the details on Aug. 6 at Black Hat, but he participated in an informative podcast where he explains the impacts and what he thinks you need to know. He does not release the details, however. His recommendation is that if your DNS server can resolve domain names from the Internet, patch the system and patch DNS clients, like your workstations. Remember, too, lots of products, like routers, switches, and print servers, also are DNS clients.