...
Vernon Schryver wrote:
> ...
>
> ... We are talking about testing for (and perhaps
> mitigating) attack packets. A "positive" for our test is "this packet
> is an attack packet." Deciding that a packet is not an attack packet
> is a "negative". An accurate test or determination that a pa
-Original Message-
From: Vernon Schryver
Date: Thursday, May 16, 2013 11:30 AM
To: "dns-operati...@mail.dns-oarc.net"
Subject: Re: [dns-operations] bind-9.9.3rc2 ANY+TCP patch
>That is mistaken. We are talking about testing for (and perhaps
>mitigating) attack packe
> From: Matthijs Mekking
> > https://www.google.com/search?q=false+positive
> > http://www.mathsisfun.com/data/probability-false-negatives-positives.html
> > https://en.wikipedia.org/wiki/Type_I_and_type_II_errors
>
> So a false positive is a type I error, aka "the incorrect rejection of a
> tru
On 05/16/2013 03:31 PM, Matthijs Mekking wrote:
On 05/16/2013 02:54 PM, Vernon Schryver wrote:
From: Matthijs Mekking
https://indico.dns-oarc.net/indico/getFile.py/access?contribId=4&resId=0&materialId=slides&confId=0
Page #12
I also wonder about the definition of "false positive." The
On 05/16/2013 02:54 PM, Vernon Schryver wrote:
From: Matthijs Mekking
https://indico.dns-oarc.net/indico/getFile.py/access?contribId=4&resId=0&materialId=slides&confId=0
Page #12
I also wonder about the definition of "false positive." There are many
plausible candidates.
I agree. Basic
> From: Matthijs Mekking
> >> https://indico.dns-oarc.net/indico/getFile.py/access?contribId=4&resId=0&materialId=slides&confId=0
> >>
> >> Page #12
> > I also wonder about the definition of "false positive." There are many
> > plausible candidates.
>
> I agree. Basically it is a query from an
On 05/16/2013 12:52 AM, Vernon Schryver wrote:
From: Jared Mauch
Because of the FP ratio presented at the DNS-OARC meeting this
past week. It's suitable on a recursive resolver, where RRL is most effective
on an authority.
See
https://indico.dns-oarc.net/indico/getFile.py/access?contribId=
On May 15, 2013, at 6:52 PM, Vernon Schryver wrote:
>> This effectively does slip=1 and does away with any amplification and just
>> makes it
>> a pure reflection attack. Still not ideal, but doesn't amplify.
>
> On the contrary, as I just now wrote in the ratelimits mailing list
> http://lis
> From: Jared Mauch
> Because of the FP ratio presented at the DNS-OARC meeting this
> past week. It's suitable on a recursive resolver, where RRL is most effective
> on an authority.
>
> See
>
> https://indico.dns-oarc.net/indico/getFile.py/access?contribId=4&resId=0&materialId=slides&confId=0
One more comment: This patch only impacts recursive servers, not authorities.
They won't set TC=1 for an ANY query.
- Jared
On May 15, 2013, at 6:03 PM, Jared Mauch wrote:
>
> On May 15, 2013, at 5:58 PM, John Kristoff wrote:
>
>> On Wed, 15 May 2013 17:52:11 -0400
>> Jared Mauch wrote:
>
On May 15, 2013, at 5:58 PM, John Kristoff wrote:
> On Wed, 15 May 2013 17:52:11 -0400
> Jared Mauch wrote:
>
>> If others want, I can look at putting in a config directive. It
>> would be possible to add other RRtypes easily enough that should get
>> TCP only that are not commonly used.
>
>
On Wed, 15 May 2013 17:52:11 -0400
Jared Mauch wrote:
> If others want, I can look at putting in a config directive. It
> would be possible to add other RRtypes easily enough that should get
> TCP only that are not commonly used.
I can speak for others, but I would prefer to use the RRL code al
On May 15, 2013, at 5:09 PM, Matthäus Wander
wrote:
> * Vernon Schryver [2013-05-15 21:40]:
>>> From: Jared Mauch
>>> This is a crude but effective hack. It doesn't stop the system from
>>> recursing to find the response.
>>
>>
>> I can understand simplistic DNS reflection mitigation in fi
* Vernon Schryver [2013-05-15 21:40]:
>> From: Jared Mauch
>> This is a crude but effective hack. It doesn't stop the system from
>> recursing to find the response.
>
>
> I can understand simplistic DNS reflection mitigation in firewalls,
> especially when response rate limiting is not availab
> From: Jared Mauch
> I thought I'd share this to anyone that wants to just force all TYPE=ANY
> queries over TCP to prevent those from coming from spoofed locations.
>
> This is a crude but effective hack. It doesn't stop the system from
> recursing to find the response.
>
> http://puck.nethe
I thought I'd share this to anyone that wants to just force all TYPE=ANY
queries over TCP to prevent those from coming from spoofed locations.
This is a crude but effective hack. It doesn't stop the system from recursing
to find the response.
http://puck.nether.net/~jared/bind-9.9.3rc2-tcp-any
16 matches
Mail list logo
