[dns-operations] Does residential ISPs do rate limit on their local resolvers?

[Xun Fan]

________________________________
From: dns-operations <dns-operations-bounces at dns-oarc.net> on behalf of Florian Weimer <fweimer at redhat.com>
Sent: Monday, October 24, 2016 5:09 AM
To: dns-operations at dns-oarc.net
Subject: Re: [dns-operations] Does residential ISPs do rate limit on their local resolvers?

On 10/22/2016 06:27 PM, Paul Vixie wrote:
>
>
> Robert Martin-Legene wrote:
>> I think RRL does not really work so well in this case. It would force
>> the client to TCP. But then on TCP the client could ask for any random
>> string from a victim-zone. A string that the resolver would try to resolve.
>
> i think you should build a test network out of a bunch of VM's and find
> out what difference RRL makes in practice against an attack like this.
> the urban legend of "would force the client to TCP" isn't supported by
> theory and likely won't be supported by practice, either. RRL has three
> things it can do when it decides that a query is a duplicate. only one
> involves TC=1. the combination of all three yields systemic attenuation.

What happens to the recursor with typical RRL deployments on the server
side?

Is the goal to take out the recursor as completely as possible, so that
its operator is forced to disconnect the client that is spewing garbage
queries?

I could imagine under a huge tough attack, the authoritative operator may want to "take out the
recursor as completely as possible" if the recursor is "spewing garbage queries". But the motivation
behind that is they want to serve the other recursors that carries no attack queries.
If they don't do this, they may end up with taking out all recursors almost completely and no users can
be served at all...


Thanks,
Florian

_______________________________________________
dns-operations mailing list
dns-operations at lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-operations mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20161024/70b3d846/attachment.html>