IIRC the vendors agreed on 150 for two reasons:
1. There are still a fair amount of zones using this value. Only a
handful of zones where using above 150.
2. Resolvers could still cope with such numbers pretty confidently.
I agree lower is better, but let's not pick a number randomly, but have
data to back up that number.
- Matthijs
On 21-10-2021 15:28, Miek Gieben wrote:
[ Quoting <matth...@pletterpet.nl> in "Re: [DNSOP] wrapping up
draft-ietf-..." ]
I don't know what the -right- value is, but I know what I want: 0
iterations, empty salt, otherwise the NSEC3 gets ignored, presumably
leading to SERVFAIL. This removes the 'insecure' window completely.
So, I'll support any push to lower the numbers.
Editorial nit, already hinted at above: the text currently has
"Validating resolvers MAY return SERVFAIL when processing NSEC3
records with iterations larger than 500." - I suggest changing this
to "validating resolvers MAY ignore NSEC3 records with iterations
larger than 500". That way, zones in the middle of a transition from
1000 to 0 iterations do not get punished. Zones at 1000, not in a
transition, will still get SERVFAIL by virtue of the NSEC3 proof
missing (because it is ignored).
In addition, the line just before that says "Validating resolvers SHOULD
return an insecure response when processing NSEC3 records with
iterations larger than 100."
And I suggest to change it to "larger than 150", a value that open
source DNS vendors have been adopting over the last couple of months:
I would recommend against using a limit that happens to be in use at the
current time, and
would just use 100 (or even lower). Resolvers will continue to work fine
and can lower their
limit at their leisure.
/Miek
--
Miek Gieben
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
