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?
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 www.google.com. 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.