unbound icon indicating copy to clipboard operation
unbound copied to clipboard

[FR] Parallelize DNSSEC lookups when forwarding

Open cyounkins opened this issue 3 years ago • 3 comments

Current behavior A DNSSEC-validating configuration causes client latency approximately twice that of a nonvalidating configuration due to serial A/AAAA and DS queries.

Describe the desired feature Parallelizing the DS queries will reduce latency seen by clients by about 50%. Because DNSSEC validation is enabled by default in most OS packages, this huge performance gain will benefit most users.

Details dnsmasq and knot-resolver have the same or worse performance characteristics when it comes to DNSSEC validation. I surveyed different daemons and created a framework for testing: https://cyounkins.medium.com/costs-and-benefits-of-local-dnssec-validation-53c72ca9059b

Note that I only tested a forwarding configuration.

While the NSEC/NSEC3 records have TTLs of around 1 day, RFC9077 makes it very clear that the TTL should be reduced to the SOA TTL if it is lower. I'm fairly confident unbound matches the example in the RFC and these NSEC/NSEC3 records are cached for 15 minutes or less.

Thank you for unbound!

cyounkins avatar Feb 05 '22 02:02 cyounkins

There is an option to do that, prefetch-key: yes that causes parallel lookups for DNSKEY records. The type DS records are supposedly picked up as they are sent with the referrals that unbound gets. The aggressive-nsec option that just turned default on caches the NSEC records for use.

wcawijngaards avatar Feb 07 '22 07:02 wcawijngaards

I'm not sure what you mean by "The type DS records are supposedly picked up as they are sent with the referrals that unbound gets." Can you clarify?

The current documentation for prefetch-key seems to suggest DS/DNSKEY parallelism: "If yes, fetch the DNSKEYs earlier in the validation process, when a DS record is encountered." I'm talking about the primary A/AAAA record and the DNSSEC records.

I have tested prefetch-key and found no performance benefit. Here's a log: https://gist.github.com/cyounkins/79dc11acc382d0ccc91dd4c718db423a I examined the tcpdump and confirmed that even with prefetch-key: yes, a query for DS wikipedia.org is not sent until a response to A wikipedia.org is received.

cyounkins avatar Feb 07 '22 19:02 cyounkins

From your logs I see that this is happening because you forward all traffic. If you used full recursion, without the forward clause, then unbound would fetch DNSKEY records in parallel with the DS records that it gets from delegations. There is no feature to fetch DS or DNSKEY records in parallel when it is forwarding, it is tied to the referral responses that unbound gets when the feature is enabled, and unbound gets those responses when it is a full recursor, eg. using a stub-zone or root hints.

wcawijngaards avatar Feb 09 '22 08:02 wcawijngaards