hannesm
commented
3 years ago The main task here is to figure out a reasonable (alternative?) API - at the moment: connect takes a hostname. The new API should take a (list of) Ipaddr and port numbers (& protocols?), and may reflect in its result type that the resolve action will not be invoked (but that may as well be left for the future).
As of now, usually a host (with a dual stack) has several configuration options: DHCP / DHCPv6 (for IPv4/IPv6 addresses of the nameserver), plus
/etc/resolv.conf(listing nameservers as IP addresses). Now, with the rise of DNS-over-TLS, the configuration is slightly more tricky:And all these three transports for each nameserver. Furthermore, https://datatracker.ietf.org/doc/html/rfc8310#section-6 recommends opportunistic privacy: why not use TLS if available (even without authentication).
So, a DNS client should (incomplete, since DTLS may be another option -- also leaving aside that configuration may be a hostname (bootstrapping issue, since that hostname needs to be resolved)):
And which nameserver and transport to use should be figured out automatically by a mechanism such as happy eyeballs. To avoid dependency cycles, the core of happy-eyeballs needs to be independent of dns(-client). This also means we need separate opam packages for happy-eyeballs, happy-eyeballs-lwt, happy-eyeballs-mirage.