[ratelimits] I-D-ing rate limiting?

[Vernon Schryver]

> From: =?iso-8859-1?Q?Patrik_Wallstr=F6m?= <pawal at blipp.com>

> Isn't it a good idea then to document the three different implementations
> and their differences, and then gather a set of requirements on DNS RRL?

Documentation is good and I would like to see an RFC someday.  However,
a formal IETF requirement document would make sense only if this stuff
depended on the let, leave, or hindrance of the IETF.  This stuff is
mostly about not putting bits on the wire, and so out of the practical
reach of IETF WGs, IESG, IAB, etc. even if the IETF wanted to own it.

Besides, the reflection DoS problem is too urgent to wait the years
that IETF processes require.

The important, relevant bits that are put on the wire are configuration
file statements, as when a site with many DNS servers uses a
configuration management system.  Even if the IETF wanted to regulate
DNS server configuration file syntax and even if it were not 30
years too late for the IETF to take up named.conf syntax, that's
simply not going to happen.


> As I currently perform a lot of different measurements on DNS, there
> won't be long until I will discover a lot of problems in my results
> due to RRL. So on the list of requirements I would like to add a new
> rcode...

I sympathize with that goal, but trying to solve it with rcodes has
problems.  There is no place to put a new rcode in dropped responses.
The years needed to get an RFC justifying an rcode would also be a
problem.  On the other hand, the RRL design goal of answering legitimate
DNS requests during attacks implies that RRL can be fingerprinted.  A
DNS server that answers an isolate request (including with REFUSED)
but drops much of a burst might be using RRL.


Vernon Schryver    vjs at rhyolite.com