performance degradation on NSEC3 zones when queried with DO=1

Summary

Authoritative zone signed using RSASHA256 + NSEC3 with 15 iterations and no opt-out suffers from large performance degradation when queried with DO=1.

BIND version used

• Affects v9.19: v9_19_9
• Affects v9.18: v9_18_11
• Affects v9.16: v9_16_36

Steps to reproduce

1. Start with an empty zone: empty.db

2. Generate new keys, I used alg 8 KSK 2048 b, ZSK 1024 b: Knet.+008+42541.private Knet.+008+42541.key Knet.+008+62311.private Knet.+008+62311.key

3. Resign the original zone using new keys and 15 NSEC3 iterations with non-empty salt

dnssec-signzone -S -o net -u -H 15 -3 0123456789ABCDEF empty.db

empty.db.signed

4. Load into auth:

options {
        check-names primary ignore;
        check-names secondary ignore;
        recursion no;
        allow-query {
                "any";
        };
        check-dup-records warn;
        check-integrity no;
        check-mx ignore;
        check-mx-cname ignore;
        check-sibling no;
        check-spf ignore;
        check-srv-cname ignore;
        check-wildcard no;
        notify no;
};

zone "net." {
        type primary;
        file "/usr/etc/empty.db.signed";
        masterfile-format text;
};

5. Query with DO=0 and DO=1. Query list can contain a single line: aaa.net. A Repeating the query suffices to reproduce the problem.

Command:

dnsperf -d qlist -s 10.10.126.46 -p 53 -S1 -T8 -O suppress=timeout -c 64 -q 1000 -l 10 -D

6. Compare max QPS - use dnsperf without and with -D to set the bit

What is the current bug behavior?

On a 16 thread machine, 8 cores, AWS type c5n.4xlarge, the performance degradation from DO=0 to DO=1 is roughly 10x.

What is the expected correct behavior?

Well, smaller performance drop :-)

CPU profiling

Beware: Done on a net. zone which exhibits ~ 3-4x degradation. Profile is from v9_18_8.

DO=0

DO=1

diff between DO=0 and DO=1 run