[dns-operations] Best Practices

[Florian Weimer]

* Vernon Schryver:

>> ISC-TN-2012-1 is unfortunately not very clear about the actual key
>> used to determine the bucket to account against.
>
> What is the relevance of the shortcomings of
> http://ss.vix.su/~vixie/isc-tn-2012-1.txt to whether RRL works on
> authority (or even recursive**) servers without too much tuning?

I used it (perhaps naïvely) as the reference for the default settings
and their potential impact.  Is there a better source (except the
source code itself)?

>>                                                   Section 2.2.1 claims
>> that "many possible questions can yield the same answer" and suggests
>> that the rate limit applies to those "same answers" (which apparently
>> do not include the transaction ID or question section), but section
>> 3.1 talks about the QNAME.
>
> It wouldn't make sense to rate limit based on transaction IDs,
> because they're supposed to be functionally unique.

Sure, I brought this up to point out that the "same answer" concept
needs explanation.

> The R in RRL stands for "response", and so rate limits should ignore
> the question section as much as possible.
> For non-empty, non-error, non-wildcard generated, non-referral
> responses, the key is {class,qname,qtype,client IP block}.

Okay, that makes sense, but contradicts the previous sentence.  I
don't quite get how you can ignore the question section, but extract
QNAME and QTYPE.

> Section 2.2.1 is about the special cases where answers are too similar.
> The rate limit for NXDOMAIN responsess is applied to the domain
> from the SOA, because response rate limiting would not be a useful
> DNS reflection attack mitigation mechanism if it treated the identical
> responses to the practically infinite number of different
> <random>.example.com questions the same.

I'm worried what happens if I send garbage <random>.example.com
queries through a legitimate resolver, and how that would imapct
(legitimate) queries for not-so-random.example.com.

> Recursive servers should generally not need RRL, because they
> shouldn't be open and so needn't worry about reflection DDoS
> attacks.

On the other hand, accidental DoS of resolver service triggered by
garbage queries from badly written clients is a problem, isn't it?
It's not something RRL intends to solve, but I worry that it makes
matters worse.