[dns-operations] responding to spoofed ANY queries

[Vernon Schryver]

> From: Casey Deccio <casey at deccio.net>

> 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%). 

As Paul Vixie often says, the goals of RRL do not include stopping
DNS reflection DoS attacks but:
  1. attenuating reflection attacks so much that the attacker would
      do more damage to the victim by sending the bogus DNS requests 
      directly to the victim
  2. not letting the attacker deny DNS service to the victim by
      failing to answer the victims real requests.

Goal #1 is achieved by attenuating or sending fewer bits toward the
victim than the attacker sends to the DNS server.  With "slip 2", the
attacker's bits are reduced by about 50%.  The attacker would do twice
the damage by sending toward the target instead of the reflector.

Goal #2 is approached with "slip" hack and by rate limiting responses
instead of clients.  The victim's DNS requests are unaffected unless
they are for the same name and type as the attacker's forged requests.
Goal #2 is practically reached while the attacker avoids the major
query types.  If the attack uses a major type such as A, then we rely
on the probability of at least one of the victim's requests getting a
"slip" or TC=1 response.  It helps that the victim need only get one
response per DNS cache lifetime.


> 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.

With slip=2 and the victim trying and retrying a total 3 times, the
probability that all of the victims responses will be dropped is
0.5*0.5*0.5 = 0.125.  That makes the probability that the victim
will get a response despite matching the DoS flood about 88%.  That's
not perfect, but not bad.  If it's a mail system that will retry a
few times or a user at a browser that will manually retry a failed
page, it gets even better.


> 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.

The impression that the "slip" value can be scaled down using the gross
qps rate comes from an error of mine the documentation.  Only the real
rates can be scaled.

I've proposed that the 'slip' value be scaled up the qps ratio or the
square of the qps ratio to keep the TC=1  responses/second rate constant.
On the other hand, any reduction of TC=1 responses (i.e. increase in
"slip") reduces the reason to have slip.


Vernon Schryver    vjs at rhyolite.com