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

Warren Kumari <> Sun, 10 March 2019 06:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E0E0C12787E for <>; Sat, 9 Mar 2019 22:49:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pLOz_OpXEuSY for <>; Sat, 9 Mar 2019 22:49:33 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::72e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EDD72126DFA for <>; Sat, 9 Mar 2019 22:49:32 -0800 (PST)
Received: by with SMTP id y15so974760qki.8 for <>; Sat, 09 Mar 2019 22:49:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EJZXriF7XDqk/0NZqUGa3Wi3ka+QTfXbVGL8JbOsK1Q=; b=ebrnYWx9eU2lpSitzqgItc99nGJiQdgBZPYjMq1BZBanIfxQbqJ00u1KvHSVRR+Fhk BNIn2pmxnKNyyr7wIQ5CsrCh6PQu75lrtMkrQbLscRzebiqPzKAdHT4STVxlSF4I+MXx r3C8087bMCN/y53l3YXPTUbeKP0foCfdjR7RJIXQA97m9tkSwhoaBjHPdY4e500IidZz avTC8QH2IP2F4e1wb/B+leSeyzvpIoDcAoC+uJJPLYNqz+zgUad4cYOsotd3qnkqro7f uTbOZRQKj0JDhX2OjrEwMYKhZTnqDtq8MCWut2DQ0ebgu3NjuhSz1bWmNBJ0UF7lGTO2 fuow==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EJZXriF7XDqk/0NZqUGa3Wi3ka+QTfXbVGL8JbOsK1Q=; b=nbHon9yTlMS4o/o3zAQmxlU483LeuzEHSYayFUzp6QkUwjrlo0ny/wMExw4wG9wnMc Btd2pvRIm4vHZflvmKsAoUoTLxPPc5m7SIGfskNNTbiMapn2vWg7GnU/MvDjcr7b9bAl f/23Xy+GIv0C2P/blnf2od7WH1MKD8iQ4y6782OQWqdrsfTGlXfeMXtkC70ewFh+gHqi OdNtmV2OXOkP8x+/dFq5K7lKkDD4EZeIvaRfSQPvx2pZyUkus4w5QqkPMaYGGTVp60xQ /p9VrnFIBTWmexqvbcTzqr/3uY5GaEQXwsv2YJHCQm3RSOeOcFRyVCuLCwwtkTS6635k BzUw==
X-Gm-Message-State: APjAAAXIHMmkXaPxkYG4nLf7L+wR869vSLq3PSTZTH+K7JDCEXkXOdNS XLlZKjE/Yn8KY1IhRc4cXYBgrGA7BmmK5dUb17rJHkBaJnSkbQ==
X-Google-Smtp-Source: APXvYqzSsZRqcKGn2BWOebZZ9X7+Bo9Tra4afzzYXLU58IDmUzf2sdCBwluHcGuOMKD8XF/aZWMNiHxhHbb516fReqk=
X-Received: by 2002:a37:c50f:: with SMTP id p15mr907375qki.278.1552200571672; Sat, 09 Mar 2019 22:49:31 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Warren Kumari <>
Date: Sun, 10 Mar 2019 15:48:52 +0900
Message-ID: <>
To: Jim Reid <>
Cc: DoH WG <>, dnsop <>
Content-Type: multipart/alternative; boundary="000000000000b1f2c60583b7db8d"
Archived-At: <>
Subject: Re: [Doh] New I-D: draft-reid-doh-operator
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS Over HTTPS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 10 Mar 2019 06:49:36 -0000

[ + DNSOP]

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

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
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 ( talks about:
"The primary focus of this working group is to develop a mechanism that
provides confidentiality and connectivity between DNS clients (e.g.,
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.


> > 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:
> > Status:
> > Htmlized:
> > Htmlized:
> >
> >
> > 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

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