I think the rustls QUIC code does the right thing for protocol versions, and will restrict to 1.3 when starting a QUIC connection. Do you have actual evidence to the contrary? Otherwise, I don't think that's an issue.

As long as we don't run the rustls-native-certs loading process multiple times, I think other parts of the config creation aren't likely to have much of a performance impact presuming that we create one TLS config per resolver config (or equivalent).

I think the rustls QUIC code does the right thing here, and will restrict to 1.3 when starting a QUIC connection. Do you have actual evidence to the contrary?

No! I only tested ALPN and SNI.
I didn't know that, but it makes sense.

EDIT: Removed it from OP.

This in turn could be solved by using WebPkiVerifier, but that would require dangerous_configuration and I'm not sure if we want to use that because it would activate it for upstream users as well.

I think rustls would definitely accept a change to take an Arc<RootCertStore> instead of RootCertStore directly. See also rustls/rustls#1403. Perhaps there's a way of doing this that is semver-compatible? I was thinking with_root_certificates() could take some kind of impl AsRef<RootCertStore> + 'static but wrangling that in there semver-compatibly might not be feasible.

See also rustls/rustls#1413 (which will go into rustls 0.22).

@daxpedda, with #2005 merged, what are the potential other changes needed here? Or is that enough?

#2005 did not fix this issue.

The current plan is to store the root certificates in an Arc<RootCertStore> and then store the default RustConfig in the runtime. There we need to split it up into a separate RustConfig for each backend: DoT, DoH, DoQ.

I'm planning to put up a PR in the next couple of days!

Awesome! Thank you!