Re: [DNSOP] nsec3-parameters opinions gathered

[Petr Špaček <[e-mail]>]

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