This is a discussion on NSEC3 Issue 9: Potential DoS on Resolvers - DNS ; NSEC3 Issue 9: Potential DoS on Resolvers Issue: A potential DoS condition exists in which the operator of a malicious server could select an impractically high number of iterations for the NSEC3 RRs in an signed zone. The NSEC3 RDATA ...
NSEC3 Issue 9: Potential DoS on Resolvers
A potential DoS condition exists in which the operator of a malicious
server could select an impractically high number of iterations for the
NSEC3 RRs in an signed zone. The NSEC3 RDATA format permits values as
high as 2 ^ 23, or 8,388,608 (N.B. this is a change in -04; in -03 it
was 2 ^ 24). Consequently, when a resolver receives multiple queries
for names (existent or non-existent) in this zone, the resolver must
perform the same number of hash iterations for each query. This could
result in a significant denial-of-service on the resolver.
One solution would be to permit resolvers to set an upper limit for the
number of iterations that would be permitted in an NSEC3 RR, and to
treat NSEC3 RRs with values exceeding this as insecure or bogus. This
could be accomplished at the implementation level alone, or it could be
governed by a recommendation or standard.
One subsidiary issue is that any limit may have to change over time in
response to increases in computational speed: a limit which may
initially reflect an unjustifiably high number of iterations may later
be considered cryptographically weak.
We agree that it is desirable for resolvers to set an upper limit.
We propose to submit the following two questions for consideration by
the IETF Security Area Directorate:
1. Should an upper limit be specified in the standard?
2. If so, should the upper limit be specified in a separate document
so that the it may be updated without having to re-publish the
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.