* 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=


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.)

Florian Weimer
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 namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.