On 08. 11. 21 14:41, Wes Hardaker wrote:
Petr Špaček <pspa...@isc.org> writes:
Thanks for the detail notes Petr, very helpful.
From my point of view the RFC does not need to stick to the value
currently implemented in resolvers.
Good point, and maybe the right phrasing I should have used should have
been "what value would implementations refuse to switch to"?
Well, the answer is the same:
For validators it's a moving target. A high value which was "necessary"
yesterday might not be needed today because a large hoster moved on.
In part, I worry that code authors would object to having just changed
something and refused to change again. It seems like reports are
overcoming that problem though :-)
[I'm not sure we're at zero yet...]
Sure, but that's not the point. The value is ever-changing.
As I see it, we can either:
a) Specify _a_ value valid for November 2021 and produce a RFC with
values not reliable beyond November 2021.
b) Specify _the_ ultimate target which guarantees interoperability in
future, and make it really clear in the text.
I think the second option is much better, so let me try this approach.
I'm proposing text along those lines:
Addition for section
3.1. Best-practice for zone publishe
----
Please note that any number of iterations larger than 0 carries risk of
interoperability problems. Any zone using higher iterations counts is
willingly signing up for problems.
The reason for this is that DNSSEC responders and validators have to
limit resource usage caused by excessive iteration values, and even very
small numbers of iterations impose significant overhead, which motivates
software vendors to drive the limit down to 0.
-----
If we really wanted we could add an appendix with an illustrative table
(with disclamer about being just ilustrative for one software version,
point in time, hardware etc. etc.):
| Iterations | QPS [% of 0 iterations QPS] |
|------------|-----------------------------|
| 0 | 100 % |
| 10 | 89 % |
| 20 | 82 % |
| 50 | 64 % |
| 100 | 47 % |
| 150 | 38 % |
If we wanted a simpler example we could say something like "at the time
of this writing, mere 10 iterations caused over 10 % QPS drop on two
popular authoritative server implementations".
(As a sanity check I just tested Knot DNS and the impact there is very
similar to what we see in the table about for BIND.)
Honestly I don't think it's necessary.
As for
3.2. Recommendation for validating resolvers
I don't see need to specify _a_ value here. I think better approach is
acknowledge current state of things. What about something like this?
---
As for November 2021, the limit of 150 iterations for treating answer as
insecure is interoperable without significant problems, but at the same
time it makes DoS attacks based on exhausting CPU resources three times
cheaper when compared to 0 iterations.
For this reason software vendors are expected to evaluate NSEC3
iteration counts seen in wild and lower their limits over time.
---
What do you think about this approach?
--
Petr Špaček
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
