[dns-operations] RRL specified in a stable place?

[Vernon Schryver]

> >   ... an Internet-Draft followed by an RFC would be Really Helpful.

> What track do you expect this to go along?  Is this a DNSOP draft?

Those are best boring details except to those with non-technical
interests in the IETF.

> Because the implementations are really just a way of using existing
> parts of the specifications in creative ways. 

That covers a lot of RFCs.

>                                                (They're also risky for
> some operators. 

That covers a lot of RFCs.

>                  Consider that, if you spoof $ISP's resolver addresses
> and perform one of these attacks, then $ISP gets at least degraded
> service during the rate limit period.

Perhaps I misunderstand, but I think that's wrong in general and based
on the persistent and by now very irritating confusion between client
rate limiting and response rate limiting (RRL).  In addition, ISPs
have reported that installing and turning on RRL has restored DNS
service that had been degraded by apparent DNS refection DoS attacks.
While your DNS servers are trying to respond to Mqps of bogus requests,
they are often not only flooding the DoS victim but also not getting
out other responses.


> it's not a panacea either,

That cover a lot of RFCs.

>                            and certainly cannot be considered a BCP
> for all use cases.)

Ok, so don't make as a BCP.  Let it be Informational.  Or don't advance
it after publishing it as an I-D.  Keeping change control out of the
IETF will not slow the spread of the idea or harm interoperability
(which in the old days was the reason for RFCs).

If you think not letting the IETF "improve" and then freeze the
specification will lead to fragmentation and disparate implementations,
then you should oppose an RFC.  Without an RFC, there is more room for
better ideas.  Because there is no directly involved on-the-wire
protocol, there is much less need for an RFC.

Personally, I think it would be nice if it were published at least as
an I-D ensure that the idea reaches more potential implementors.  However,
it would not be a big deal if the IETF doesn't want it even as an I-D.


The one thing the IETF really should do (if it has not become
interchangable with the ISO/ITU/UN) is to add two check list items
before advancing future protocols:

   - all servers MUST deal appropriately with excessive requests such 
      as by rate limiting by client, network, request, and/or type of
      request.  This is particularly important for services that
      do not require long lived state.

   - all clients MUST rate limit their requests, both retries and de novo,
      including using at least exponential back-off.


Vernon Schryver    vjs at rhyolite.com