[ratelimits] Referrals incorrectly limited.

[john]

Hello Vernon,

Thanks for the response and thanks for your work on the patch

On 1/8/13 10:51 PM, Vernon Schryver wrote:
>> From: john <jbond at ripe.net>
> 
> That rate limiting applies to referrals is an intended feature.
> Without that feature, a bad guy could get a recursive server throttled
> or worse as it tries to deal with a flood of requests.
Would it be possible to tune this with an option similar to
nxdomains-per-second?


> Also without that feature, referrals for random, invalid names would be
> useful from DNS reflection attacks.
> `dig +dnssec asdfasdf.ripe.net ns @a.gtld-servers.net` is good for
> an amplification of about 11X.
> 
> `dig +dnssec 1.1.170.170.91.in-addr.arpa ns @ns.ripe.net` gives me
> a response of 362 bytes.  That means requests for
> <random>.170.170.91.in-addr.arpa ns" are good for reflection attacks
> with an amplification of about 6.5X.  That is as not big as other
> available amplifications, but it has the advantage to bad guys of what
> I assume is your substantial bandwidth and it might not be noticed as
> soon as similar attacks using the roots.
We are aware we would still have some amplifications.  however we are
not seeing attacks that match this pattern at the moment.  Also a bad
guy would have much better results querying for nxdomains as the
amplification their is closer to 13X. e.g  `dig +dnssec
bla.91.in-addr.arpa ns @ns.ripe.net` is 713 bytes versus your 362.

Currently we get a lot of traffic which is not DOS traffic being blocked
by this feature and so far i have seen no DOS traffic being blocked.  I
think it is good to have this blocking available and enabled by default
however it would be nice if we could turn it off

> 
> What is a legitimate reason for more than 25 referrals per second
> (from your "responses-per-second  25") from a single DNS client
> for reverse DNS lookups in 91.170.0.0/16?
The sample traffic was from a university research project trying to do
something similar to the old ripe ncc hostcount project[1].  This meant
they where walking the full in-addr.arpa tree.

> Are you sure you do not want to squelch 198.51.100.111 for reasons
> other than DNS reflection attacks?
> If 198.51.100.111 were some other address, my guess would be that it
> is one of the many evil DNS clients that walk through in-addr.arpa
> looking for domain names to abuse.
In this case the traffic was genuine although i'm sure we get a lot of
traffic that some may consider abusive.  Unfortunately that is not the
problem we are trying to deal with now.  When the rate limit was enabled
with a responses-per-second of 10 we where limiting roughly one prefix
per second matching this traffic signature i.e. referrals.

The time involved investigating each one of these to understand if it is
genuine or abusive would be significant.  This is also forgetting the
fact that there may be some disagreement of what traffic constitutes
abusive; however lets not diverge onto that topic.

For now we want to stop the reflection traffic we are seeing and
minimise the false positives.  As our goal is DOS mitigation a false
positive is any traffic which does not look like a reflection attack.
Once we have shifted some of this reflection traffic away from our
infrastructure further analysis of the type of traffic we get would be
simpler.

> 
> Did you replace the real DNS client IP address in your mail message
> with 198.51.100.111?  If not, that it is appears at all in your DNS
> server logs sounds like a problem.
Yes, I changed the IP address.

Thanks
John


[1]http://www.ripe.net/data-tools/projects/archive/hostcount/ripe-ncc-hostcount