[dns-operations] responding to spoofed ANY queries

[Casey Deccio]

On Thu, Jan 10, 2013 at 12:07 PM, Jim Reid <jim at rfc1035.com> wrote:

> On 10 Jan 2013, at 17:39, Matthew Ghali <mghali at snark.net> wrote:
>
> > So if I understand correctly, the solution you are advocating is to only
> answer non-spoofed queries?
>
> It's one of them, yes. Though since it's hard for a DNS server to
> distinguish between spoofed and genuine source IP addresses, the RRL patch
> is the easiest way to get the same effect. Your server would then respond
> to a teeny fraction of the thousands of queries per second from the same
> (forged) IP address(es).


I'm not familiar with other RRL behavior, but to provide some numbers for
BIND's patch:  All responses to rate-limited queries are truncated, but
default behavior is to withhold response altogether for only 1 out of 2
such queries (50%).  The maximum configurable behavior is to withhold 90%
of such responses [1].

With a low response rate for rate-limited queries and a high query rate for
a rate-limited query from the same "client", responses to legitimate
clients with the same IP (or range) would effectively be shut out by the
statistical (im)probability of being "selected".  I understand that "teeny
fraction" is a relative term, but in order to effectively meet the
objectives of 1) amplification mitigation and 2) not denying legitimate
clients service, the response rate must be reasonable.  A reasonable value
depends on the query rate.  The statisticians might provide a good rule of
thumb for reasonable response rate given query rates, but it seems like 50%
is in fact a good starting place.

The BIND RRL patch also has an option for scaling down the "slip" value
(which dictates response rate) in the presence of increased query rates.  I
haven't had time to play with it, but the idea is smart.

kudos to Paul and Vernon on the BIND RRL patch (and others working on
similar functionality). It's been a useful tool for mitigating some of the
behaviors that have been observed in recent months.

Casey

[1] documentation from the patch itself:

Rate limiting prevents the use of BIND 9 to flood a network
with responses to requests with forged source addresses,
but could let a third party block responses to legitimate requests.
There is a mechanism that can answer some legitimate
requests from a client whose address is being forged in a flood.
Setting slip to 2 (its default) causes every
other UDP request to be answered with a small response
claiming that the response would have been truncated.
The small size and relative infrequency of the response make
it unattractive for abuse.
Slip must be between 0 and 10.
A value of 0 does not "slip"
or sends no rate limiting truncated responses.
Some error responses includinge REFUSED and SERVFAIL
cannot be replaced with truncated responses and are instead
leaked at the slip rate.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20130110/d1a2c3ae/attachment.html>