> From: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= <[email protected]> > To: Paul Vixie <[email protected]> > Cc: DNS Operations List <[email protected]>
> > For example, if the authoritative provider www.example.com were to > > implement RRL as you describe, then an attacker could spoof traffic > > purporting to be from Google Public DNS, OpenDNS, Comcast ... etc, and > > cause www.example.com to be un-resolvable by users of those resolvers. > > > > no. it just does not work that way. > > O.k., so say I spoof 10M UDP queries per second and 10M TCP SYNs per second > purporting to be from OpenDNS's IP address. Does RRL a) Let the queries > and SYNs go answered. Or b) Rate limit the responses? > > If it's (a) RRL doesn't prevent the reflection. If it's (b) then you > complete a denial of service attack against the OpenDNS users. > > Which is it? or what's option (c)? I think one option (c) (there might be others) is related to what Paul Vixie meant when he wrote: ] The more common case will be like DNS RRL, where deep knowledge ] of the protocol is necessary for a correctly engineered rate-limiting ] solution applicable to the protocol in http://queue.acm.org/detail.cfm?id=2578510 I've written too many times here and elsewhere that DNS RRL is not a naive firewall rate limit. Simplistic firewall rate limiting against DNS reflections is little better than blocking all ICMP on "security" grounds. That is why DNS RRL is in the DNS code instead of firewalls. That's also why there are two R's in RRL. There are plenty of words in the documentation, technical reports, and analyses of the various RRL implementations about RRL false positives. There is disagreement about the best values for the parameters that minimize RRL false positives, but we who have the least interest in the topic agree that neither option (a) nor option (b) fit. Vernon Schryver [email protected] _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
