Hi, this is a bit off topic, but I figured it would be useful to solicit some early feedback. The current status is that for secure (as in RFC7858 DoT or DoH) resolvers is that there's no discovery mechanism, and it's also out of scope for [0]. At the same time we're seeing real world deployment of clients which either:
a) Probe port 853 and use DoT in opportunistic profile, or probe 443 and trust WebPKI b) Statically configure ADN and/or SPKI pins with well known public resolvers This approach works if there's someone maintaining the statically configured information, as with the dnscrypt-proxy stamp lists [1]. However in most networks the default resolver configuration is pushed through DHCP, so it's the network operator that's in charge for providing default DNS resolver configuration (unless the user is a DNS aficionado and overrides it), but there's currently no good way to provide information required to identify and securely bootstrap a connection to a resolver using DoT or DoH. This draft adds an option to provide a capability list for each configured resolver. The three defined capabilities are TLS with SPKI pin, TLS with ADN, HTTPS. The idea is that DHCP clients reads this information and stores it similarly to resolver list and domain search path for applications to read. Another possible solution for this is to use the system of stamps from dnscrypt-proxy, but it's probably less legible for clients and duplicates information that's already in the recursive DNS nameservers DHCPv4/v6 option. The draft does not change the trust model, an end-user or an application can still disregard DNS recursive nameserver list from DHCP, for better or worse. Here's the draft: https://github.com/vavrusa/draft-dhcp-dprive/blob/master/draft-dhcp-dprive.txt Marek [0]: https://trac.tools.ietf.org/html/rfc8310#section-7.3.1 [1]: https://download.dnscrypt.info/dnscrypt-resolvers/v2/public-resolvers.md _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop