{"id":218,"date":"2008-04-19T22:51:17","date_gmt":"2008-04-19T21:51:17","guid":{"rendered":"http:\/\/lendl.priv.at\/blog\/2008\/04\/19\/dns-what-to-do-if-the-sky-is-falling\/"},"modified":"2026-01-26T12:16:55","modified_gmt":"2026-01-26T11:16:55","slug":"dns-what-to-do-if-the-sky-is-falling","status":"publish","type":"post","link":"https:\/\/lendl.priv.at\/blog\/2008\/04\/19\/dns-what-to-do-if-the-sky-is-falling\/","title":{"rendered":"DNS: What to do if the sky is falling?"},"content":{"rendered":"

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<\/a>.<\/p>\n

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.<\/p>\n

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

If<\/strong> 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?<\/p>\n

There is a trivial solution: Redo the query a few times, preferably utilizing all authoritative servers.<\/p>\n

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<\/em> queries?<\/p>\n

n = 2: 0.01 % chance
\nn = 3: 0.0001 % chance
\n…<\/p>\n

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.<\/p>\n

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.<\/p>\n

What did I miss?<\/p>\n

[Update: 2008\/04\/22]<\/p>\n

After a chat with Klaus and Alex, two new thoughts on this:<\/p>\n