[GH-ISSUE #2875] Conformance tests: reuse keys #1078

New issue

Open

opened 2026-03-16 01:33:31 +03:00 by kerem · 4 comments

kerem commented

2026-03-16 01:33:31 +03:00

Owner

Originally created by @divergentdave on GitHub (Mar 19, 2025).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2875

I did an off-CPU analysis of the conformance test suite, and it appears that a significant amount of time is spent generating keypairs. (24% of samples have stack traces containing Signer::gen_key()) We could speed things up by generating a handful of keys up front, and then re-using them in different tests as needed. We should still use different keys for different zones in the same test, to maintain test validity. Note also that forwarder::dnssec::scenarios::bogus::wrong_key expects to generate two distinct KSKs for the same zone, so we will need an escape hatch.

Methodology

I ran the tests with RUSTFLAGS="-C force-frame-pointers=y" DNS_TEST_PEER=unbound DNS_TEST_SUBJECT="hickory /home/david/Code/hickory-dns dnssec-aws-lc-rs" cargo test --lib -p conformance-tests --manifest-path conformance/Cargo.toml in one terminal. In another terminal, I ran sudo offcputime-bpfcc -f -U --stack-storage-size 65536 -p `pgrep -n conformance_tes` 120 > out.stacks, using the Ubuntu package for BCC (bpfcc-tools). I then used https://github.com/brendangregg/FlameGraph to render the output, with ~/Source/FlameGraph/flamegraph.pl --color=io --title="Off-CPU Time Flame Graph" --countname=us --reverse < out.stacks > out.svg.

Note that BPF does not support stack walking with DWARF, so force-frame-pointers=y helps us get more complete stack traces. The -U flag for offcputime-bpfcc limits the output to only user-mode stack frames, and -f chooses the folded output format, which flamegraph.pl expects. It's important that offcputime-bpfcc exits before the workload it is tracing, since it only symbolizes at exit, and it needs the process to still be running in order to load the executable. Running for 120 seconds is good enough on my system.

Originally created by @divergentdave on GitHub (Mar 19, 2025). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2875 I did an off-CPU analysis of the conformance test suite, and it appears that a significant amount of time is spent generating keypairs. (24% of samples have stack traces containing `Signer::gen_key()`) We could speed things up by generating a handful of keys up front, and then re-using them in different tests as needed. We should still use different keys for different zones in the same test, to maintain test validity. Note also that `forwarder::dnssec::scenarios::bogus::wrong_key` expects to generate two distinct KSKs for the same zone, so we will need an escape hatch. ## Methodology I ran the tests with `RUSTFLAGS="-C force-frame-pointers=y" DNS_TEST_PEER=unbound DNS_TEST_SUBJECT="hickory /home/david/Code/hickory-dns dnssec-aws-lc-rs" cargo test --lib -p conformance-tests --manifest-path conformance/Cargo.toml` in one terminal. In another terminal, I ran ``sudo offcputime-bpfcc -f -U --stack-storage-size 65536 -p `pgrep -n conformance_tes` 120 > out.stacks``, using the Ubuntu package for BCC (`bpfcc-tools`). I then used https://github.com/brendangregg/FlameGraph to render the output, with `~/Source/FlameGraph/flamegraph.pl --color=io --title="Off-CPU Time Flame Graph" --countname=us --reverse < out.stacks > out.svg`. Note that BPF does not support stack walking with DWARF, so `force-frame-pointers=y` helps us get more complete stack traces. The `-U` flag for `offcputime-bpfcc` limits the output to only user-mode stack frames, and `-f` chooses the folded output format, which `flamegraph.pl` expects. It's important that `offcputime-bpfcc` exits before the workload it is tracing, since it only symbolizes at exit, and it needs the process to still be running in order to load the executable. Running for 120 seconds is good enough on my system.

kerem commented

2026-03-16 01:33:37 +03:00

Author

Owner

@djc commented on GitHub (Mar 19, 2025):

(Consider using the flamegraph Rust binary instead of the Perl tooling -- full disclosure, I'm the current maintainer.)

Curious why we need to generate so many keys at all? Do we a separate set of keys for each test?

@djc commented on GitHub (Mar 19, 2025): (Consider using the flamegraph Rust binary instead of the Perl tooling -- full disclosure, I'm the current maintainer.) Curious why we need to generate so many keys at all? Do we a separate set of keys for each test?

kerem commented

2026-03-16 01:33:43 +03:00

Author

Owner

@divergentdave commented on GitHub (Mar 19, 2025):

Yes, whenever we sign a zone file, we do so with a freshly-generated ZSK and KSK. A DNSSEC test may do so on multiple zone files.

@divergentdave commented on GitHub (Mar 19, 2025): Yes, whenever we sign a zone file, we do so with a freshly-generated ZSK and KSK. A DNSSEC test may do so on multiple zone files.

kerem commented

2026-03-16 01:33:48 +03:00

Author

Owner

@djc commented on GitHub (Mar 19, 2025):

Can we sign with ECDSA? That would probably be the easiest win?

@djc commented on GitHub (Mar 19, 2025): Can we sign with ECDSA? That would probably be the easiest win?

kerem commented

2026-03-16 01:33:53 +03:00

Author

Owner

@divergentdave commented on GitHub (Mar 19, 2025):