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.
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. 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. On Thu, Feb 6, 2014 at 9:53 AM, Paul Vixie <[email protected]> wrote: > my latest bcp38 related effort was published in ACM Queue today: > > http://queue.acm.org/detail.cfm?id=2578510 > > 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 > -- Colm
_______________________________________________ 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
