On Sun, Feb 21, 2010 at 4:22 PM, Mark Andrews <[email protected]> wrote:
>
> In message <[email protected]>, John Dickinson
> w
> rites:
>> Hi,
>>
>> It might also be worth adding a line at the start reminding of the need for N
>> SEC and NSEC3 - namely that the signing and serving of the zone are separate
>> operations and that it is therefore necessry to create records that cover the
>> very large number of non-existent names that lie between the names that do e
>> xist.
>>
>> NSEC and NSEC3 are just different ways to achieve this goal and some people m
>> ight prefer one above the other. One is NOT better than the other and it is a
>> matter of operational needs that determine which one you select.
>>
>> It may also be worth removing the mention of cryptographic operations. The ha
>> shing in NSEC3 is just a way to create new names that cover the same spaces.
>> I imagine that many other schemes could have been dreamt up to do this. Hashi
>> ng is just a convenient method.
>>
>> John
>
> Actually NSEC is technically better at proving non-existance. NSEC3
> has a non zero false positive rate due to the fact that the names
> are hashed. NSEC has a zero false positive rate.
>
> This is not to say the false positive rate is high enough to stop
> using NSEC3, but that it needs to be acknowledged.
Unless I'm misreading the specifications, unless you're using an extremely
poor or short hash function, the probability of false positive is vanishingly
small (order 2^{-100}). This shouldn't be acknowledged, but rather
should be ignored. Moreover, it appears that NSEC3 has a mechanism
for dealing with it in S C.2.1 (pointless, IMO...)
So, I don't see what the issue is.
-Ekr
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
