Re: [DNSOP] extension of DoH to authoritative servers

Stephane Bortzmeyer <> Wed, 13 February 2019 14:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6A26B12D861 for <>; Wed, 13 Feb 2019 06:23:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id O_FZPTU2yMst for <>; Wed, 13 Feb 2019 06:23:09 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7AEBA129441 for <>; Wed, 13 Feb 2019 06:23:09 -0800 (PST)
Received: by (Postfix, from userid 10) id E4C1EA06BF; Wed, 13 Feb 2019 15:23:06 +0100 (CET)
Received: by (Postfix, from userid 1000) id 46C6A190673; Wed, 13 Feb 2019 15:19:13 +0100 (CET)
Date: Wed, 13 Feb 2019 15:19:13 +0100
From: Stephane Bortzmeyer <>
To: David Conrad <>
Cc: Paul Vixie <>, dnsop <>
Message-ID: <>
References: <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
X-Transport: UUCP rules
X-Operating-System: Debian GNU/Linux 9.6
X-Charlie: Je suis Charlie
User-Agent: NeoMutt/20170113 (1.7.2)
Archived-At: <>
Subject: Re: [DNSOP] extension of DoH to authoritative servers
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 13 Feb 2019 14:23:11 -0000

On Tue, Feb 12, 2019 at 10:14:19AM -0800,
 David Conrad <> wrote 
 a message of 100 lines which said:

> Why don’t you force folks on your network to install a certificate
> that would allow you to inspect TCP/443 outbound traffic?

There are probably many connected things where this is not
possible. But I don't think blocking DNS resolution (through DoT
blocking or DoH bashing) would help: malware learned a long time ago
how to work even in the most hostile (for them) environment, so
connected things will learn to do the same, in the same way that they
use STUN, TURN and other tricks to work around NAT.

So, I don't think Paul Vixie's plan will work: either you connect only
trusted devices to your network, or you block all outbound traffic for
nodes that must stay local (a thermometer or a camera MUST NOT talk to
the outside world at all).

(And, yes, I know, that today's connected devices talk a lot to remote
nodes. But it is evil.)