On 08. 11. 21 9:34, Matthijs Mekking wrote:
I concur with Benno.For Bind 9, there is no technical challenge to set the iteration cap at a lower value. We prefer the value to be as low as possible, because it adds no real value at a real resource cost. But we will likely not implement blindly a maximum that will cause lots of operational problems.
TL;DR I say we should go for 0 and acknowledge in the text we are not there yet. A longer version, With Measurement Inside (tm):From my point of view the RFC does not need to stick to the value currently implemented in resolvers.
IMHO the technically "hard" part is implementing limits at all, and understanding their impact. I would loudly object to publishing the text before the mechanism have been implemented and tested in wild, but we are now past this phase. I.e. we already now it is feasible to implement, and that reasonably high values work well in practice.
The specific value is quite obviously a moving target, so I think it is appropriate to acknowledge that in the text. I propose to say something along those lines:
- resolvers use 150 iterations as insecure limit as of November 2021- resolvers are expected to gradually lower the limit to 0 over time, so don't do stupid things and use 0 right away
That's factually correct and also provides us with a stick to beat outliers.To make this debate more informed, let's have a quick glance on real performance impact of NSEC3 iterations.
This is measured against BIND 9.17.19 as an authoritative server. In all cases the server was CPU-bound and we compare average QPS
| Iterations | QPS [% of 0 iterations QPS] | |------------|-----------------------------| | 0 | 100 % | | 10 | 89 % | | 20 | 82 % | | 50 | 64 % | | 100 | 47 % | | 150 | 38 % |That's means that even 100 iterations is a huge waste of resources, where half of the QPS is sacrificed to mindless NSEC3 iterations.
So again, I say we should go for 0 and acknowledge in the text we are not there yet.
------Here is my crude test setup so people can reproduce it themselves, possibly with different software:
* $ cat named.conf
zone "." {
type primary;
file "root.zone.signed";
};
* input zone: root zone SOA serial 2021012701
* keys:
dnssec-keygen -K . -a ECDSAP256SHA256 .
dnssec-keygen -K . -a ECDSAP256SHA256 -f KSK .
* signed with:
# example with no salt, 0 iterations
dnssec-signzone -u -3 - -H 0 -S -o . root.zone
* BIND started with:
named -g -c named.conf -n 1
* numbers below are from a far-from-perfect laptop setup, so some
instability is to be expected; here are some basic tweaks for Intel
hardware:
echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo cpupower frequency-set -g performance cpupower frequency-set --min 2.4G --max 2.4G * perf tested with: yes 'blabla. A' | dnsperf -D -s localhost -l 20 -S 1 A crude measurement script is attached. To get raw numbers run: fgrep -H 'per second' iter* | sed -e 's/:[^:]*nd:/:/' More detailed results in a table:| Iterations | Min - qps | Median - qps | Average - qps | Max - qps | StDev - qps | stdev [% of avg] | % of 0 iterations qps avg |
|------------|-----------|--------------|---------------|-----------|-------------|------------------|---------------------------|| 0 | 19 910 | 22 289 | 21 881 | 22 937 | 994 | 5 % | 100 % | | 10 | 18 078 | 19 333 | 19 367 | 20 278 | 843 | 4 % | 89 % | | 20 | 16 947 | 18 167 | 17 982 | 18 289 | 419 | 2 % | 82 % | | 50 | 13 483 | 14 225 | 14 021 | 14 385 | 395 | 3 % | 64 % | | 100 | 9 922 | 10 426 | 10 371 | 10 573 | 212 | 2 % | 47 % | | 150 | 7 962 | 8 315 | 8 270 | 8 320 | 112 | 1 % | 38 % |
Now I can only hope the tables survive transit. -- Petr Špaček @ ISC
measure.sh
Description: application/shellscript
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
