>I meant this to be in response to Ben's concern about potential malicious use, > in which case 99% idling and other normal-use scenarios don't seem to be appl >icable.
The point of dry-run is to get a statistical sample of failures. If all of those mostly idle resolver can validate the domain, then it is a good signal that things are probably fine. For busy resolvers, the operator can either run a few instances with dry-run enabled with a lower query rate. Or have a system where dry-run gets disabled during an attack. >Rather, the work bounds are there especially to limit malicious use. Why would > a resolver want to expend twice the resources, in comparison to what they had > decided would be the maximum they would want to spend, just because the (mali >cious) DS record has a dry-run entry? Given that the resolver is doing DNSSEC validation, we can assume that the operator cares about the deployment of DNSSEC in one way or another. So helping out with dry-run is a benefit if it doesn't cost too much. Large scale DNSSEC failures are costly. It is likely that when a popular domain fails to resolve, people are first going to look at their local ISP. Who then has to insert a negative trust anchor. If dry-run can avoid most of that, it is a clear win. Somehow, you seems to be under the impression that 'twice the resources' is a significant amount. I think that compared to the endless DoS possibilities that DNS offers, this is not that significant. _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
