[ + DNSOP] On Sun, Mar 10, 2019 at 12:31 PM Jim Reid <j...@rfc1035.com> wrote:
> FYI colleagues. The draft below has just been submitted. I've been given > 10 minutes of WG agenda time at IETF104. > I haven't given this a full review yet, but I'd like to note that almost all of this is about concerns around applications (including browsers) deciding to use their own name resolution and bypass the system resolver, and that very little of this document is actually about DoH itself. I think it would be very valuable to not conflate DNS-over-HTTPS (the protocol) with the "applications might choose to use their own resolvers" concerns. As an example: " For most users, DNS resolution is currently part of the service provided by their ISP. With DoH, users can be expected to rely on DoH service providers and are likely to have no business or contractual relationship with those providers." This about the latter, and I *really* think that this is not helpful to use the term DoH to refer to it -- applications have always been able to write code to bypass the system resolver if they had chosen to - for example apps, including browsers, could have equally done this with "plain DNS", DNS-over-TLS, DNS over foo, etc. As an example it appears that the NetFlix apps have been bypassing the system resolvers sinde before the times of DoH. Yes, the Mozilla / CloudFlare experiment used the DoH protocol, but it could queally have used DoT, DNS over IPSec, $whatever. I encourage discussion of the concerns and what the implications of applications doing their own DNS are, but they are different to the DoH protocol - please do not conflate / confuse the two. Someone (it may have been Vittorio Bertola) coined the term DNS-over-Cloud (DoC) to refer to the deployment concerns - while I don't think it is a great term, it is much better than using the the term DoH to refer to all of: 1: the protocol, 2: the deployment concerns, 3: "resolverless DNS", 4: the loss of visibility from encrypting the DNS Also, I think that this topic would be better discussed in the DNSOP WG - the DoH charter (https://datatracker.ietf.org/wg/doh/about/) talks about: "The primary focus of this working group is to develop a mechanism that provides confidentiality and connectivity between DNS clients (e.g., operating system stub resolvers) and recursive resolvers." While it does say: "The working group will analyze the security and privacy issues that could arise from accessing DNS over HTTPS. In particular, the working group will consider the interaction of DNS and HTTP caching." it goes on to say: "In particular, DNSOP will be consulted for guidance on the operational impacts that result from traditional host behaviors (i.e., stub-resolver to recursive-resolver interaction) being replaced with the specified mechanism." So can the document please be updated to discuss either the DoH protocol *or* the larger issues - and if the latter, this document / discussion should happen in DNSOP. W > > A new version of I-D, draft-reid-doh-operator-00.txt > > has been successfully submitted by Jim Reid and posted to the > > IETF repository. > > > > Name: draft-reid-doh-operator > > Revision: 00 > > Title: DNS over HTTPS (DoH) Considerations for Operator > Networks > > Document date: 2019-03-10 > > Group: Individual Submission > > Pages: 17 > > URL: > https://www.ietf.org/internet-drafts/draft-reid-doh-operator-00.txt > > Status: > https://datatracker.ietf.org/doc/draft-reid-doh-operator/ > > Htmlized: https://tools.ietf.org/html/draft-reid-doh-operator-00 > > Htmlized: > https://datatracker.ietf.org/doc/html/draft-reid-doh-operator > > > > > > Abstract: > > The introduction of DNS over HTTPS (DoH), defined in RFC8484, > > presents a number of challenges to network operators. These are > > described in this document. The objective is to document the problem > > space and make suggestions that could help inform network operators > > on how to take account of DoH deployment. This document also > > identifies topics that may require further analysis. > > _______________________________________________ > Doh mailing list > d...@ietf.org > https://www.ietf.org/mailman/listinfo/doh > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop