Prev the ECH config parsing was placed in between parsing ipv4 and ipv6
hints. This commit reorders so that `parse_ech_config()` is after
`parse_ipv4_hint()` and `parse_ipv6_hint()`.
Previously `"echconfig"` was being used as the encrypted client hello
(ECH) service parameter key for SVCB/HTTPS RRs.
In RFC960 the parameter key is specified in the intial IANA registry
contents as `"ech"`[0].
This commit updates the two relevant parts of hickory (and corresponding
test data) to use the up-to-date parameter key.
This is a breaking change, however given the very low adoption of ECH,
and the use of the correct `"ech"` key in popular test servers, it
doesn't seem worth trying to maintain backwards compatibility with
earlier draft RFC values.
[0]: https://datatracker.ietf.org/doc/html/rfc9460#section-14.3.2
Since initial support for SVCB/HTTPS RRs landed in hickory-dns, RFC
9460[0] was published:
Service Binding and Parameter Specification via the DNS (SVCB and HTTPS
Resource Records)
This is the definitive reference for SVCB and HTTPS RRs and previous
references to `draft-ietf-dnsop-svcb-https-XX` need to be updated.
Thankfully, it seems as though the implementation did not change
meaningfully from draft-03 and so this commit can largely just update
documentation references and copied quotations to match RFC 9460.
One minor change is worth mentioning: the Encrypted Client Hello (ECH)
aspects of the draft were removed pre-publication and the RFC9460 IANA
registry includes a "reserved" allocation for the `"ech"` key, but no
details on its use. These details are now located in a separate draft,
draft-ietf-tls-svcb-ech-01[1].
Since the code in `svcb.rs` also concerned itself with ECH it now
references draft-ietf-tls-svcb-ech-01 where the ECH specific usage of
service parameter is under specification. Notably the new draft and RFC
9460 both use `"ech"` for the service parameter key for encrypted client
hello configs. Hickory-dns is currently using `"echconfig"`, but this
will be fixed in a follow-up commit to keep this one documentation only.
[0]: https://datatracker.ietf.org/doc/html/rfc9460
[1]: draft-ietf-tls-svcb-ech-01
Pushing branches named "$WHATEVER_dev" will result in CI being run. This
is helpful for those working on a fork that want a quick way to test CI
for their branch before opening a PR.
If we find that we've constructed a Rustls root cert store that has no
trust anchors, return an early error. This makes the problem obvious
and avoids surfacing some other less specific error cause when we first
try to validate a peer certificate with an empty root store.
In order for our new early error to be surfaced correctly the
`name_sever_pool.rs` `parallel_conn_loop` fn needs its error handling
adjusted. Previously it would always compare the new error produced by
trying to build the TLS config against the default error it starts its
loop with, `ProtoErrorKind::NoConnections`. Since the error being
returned is another `ProtoErrorKind`, and the error specificity
comparison considers two `ProtoErrorKinds` equivalent in the general
case, the default error was always returned and the new error thrown
away.
`ProtoErrorKind` is `Clone`, but the `Io` variant holding `io:Error`
runs into trouble with this: since the error can't be cloned we have to
reconstruct it and this is a lossy process: resulting in a "simple"
`io::Error` that only holds the error type from the parent it was cloned
from. This loses important details like the underlying error
source/message.
This commit changes `ProtoErrorKind::Io` to hold `Arc<io::Error>>`
instead. This makes implementing `Clone` trivial - we clone the arc
- and no error information is lost.
