This is a discussion on Re: NSEC2 on existing records - DNS ; Ben Laurie wrote: >The downside of this proposal is that currently EXISTS records are only >needed to prove closest enclosers that otherwise don't exist. You'd be >introducing them for every name in the zone - and you'd still have to ...
>The downside of this proposal is that currently EXISTS records are only
>needed to prove closest enclosers that otherwise don't exist. You'd be
>introducing them for every name in the zone - and you'd still have to
>have NSEC2 records. The upside, if I understand, is that for the case of
>proving existence you'd save the size of the hash of the next domain
>name in the response. Not sure the upside is worth the downside.
The point of the proposal is (a) to cut the amount of work required
for authenticated denial of RRsets in existing names using NSEC2, and
(b) to cut the traffic on the wire in both authenticated denial cases.
The expense, as you say, is to add an additional RR and its signature to
the zone, making zone signing harder.
Where I'm coming from with regard to (a) is that TLD zones would contain
vast numbers of insecure delegations, especially early in the game, and
every one of those insecure delegations would need to generate hashed
NSEC2 records for security-aware resolvers. While authoritative name
servers could internally link each name with its NSEC2 hash at zone load
time, that link has to be computed on the fly by security-aware
resolvers every time a query is made via those delegations.
If the NSECINFO iteration count is high to deter offline dictionary
attacks, those hash computations could get expensive for smaller
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.