Dear colleagues,
[This mail is cross posted to a few relevant mailing lists, apologies
for duplicates]
Since DDOS through DNS amplification has been a hot topic on this list I
would like to make you aware that we now have a production release of
NSD that contains Response Rate Limiting (RRL): NSD
We now have two implementation of response rate limiting (RRL). In order for it
to be widely adopted, an Internet-Draft followed by an RFC would be Really
Helpful.
If this is not possible due to overcommitment on the parts of the authors, I
would be willing to be primary editor of the draft. Th
Paul Hoffman wrote:
> We now have two implementation of response rate limiting (RRL). In order for
> it to be widely adopted, an Internet-Draft followed by an RFC would be Really
> Helpful.
agreed.
> If this is not possible due to overcommitment on the parts of the authors, I
> would be will
On Feb 4, 2013, at 11:07 AM, Paul Vixie wrote:
> Paul Hoffman wrote:
>> We now have two implementation of response rate limiting (RRL). In order for
>> it to be widely adopted, an Internet-Draft followed by an RFC would be
>> Really Helpful.
>
> agreed.
>
>> If this is not possible due to ove
On Mon, Feb 04, 2013 at 10:54:36AM -0800, Paul Hoffman wrote:
> We now have two implementation of response rate limiting (RRL). In order for
> it to be widely adopted, an Internet-Draft followed by an RFC would be Really
> Helpful.
>
What track do you expect this to go along? Is this a DNSOP d
On Feb 4, 2013, at 11:39 AM, Andrew Sullivan wrote:
> On Mon, Feb 04, 2013 at 10:54:36AM -0800, Paul Hoffman wrote:
>> We now have two implementation of response rate limiting (RRL). In order for
>> it to be widely adopted, an Internet-Draft followed by an RFC would be
>> Really Helpful.
>>
>
On Mon, Feb 04, 2013 at 12:31:28PM -0800, Paul Hoffman wrote:
> Old-style IETF (RFC that really requests comments), and only later settling
> on what to tell the community as "best".
>
This sounds like an excellent idea to me.
A
--
Andrew Sullivan
a...@anvilwalrusden.com
_
Paul Hoffman wrote:
> ...
>
> I think it should be Experimental, it should discuss any differences that the
> BIND and NSD folks have, and it should be an individual submission.
>
> After than, people can discuss the different approaches over maybe a year,
> and if there is kinda general agree
> > ... 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 existi
Why an IETF document? In what way does Response Rate Limiting impact
interoperability of implementations?
If this is not an independent submission, how does it fit into a working group?
The implementations are pretty much out there, what's to work on?
I understand that would be useful is a re
Hi,
On Mon, Feb 04, 2013 at 09:02:14PM +, Vernon Schryver wrote:
> > 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 thin
Edward Lewis wrote:
> Why an /IETF/ document? In what way does Response Rate Limiting
> impact interoperability of implementations?
>
> If this is not an independent submission, how does it fit into a
> working group? The implementations are pretty much out there, what's
> to work on?
>
> I und
Edward Lewis wrote:
> Why an /IETF/ document? In what way does Response Rate Limiting
> impact interoperability of implementations?
>
> If this is not an independent submission, how does it fit into a
> working group? The implementations are pretty much out there, what's
> to work on?
>
> I und
may i suggest that the ratelimits mailing list is a better place for
this argument. but herewith:
Andrew Sullivan wrote:
> Suppose that DNSprov provides DNS service on behalf of HiProfile.
> Suppose that HiProfile has one of those services that is really
> susceptible to the "no response, kill the
On Feb 4, 2013, at 2:32 PM, Edward Lewis wrote:
> Why an IETF document?
Because that's where implementers look for such documents.
Because there are implementers who are active in the IETF who might have
valuable opinions on what the doc might say that would make it more valuable.
> In what
> From: Andrew Sullivan
> > 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).
>
> No, it isn't.
Yes, it is. Please pause to understand the differe
On 02/04/2013 03:16 PM, Paul Hoffman wrote:
On Feb 4, 2013, at 2:32 PM, Edward Lewis
wrote:
Why an IETF document?
Because that's where implementers look for such documents.
Because there are implementers who are active in the IETF who might
have valuable opinions on what the doc might say t
17 matches
Mail list logo
