This is a discussion on Re: resolver side mitigation - DNS ; * W. C. A. Wijngaards: > I've submitted a draft with the resolver side mitigations that I > envision for Unbound. > > http://www.ietf.org/internet-drafts/...resolver-side= -mitigation-00.txt I think RTT banding with 200 ms does not work that well if the attacker ...
* W. C. A. Wijngaards:
> I've submitted a draft with the resolver side mitigations that I
> envision for Unbound.
I think RTT banding with 200 ms does not work that well if the
attacker is less than 200 ms away from the resolver which is attacked:
Suppose that NS1 has got a RTT of 20 ms, and NS2 one of 220 ms, and
the attacker is very close to the resolver (negligible RTT). The
attacker sends a query to the resolver, initially spoofing responses
from both resolvers. If no answer is received within 20 ms, it
concentrates spoofing on the other resolver. As a result, the
necessary attack bandwidth has been reduced, leading to a better
In the end, the question whether RTT banding is useful boils down to
how we measure attack costs. Without proper cost metrics, it's hard
to tell if a countermeasure is a real improvement (and how it
interacts with other resolver features like lameness caches).
Section 3.3 could mention that these techniques stop query mining
attacks on DNSSEC (because an off-path attacker cannot proxy DNSSEC
traffic anymore). The downside is that when you detect a failure
(even if it's just a timeout), you need to back up, maybe even back to
the root, in order to get a fresh version of the data you've just
invalidated. (I don't think this should be a priority item, though.)
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstra=DFe 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.