Re: [Doh] New I-D: draft-reid-doh-operator

[Warren Kumari <[e-mail]>]

[ + DNSOP]

On Sun, Mar 10, 2019 at 12:31 PM Jim Reid <[e-mail]> 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
> [e-mail]
> 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