Re: [Doh] DoH

Adam Roach <> Thu, 28 March 2019 17:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DF8D91202AD for <>; Thu, 28 Mar 2019 10:08:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tV-Kmm2ajhvr for <>; Thu, 28 Mar 2019 10:08:51 -0700 (PDT)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F362C12002F for <>; Thu, 28 Mar 2019 10:08:49 -0700 (PDT)
Received: from ( []) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id x2SH8MaF061105 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 28 Mar 2019 12:08:25 -0500 (CDT) (envelope-from
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=default; t=1553792907; bh=a/sgZjTN8U113WxAFXzRQXdJ/fGEMOK8h00PwKc+ul8=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=k8sEN+WHjL5YqQERMnXM8GUjpQ3mbxoy1Ze1lHUegaQ+cOMV8pYR0UbF92fYF4+xD ngGNbrukoe+QX+CZZoVVknNbxXkWCxdZr7uPLJ+VSH10IEw6JItdknscfOUZNQda1E YIqmaFcLhTz1Uml6US+4DfD7HndQ3VxHIMw3967I=
To: John Carr <>, Patrick McManus <>
Cc: "" <>, "" <>
References: <> <> <>
From: Adam Roach <>
Message-ID: <>
Date: Thu, 28 Mar 2019 18:08:21 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------119E21806CBB1AC342FB0341"
Content-Language: en-US
Archived-At: <>
Subject: Re: [Doh] DoH
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: Thu, 28 Mar 2019 17:08:58 -0000

[speaking as an individual contributor]

John --

The issue you're raising is not inherent to the DoH protocol. Since the 
advent of public DNS servers, which started to gain significant 
popularity with Google's service offering a decade ago [1], the various 
DNS-based approaches of content restriction that you describe in your 
original message have been fairly easily circumventable (e.g. by 
changing the DNS settings on a local machine, using TOR browser, or by 
using a VPN).

There has been significant discussion within the IETF, especially over 
the past few weeks, of some of the operational changes that result from 
the difference between DoH and other means of accessing DNS. These 
changes do have some bearing on sophisticated network operators, such as 
those who administer enterprise networks. For the types of home networks 
you mention, which generally lack professional and dedicated network 
administrators, DoH does not inherently represent any significant change 
to the decade-old status quo resulting from publicly-available DNS.

There has also been some speculation about, and announcements of, future 
behaviors that some applications -- notably, web browsers -- may choose 
to exhibit. While the development of the DoH protocol might have focused 
and potentially accelerated the decisions made by the vendors of those 
applications, it should be noted that the behaviors enabled by DoH are 
possible without any standardized protocol, and that browser vendors in 
particular were almost certainly going to deploy equivalent technology 
regardless of whether such standardization took place. As the IETF 
itself only has that information that has been sent to the DoH mailing 
list, it seems unlikely that you could get any useful answers to the 
questions you raise except for by contacting the vendors of such 
applications through their official public comms channels.



On 3/28/19 17:20, John Carr wrote:
> Many thanks. I represent children’s organizations which do not have  
> the resources to track the complexities or ins and outs of some of 
> these sorts of issues.
> Perhaps there is someone on the list who knows the answer to my 
> question? Or are you saying I must wade through the whole shooting 
> match and work it for myself?
> John
> *From:*Patrick McManus <>
> *Sent:* 28 March 2019 15:56
> *To:* John Carr <>
> *Cc:*;;
> *Subject:* Re: DoH
> Hi John - I cannot speak for the IETF, nor am I in a position to 
> effectively summarize all of the inputs over the year long process in 
> building RFC 8484. However the consensus opinion of that work is 
> reflected in that document. I can also refer you to the datatracker 
> page for the working group which includes the mailing list archives 
> and minutes from in person meetings while doing the work. 
> The final consensus 
> document does contain some related content in section 10.
> Best Regards,
> -Patrick
> On Thu, Mar 28, 2019 at 3:54 PM John Carr < 
> <>> wrote:
>     Hi Both,
>     I refer to the IETF project on DNS queries over HTTPS (DoH)
>     Could you tell me if, in the course of the deliberations which
>     have been taking place within the IETF structures in respect of
>     DoH, any consideration was given, or is being given, to the
>     implications of this standard in terms of its likely impact on
>     filtering solutions which have been implemented either  on routers
>     within individual households, or by ISPs or other access
>     providers, where the purpose of the filtering is either to
>     restrict access to known illegal content or it is to restrict
>     access to content which is considered inappropriate, e.g. for
>     younger family members?
>     Many thanks,
>     John  Carr
>     Secretary
>     Children’s Charities’ Coalition on Internet Safety
> <>
> _______________________________________________
> Doh mailing list