[DNSOP] Draft for dynamic discovery of secure resolvers

[Marek Vavruša <[e-mail]>]

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