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

Reply via email to