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

Paul Vixie <> Sun, 10 March 2019 07:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 90EE5129508; Sat, 9 Mar 2019 23:01:36 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5ncX-cqeNmqq; Sat, 9 Mar 2019 23:01:35 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F29AB128766; Sat, 9 Mar 2019 23:01:34 -0800 (PST)
Received: from [IPv6:2001:559:8000:c9:5055:7992:c019:3c37] (unknown [IPv6:2001:559:8000:c9:5055:7992:c019:3c37]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by (Postfix) with ESMTPSA id 9E1B9892C6; Sun, 10 Mar 2019 07:01:34 +0000 (UTC)
To: Warren Kumari <>
Cc: Jim Reid <>, dnsop <>, DoH WG <>
References: <> <> <>
From: Paul Vixie <>
Message-ID: <>
Date: Sat, 09 Mar 2019 23:01:33 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 PostboxApp/6.1.11
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [Doh] [DNSOP] 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 07:01:45 -0000

Warren Kumari wrote on 2019-03-09 22:48:
> [ + DNSOP]
> ...
> 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.

i disagree. as an example:

>    Two primary use cases were considered during this protocol's
>    development.  These use cases are preventing on-path devices from
>    interfering with DNS operations, ...

(from the Introduction of RFC 8484.)

no other off-network RDNS is reachable by malware which somehow gets 
into my network, or BYOD devices that have a coffee-shop configuration, 
or any other rogue purpose which is at odds with me as the operator of 
"on-path devices". i intend to interfere. DoH turns traditional rules on 
their head, and does so _deliberately_.

if the authors of DoH don't want to be lumped in with the "apps 
(malware) that might choose to use their own resolvers" then they ought 
to have designed it to work in concern with local network policy. in 
other words, make it blockable. by explicitly and aggressively taking 
the position they took, they own the followup, including the Reid draft.

i have been away as long as possible, which means i was surprised that 
the IESG was willing to allow a document to standardize hostility 
between me as a parent and my children who are subject to my parental 
controls technology, and between me as a network operator and malware 
authors who can't succeed without bypassing my DNS servers.

but, the cat is out of the bag now, and it's going to be pretty messy. 
please do not blame that mess on jim reid or on his draft.

P Vixie