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

[Robert Martin-Legene]

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.

RRL mostly saves us from spoofed sender addresses.

On Sat, 22 Oct 2016 13:05 Paul Vixie, <paul at redbarn.org> wrote:

>
>
> Xun Fan wrote:
> > ...
> >
> > In addition, [Mirai] can also cause damage on the authoritative name
> servers
> > if the attack is targeting a specific domain.
>
> that attack mode is why DNS RRL uses the closest enclosing SOA RR as its
> NXDOMAIN bucket-holder. that is, random subdomain attacks are counted
> (and NXDOMAIN-limited) per zone-cut not per-qname.
>
> >
> >
> > So just out of curiosity, is it prevailing that the residential ISPs do
> > rate limit on their local resolvers (per source preferably) ?
> >
> > Public DNS resolvers seem to do that, i.e. 8.8.8.8, but it will be
> > helpful if ISPs do it too.
>
> rate-limiting a recursive is made difficult by the fact that stubs
> mostly do not cache, and it's actually quite reasonable for a stub to
> ask the exact same question a hundred times per second. and if you allow
> that, then you're not going to make yourself useless enough to attackers.
>
> this is why DNS RRL focuses all of its energies on the authoritatives.
> DNS RRL is free, it's ubiquitous, but it's not yet the default. for more
> information, consult the web site below.
>
> http://www.redbarn.org/dns/ratelimits
>
> --
> P Vixie
>
> _______________________________________________
> 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/20161022/1b01a6a4/attachment.html>