[dns-operations] bind-9.9.3rc2 ANY+TCP patch

[Matthijs Mekking]

On 05/16/2013 12:52 AM, Vernon Schryver wrote:
>> From: Jared Mauch <jared at puck.nether.net>
>
>> 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
>>
>> Page #12
>
> I wonder to which RRL implemetation those numbers apply?
>
> Please recall that those slides appeaer to be from NLnet Labs and
> that one of my concerns with the NLnet Labs RRL implementation is
> the possibility of significantly more false positives than what I
> hope are the practically none from the BIND9 RRL code.

The numbers apply to BIND9.9.2-P1 + RRL (it is in the report).

> I also wonder about the definition of "false positive."  There are many
> plausible candidates.

I agree. Basically it is a query from an attacker that is not being 
dropped. I know it has more to it than that. It might be a good idea to 
define the term in the technical note. I can write some initial text, if 
that is appreciated.

>> 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://lists.redbarn.org/mailman/listinfo/ratelimits
> your patch does not affect amplification by authorities.
> For example, if applied to an authority for isc.org,
> `dig +dnssec isc.org any @ams.sns-pb.isc.org'
> would still reflect almost 4 KBytes for each 60 byte ANY request.
>
>
> Vernon Schryver    vjs at rhyolite.com
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
>