DNS: What to do if the sky is falling?

Having been treated to another iteration of “we need to deploy DNSSEC, otherwise DNS will fall apart due to rampant forgeries” talk recently, I started to think what other options resolvers have to protect themselves. See also bert’s draft.

First of all, is it possible to implement a successful forgery attack without the client noticing that anything is wrong? IMHO not. Most scenarios assume that the attacker sends a burst of forged replies to the recursor in the hope of hitting the right query-ID before the real answer arrives. So, even with a successful attack a lot of answers with mis-matched ID will arrive (and be rejected) before the forgery actually succeeds.

This spike in ID mismatches towards a query should tell the recursor that something fishy is going on. TODO: Instrument bind/powerdns/… to actually log such ID mismatches.

If this works, then the 99.9999% percent of normal DNS lookups which are not targetted by a forgery attack can continue without modification. The only question now is: what can a resolver do if he has a clear suspicion that he is the target of a DNS forgery attack?

There is a trivial solution: Redo the query a few times, preferably utilizing all authoritative servers.

Let’s do some simple math: assume that the forger has a 1% chance of a successful spoofing attack. What are his chances if the recursor only accepts the answer if he got the same data from n queries?

n = 2: 0.01 % chance
n = 3: 0.0001 % chance

That doesn’t sound so bad, does it? The downsides sound rather minimal: no impact on queries which are not target of an attack, a few more requests during an attack and a slight delay (sequentially querying! You can’t do that in parallel.) before answering back to the client.

A few optimizations come to mind: Bert’s draft mentions a few other options, e.g. source port (or even IP address) variability. These come with some added cost, so perhaps they could be utilized just for these cases.

What did I miss?

[Update: 2008/04/22]

After a chat with Klaus and Alex, two new thoughts on this:

  • There might be legitimate cases where multiple queries might give varying results. E.g. global load-balancing like Akamai or This might break the “ask multiple times and check for consistency” idea.
  • Another option is the following: if a forgery attack is detected, simply switch to TCP for this query / target nameserver.