There’s been a lot of emphasis on DNS performance lately because faster DNS contributes directly to a better user experience. There’s an interesting flipside to DNS performance though, higher performance DNS servers may be better targets for cache poisoning attacks. Faster servers give attackers more opportunities to insert fake entries into the DNS—speed can kill (or at least inflict a nasty wound!) so it’s important to understand the security implications if you’re looking to upgrade DNS performance.

The probability of a successful cache poisoning attack can be calculated. Depending on the protections implemented in the server it can scale in proportion to the performance of the caching resolver because one of the variables in the numerator of the equation is the number of packets that can be sent per second by an attacker. Math aside this makes sense intuitively.

So is increasing the performance of DNS servers a bad idea?? Of course not! But it’s important to understand that DNS security has to be improved as server performance increases—otherwise you increase the exposure of your DNS servers.

At this point everyone in the industry has implemented basic features that randomize fields in DNS packets. For instance the TXID (Transaction ID) has been randomized for many, many years. This randomization makes it harder for attackers to guess the correct values, and thus harder to spoof a DNS answer.

For years most vendors didn’t pay any attention to DNS security until Dan Kaminsky ably demonstrated servers that only had TXID randomization were horribly exposed. With an unforeseen trick that he devised, Kaminsky showed even with modest links speeds randomized query IDs could be defeated quickly. Most of the industry rushed to respond; the solution was UDP Source Port Randomization (USPR). USPR provided more protection and once again the industry moved on. Rare commercial message: Nominum DNS servers were the only ones with multiple additional protections to deter the Kaminsky attack prior to it being revealed.

Meanwhile, networks are getting faster and server hardware and DNS SW continue to improve. Servers supporting many hundreds of thousands of recursive queries per second are becoming available. This higher performance is a Good Thing, but not at the expense of increased security exposure.

DNSSEC has been positioned as the solution to stop cache poisoning dead in its tracks and no one disputes it will. But despite substantial visibility and effort on the part of some vendors to simplify its deployment, adoption of DNSSEC has been painfully slow, even for extremely popular, “high value” web resources. And the (very) long tail of other web sites will probably never adopt DNSSEC, yet they need better protection too.

So what else can be done to improve DNS security? Randomization can play even more of a role, a draft RFC was circulated that showed how the case of query names could be randomized to provide more protection: www.nominum.com becomes WwW.NOmiNUm.cOM. Each letter adds another bit of protection—kinda cool huh?? Even short names can get better protection, and properly implemented old authoritative servers that can’t mirror back the randomized case in their query response can easily be accommodated. Makes you wonder why so few vendors have chosen to implement it.

Another simple trick can massively frustrate attackers. Mismatched query responses from authoritative servers (which may indicate a cache poisoning attempt) can trigger a shift to TCP for the connection. This means an attacker gets one try to spoof a response, rather than hundreds or even thousands they might get on a high speed link. Again proper implementation can prevent this from becoming a vector for DoS attacks. Again scratch your head and wonder why most of the industry has not chosen to Just Do It. It’s hard, but most seasoned engineering teams thrive on solving hard problems.

Other security protections are more subtle. Screening query responses and segregating glue records so an attacker cannot use them to insert a fake domain into the cache is an extremely effective deterrent. Implementing a capability like this is more or less difficult depending on the underlying design of the code—but it’s been years so what’s the excuse?

DNS performance is a critical part of the subscriber experience: faster DNS = faster network. New network architectures (cloud, regional DNS) and continued rapid growth in DNS queries are driving network operators to implement faster DNS servers. But security upgrades must go hand in hand with performance upgrades because faster DNS servers are more vulnerable to cache poisoning attacks. DNSSEC will help when it becomes mainstream; but it’s going to be a long time. It’s worth asking your DNS software (or appliance) vendor what they can do for you now.