I am going to focus back on the draft itself. While the discussion around centralizing DNS to 3rd party vs local ISP (or any other alternatives) is worth having, it is a fact that most people get their DNS server set using DHCP. the current state is that all you will get are addresses that you can use to query DNS over port 53.
With the advent of recursive DNS servers that can support encryption, it will be useful to signal that to stub resolver. Some ISPs may want to provision their CPE to advertise DoT to their recursive resolvers with cert pining. Other ISPs in regions that heavily offload their DNS to so X.X.X.X provider, would be able to let their customer use the service from such providers, but over an encrypted channel. "power users" may want to configure their home router to publish a set of DNS servers to be used using DoT or DoH. This is definitely not a bullet proof solution, but it seems better than what we currently have and with minimal protocol change (just adding an option). The way I read this, the network owner that in the past would have made the hosts in their network use unencrypted DNS, will now be able to easily promote encrypted DNS. As for feedback on the draft options. - Section 2.3: Why DoH has no option data? The IP from the DNS recursive name server option merely provide an IP to connect to. DoH server may have a cert that will validate for a hostname. The endpoint may or may not be /dns-query . How about alternate ports? It seems a having the URI as part of the data would be useful ( e.g https://dnsserver.example.net/dns-query , https://10.10.10.10:8443/dns-query , https://2001:DB8::1/doh ...) - the draft as is, assumes that port 853 will be used for DoT, 443 for DoH. Being able to provide alternate ports could be a plus - It is not clear to me if the options apply to all nameservers from the dns recursive nameserver option, or if there needs to be 1 option for each nameserver. I could for instance have nameserver1 which does DoT + DoH while nameserver2 does none. In this case, I would get option 147 with option len of 2 for the first server, followed by option 147 with option len of 0 for the second one. - A DHCP option should be able to be set multiple time, so one can configure TLS_SPKI with multiple values. May be useful for rotations and such. Manu On Sat, Aug 18, 2018 at 2:17 PM Marek Vavruša <mvavrusa= 40cloudflare....@dmarc.ietf.org> wrote: > 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 >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
