DNS Issues

Kaminsky DNS attack

In July 2008 Dan Kaminsy went public with a DNS design flaw and a temporary fix for it. See this or Google for "Kaminsky DNS". Basically, the problem was that an attacker could guess the parameters needed to forge a DNS answer and get their answer accepted by your DNS server. The temporary fix for this is to add randomness to the port numbers used by your recursive DNS server when it sends queries to other authoritative DNS servers. The permanent fix is DNSSEC - see below.

Although this was almost 6 years ago, there are still a LOT of DNS servers that have not been hardened against this attack. Many of you are clearly still running vulnerable DNS servers, or you are running a modern DNS server behind a firewall that is changing the source port on your udp DNS queries. Please test and fix that.

Open recursive resolvers

Almost everyone running an internet visible mail server is familiar with the reasons they should not be running an open mail relay. But many people running internet visible DNS servers apparently have not received the message that running an open recursive resolver is also bad for many of the same reasons that open relays are bad. Are your DNS servers also open recursive resolvers? See this for reasons why you should restrict recursion.


The real solution to the Kaminsky attack is DNSSEC, which also prevents other malicious DNS operators from successfully lying to their customers about your domain names. Do your DNS servers have dnssec checking enabled? Have you digitally signed the public zones for which your DNS servers are authoritative?

Response Rate Limiting

So your DNS server is properly using random source ports on outgoing queries, your firewall is not destroying that randomness by modifying those port numbers, you have restricted recursion to your own clients, and you are signing your zones with DNSSEC. Are you done? Not quite yet. Various ongoing attacks used forged udp DNS packets to get your DNS server to send a larger packet toward the victim. Since your zones are signed with DNSSEC, those responses are now significantly larger than before.

Response rate limiting is one method to mitigate the harm caused when some attacker uses your authoritative DNS server to amplify their attack.

Response Policy Zones

Almost any network will be running some form of spam control on the inbound mail servers, but some spam will inevitably leak thru to your customers. Much of this spam will be some variation of the "click here to be infected" variety, where the message body includes some URL, and the customer ends up clicking on that link.

If the URL includes a numeric ip address rather than a host name, it is much more likely to be rejected by your spam defenses. Most of those malicious URLs contain normal host names, and there are lists of such evil host names available on the net. If you knew that the name was evil when the spam arrived, your spam defenses could simply reject the message. We are concerned here with the case where the name is not known to be evil when the message is received by the mail server, but the name is known to be evil when the user clicks on the link many hours later.

You can use the rpz feature of Bind to setup one zone which controls and modifies the answers that you return to your customers. Using rpz, you can redirect the web click from the user to an internal web page containing content of your choice.