[dns-operations] Best Practices

[Vernon Schryver]

> From: Florian Weimer <fw at deneb.enyo.de>

> >> a) Secure configuration guidelines (RRL you can't make part
> >> of that, because it requires too much tuning IMHO).

I think RRL is young for published, official secure configuration guidelines.


> > rrl's defaults work fine on every authority server i've tried.
>
> That's probably because those servers don't see traffic from resolvers
> which in turn have clients that send queries which are a little bit
> creative.

What is the nature of the troublesome traffic or tuning on authority
servers that you've seen or heard about with settings as close to
defaults as you get without leaving RRL turned off?

    rate-limit { responses-per-second X; };

probably for X>=2 and <=20,
and perhaps X=15 as suggested on http://www.redbarn.org/dns/ratelimits

Would the "too much tuning" problem be fixed by adding
    rate-limit { responses-per-second 15; };
to the example in the BIND9 ARM text?  


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


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

Is there a specific question about the key in BIND9 RRL?


** I continue to be surprised and disappointed by people who spin
"RRL is not recommended for recursives" into
RRL-doesn't-work-especially-on-recursives and then flog that FUD.
"Not recommend" differs from "doesn't work," "denies all service,"
"is a security hole," or "breaks the intertubes."
RRL on recursives could in theory slow down applications that repeat
requests a lot, but I do not recall hearing of even one case where
end users noticed or complained.
Recursive servers should generally not need RRL, because they shouldn't
be open and so needn't worry about reflection DDoS attacks.
Not recommending RRL on recursive servers is like not prescribing
statins for people without high cholesterol levels.

Besides, open recursives must have some kind rate limiting,
as people who run professional open recursive servers say.


Vernon Schryver    vjs at rhyolite.com