Personal opinions:
I think we should start with full functionality, and if someone shows up later with a usecase for a small one we can add it.
I prefer rustls over openssl, it seems like a more securely designed software (based on the review from cure53)
//Alex
On 27/03/2025 15:07, Antoine Beaupre wrote:
(...)
> # Optional protocol support
>
> The following DNS protocols are optionally supported:
>
> - Enable dns-over-rustls for DNS over TLS (DoT)
> - Enable dns-over-https-rustls for DNS over HTTP/2 (DoH)
> - Enable dns-over-quic for DNS over QUIC (DoQ)
> - Enable dns-over-h3 for DNS over HTTP/3 (DoH3)
(...)
> We already have most of the crates here, it seems we just need this binary.
Yes, despite some feature shenanigans in dependencies,
hickory-dns itself built relatively easily.
(As 0.24; 0.25 is unlikely to make it into trixie.)
Though there is one decision to be made:
whether and which the optional features should be enabled.
In my test build these features are enabled:
- default = [sqlite, resolver, native-certs, ascii-art]
- dns-over-h3
- dns-over-https-rustls (DoH with rustls, other option is disabled upstream, -openssl)
- dns-over-quic
- dnssec-ring (DNSSEC with ring, other option is -openssl)
- recursor
referred to as "mostly full" below.
Size wise:
The default configuration (sqlite, resolver no dns-over-*) weighs in at ~5MB.
The "mostly full" configuration comes at ~12MB,
or ~10MB with opt-level = 3, lto = true, codegen-units = 1.
(I don't think it's desirable to have opt-level = 's',
it's a performance sensitive application.)
As the size difference is quite significant,
it might even be feasible to split a default package and a full one?
Feature wise:
Good to have those secure transports IMO,
but I'm no expert in this field.
Maybe some are less desirable?
Backend wise:
rustls/ring or openssl?
Split packages for them?
--
Sdrager,
Blair Noctis