Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.

[Alex Bligh <[e-mail]>]

Paul,

> I was talking about the situation where example.org is signed, the .org
> is optout and exemple.org does not exist. For many, it is impossible
> to register all typo-squat domains, so this is a real scenario.

Ah, didn't spot the 'e'.

> Having verifiable deniability for typo-squated domaims is very useful.

If expensive, where 99% of your domains are unsigned.

> I had no problems doing this on a 1.2M domains TLD zone, using off the
> shelf hardware, integrating into the TLD's hourly update interval.
> (http://www.cira.ca/dnssec/)
>
> The only issues encountered were indeed the increased memory usage
> on the nameservers, but those can still run fine on commodity hardware.
> Though I recommend 64bit to avoid and 3G or 4G memory allocation per
> process issues.

And on a 100M TLD zone that needs near real time updates? I don't
know whether zone growth predictions exceed Moore's law or vice
versa, to see whether this is a growing problem or not. I agree
that the computational complexity argument is a minority problem.

>> It might be worth mentioning (but is perhaps blindingly obvious) that
>> NSEC3 is substantially more complex in terms of implementation than
>> NSEC. Whilst one can by visual inspection spot the odd problem with
>> a small zone's NSEC chain, it's far harder with NSEC3. Obviously, if
>> a tool chain is used to NSECify and sign the zone, that's a problem
>> for the implementor rather than the operator.
>
> Commercial and free tools are readilly available.

Sure. Just rehearsing an argument I've heard others use against NSEC3.

-- 
Alex Bligh