Re: [Doh] ISP position re. hardcoded DoH servers

Ted Lemon <> Thu, 25 July 2019 19:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 750071201CE for <>; Thu, 25 Jul 2019 12:43:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Be9U4kLEqgei for <>; Thu, 25 Jul 2019 12:43:40 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::92d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 925C91201C6 for <>; Thu, 25 Jul 2019 12:43:40 -0700 (PDT)
Received: by with SMTP id 8so20318178uaz.11 for <>; Thu, 25 Jul 2019 12:43:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZRwI6Ww+IbJfES6pni0dRpQvQdGEmhAnhztCNlGpIhg=; b=PE1HO171afkiYbxwEO0GPzNpGs4Rn92/8q3WrDcer+uFunOIG4sxPR4/3292x5be4Q VJqa4xbZEm6QvA2umvX3o/sN68/HDcs09cvNCGtuul3lHqZ2l9KbVQhgcGZqY0x6QNfd ckDkIL3sttzE+LwSQ7Ic/XI3uESaYFOIdf+lowv0IuwCrT/QxNEw1LnFh0LP9ko7qTvf xvzNtrDmQKlKj6Czic0GrMj/V4yfXWMpQ+k8Xwc5ioTZf6a4l6PYq1/c1pKeYPwL6H/O 0GXn9YriCdbLxKyrBmvmEtQdXY1l1Nj/Hz8fXz5Mr8uXctiPGRqLMePxbmiSWhkOtqbI wvtQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZRwI6Ww+IbJfES6pni0dRpQvQdGEmhAnhztCNlGpIhg=; b=eVZ0QoHL/GJiEZvSPnrCdP/BD0BtCPE+1nJ3hsYMjq3GAs//9qC08WuYI9nGooBbF2 a93ygWvML9rHbp177DZjIVEYfISJ+OCNf4RA1LHMIO8+vNnqKWkqXVy/6JQCH9EDG+RE hVhNcAeoynbCHxNyRRoD83rTKV9TRAkn0w0ZZKuPfOCXcSz8tErN9zC031x/4KSnj4mY wbo3N+f/v60wMTOXSvy3dPj+TqHkbAUcFXTFEBVzCrs4Cv9k/rRk4OPR9G927sQ5HgHF Ay4IW9JZ7ihI9L8TmrhGtZqTdIhWULVUXs9TqSxGoztqQLuRiE5szR5JV5n8Hb2VUVjS pg5w==
X-Gm-Message-State: APjAAAWV12tuwJf4k2Te63NrWv2LFXxlFN3dji6zZ/Q1liVk2UCZF+y2 yQflWVGU8vvNjptWMFfeY/26/7WHKONJtA==
X-Google-Smtp-Source: APXvYqzUn2bNNyWvw2zH+541++Sq0H7zzpgVc5eyn/lI1Q+QXGnizxLCQqlmADi7JoqG7IfAWPGywQ==
X-Received: by 2002:ab0:13e2:: with SMTP id n31mr3951853uae.61.1564083819238; Thu, 25 Jul 2019 12:43:39 -0700 (PDT)
Received: from ?IPv6:2001:67c:1232:144:5581:1760:1fae:6b33? ([2001:67c:1232:144:5581:1760:1fae:6b33]) by with ESMTPSA id a23sm2291402vkl.52.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Jul 2019 12:43:38 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (1.0)
From: Ted Lemon <>
X-Mailer: iPhone Mail (16G77)
In-Reply-To: <>
Date: Thu, 25 Jul 2019 15:43:37 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: David Lamparter <>
Archived-At: <>
Subject: Re: [Doh] ISP position re. hardcoded DoH servers
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, 25 Jul 2019 19:43:42 -0000

I think there is an assumption in the approach you are taking that the threat model is centralized resolvers tracking users in a transparent way. I don’t think it’s really a philosophical question to ask whether this is indeed the threat mode about which users should be concerned. 

Sent from my iPhone

> On Jul 25, 2019, at 2:36 PM, David Lamparter <> wrote:
> Hi all,
> it happens to be that I run a small ISP in Germany.  Probably one of the
> smallest, but this does give me the advantage that I have no company
> politics blocking me from things like sending this mail.
> First of all, I'm hoping to implement DoH as soon as possible on our
> ISP-side DNS caches.  When that happens depends on the availability of
> an open source DoH cache, or maybe a DoH to "classical" converter that
> we can stack on top of our existing cache.  We'd throw the DNS queries
> into our existing resolver either way, so I'd actually prefer a proxy
> over a full cache.
> At the same time, I will be working to send an all-users bulletin asking
> our users for their opinions regarding blocking any known hardcoded DoH
> servers in any application.  Since I know our userbase reasonably well,
> I can predict that we will indeed be implementing this.  Since we don't
> look at any layer 4 headers, this will take the form of simple IP/Prefix
> blackhole routes.
> Of course you can try and make this as painful as possible by stacking
> the DoH service onto something that users will miss.  Maybe some
> well-visited front page.  I have no way to isolate DoH traffic from
> other HTTPS traffic, and I wouldn't want it any other way.  But I'll
> still block anything you hardcode, on layer 3.
> I'm doing this because you do not have informed consent from the users
> if you ship a general purpose application with some default DoH server.
> (btw: Single-purpose applications (e.g. Video streaming services) are a
> different story, nothing wrong with hardcoding an e.g. Netflix DoH
> server into the Netflix App.  This is about general-purpose things like
> browsers.)
> The only way you can get informed consent is to present the user with a
> dialog box that asks "Do you want to perform all web name queries
> through <Service>?  [Yes] [No]".  If you do that, I'll turn into your
> advocate instead of adversary.
> And while we're at it, I'd like to point out that a hardcoded DoH in an
> application is probably illegal in Germany.  German law prohibits /
> invalidates "surprising" clauses (BGB §305c), and I'm reasonably
> confident a court will agree that sending all unrelated name lookups to
> a DoH server of the browser vendor's choice is surprising.  The only way
> to fix that is to make it, well, not a surprise.  Maybe ask your lawyers
> before you get the GDPR bill.
> (again, Netflix app sending DoH to Netflix: no surprise.  Browser
> sending all name queries to some DoH: big surprise.)
> (I'm not a lawyer, the above is not legal advice, I'm just pointing out
> there might be a legal angle to this too.)
> It is what it is.  Sorry about that.
> -David
> P.S.: I don't believe it is useful to respond to this mail.  There's
> nothing technical to be discussed here, only philosophy.
> _______________________________________________
> Doh mailing list