Colm MacCárthaigh wrote: > > Your article mentions RRL and asymmetric threats, but does not > mention that RRL opens the implementor up to a new asymmetric threat. > With RRL, an attacker can spoof legitimate clients and cause the RRL > implementation to deny them service.
no. > > For example, if the authoritative provider www.example.com > <http://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 > <http://www.example.com> to be un-resolvable by users of those > resolvers. no. it just does not work that way. > > The more widely RRL is applied to more protocols and schemes, the more > they are vulnerable to this same simple counter-attack. It seems like > setting the internet up with a brittle component that may ultimately > makes spoofing-based denial of service easier, not harder. This > creates additional risk on the implementor at very little benefit to > themselves, which still seems asymmetric. dns rrl is a protocol-specific approach to rate limiting, for dns, based on responses. as i said in the ACM Queue article, every protocol we want to rate limit is going to need a protocol-specific, protocol-aware method of rate limiting. we must not create new vulnerabilities as a side effect of closing old ones. vixie
_______________________________________________ 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
