Re: [DNSOP] Draft for dynamic discovery of secure resolvers

Vittorio Bertola <> Mon, 20 August 2018 11:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AE5FC130DFC for <>; Mon, 20 Aug 2018 04:48:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 EW7CQ81M2nqL for <>; Mon, 20 Aug 2018 04:48:42 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D9093130EF1 for <>; Mon, 20 Aug 2018 04:48:40 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0757A6A34C; Mon, 20 Aug 2018 13:48:39 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=201705; t=1534765719; bh=qPlj8DlUao/vn/rc4DuNM+dqyHZ6Qeh64PUfaaZZTes=; h=Date:From:To:In-Reply-To:References:Subject:From; b=B1sluSuTyxhNdAccMjhsD6OQCzLAIj+loG3qCw1FqNMarXDuSrTxgwK+xhTMAktKl 6ZlymCtXQSmu+Ac08jD93ZmitduKn5gpCx9N5kw58N7kVtxix6O9RH2x5DNkWvklq+ OFGFRdjbPuu9HvLML5oG7RFxblV/O99Dih/aIImqyval01+Oa6VhHoq2/Me0qwbcEm g1Eab/ljOWfRUWNw0ijMf+WdF1UygJrETBBmQu03lr5DS82Ud7tO6U9/lh5owTKbKv 6NGhxeQNlBqBYukQ36Q/As44Lgtr3CodsyXToNUpa6tH3iKhDJk/XZSFTOZXqelrEn 44kJcE16aUj1Q==
Received: from null ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id DBA1D3C06F4; Mon, 20 Aug 2018 13:48:38 +0200 (CEST)
Date: Mon, 20 Aug 2018 13:48:38 +0200
From: Vittorio Bertola <>
To: Doug Barton <>,
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
Importance: Medium
X-Mailer: Open-Xchange Mailer v7.10.0-Rev11
X-Originating-Client: open-xchange-appsuite
Archived-At: <>
Subject: Re: [DNSOP] Draft for dynamic discovery of secure resolvers
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 20 Aug 2018 11:48:44 -0000

> Il 19 agosto 2018 alle 19.02 Doug Barton <> ha scritto:
> And Jason, you missed a threat model, which is users who want to bypass their ISP's resolver.

I think that there should be a lot more attention to this "use case" in this discussion. It seems to me that the designers of DoH have in their minds a romantic picture of the dissident in some authoritarian country trying to escape censorship and save her own life, so that being able to bypass the local ISP, obviously run by evil government cronies, would be a good thing. 

However, in most of the world, the reality is that the biggest motivation for people to try bypassing the ISP's resolver is to access illegal Web content that has been filtered out at the DNS level, such as unauthorized gambling websites, illegal pornography, "free" football live streams (which are usually full of malware), etc. - not to mention bots trying to contact their command and control server without incurring into RPZ-based filtering.

If I accepted Ted Lemon's point that publishing a proposed standard (like DoH) implies active endorsement by the IETF, I would wonder why the IETF is actively endorsing a standard that will make this much easier.

> I agree that encrypting from the CMTS to the local resolver isn't that 
> valuable, since (unless I'm missing something) the ISP is the only one 
> that can see that traffic, and they'll be able to log/manipulate the 
> resolver already. So it's unlikely that an ISP would deploy DOH or DOT 
> in the first place, so the idea of a DHCP option to support it isn't 
> necessarily relevant in that environment. That doesn't mean it's not 
> relevant elsewhere.

Well, if I were an ISP, I'd rush to deploy DoH on my consumer resolver so to deprive the browser makers of the excuse "we are redirecting by default your DNS traffic to us because we encrypt it and your ISP does not". I agree that technically speaking there is not a lot of need for this, but DoH (more precisely: the upcoming deployment of DoH in the browsers) is mostly a business and marketing issue, not a technical one.


Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
Office @ Via Treviso 12, 10144 Torino, Italy