Re: [Resolverless-dns] Paper on Resolver-less DNS

Anne Bennett <> Mon, 19 August 2019 16:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 08429120043 for <>; Mon, 19 Aug 2019 09:10:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xSEj-DvVzEfU for <>; Mon, 19 Aug 2019 09:10:50 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B1D6512016E for <>; Mon, 19 Aug 2019 09:10:50 -0700 (PDT)
Received: from ( [] port 48337) by (envelope-from (8.13.7/8.13.7) with ESMTP id x7JGAmAQ021371 for <>; Mon, 19 Aug 2019 12:10:49 -0400
Received: from (vin-anne@localhost) by (8.14.7/8.14.7/Submit) with ESMTP id x7JGAmQF024531 for <>; Mon, 19 Aug 2019 12:10:48 -0400
X-Authentication-Warning: vin-anne owned process doing -bs
References: <> <16840451.Gnsi7N2eSB@linux-9daj> <> <9323236.5EVOHOzQma@linux-9daj>
In-Reply-To: <9323236.5EVOHOzQma@linux-9daj>
X-In-Reply-To: Your message of Fri, 16 Aug 2019 21:45:08 -0000
From: Anne Bennett <>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Date: Mon, 19 Aug 2019 12:10:48 -0400
Message-ID: <>
X-Scanned-By: MIMEDefang 2.58 on at 2019-08-19 12:10:49 EDT
Archived-At: <>
Subject: Re: [Resolverless-dns] Paper on Resolver-less DNS
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Resolverless DNS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 19 Aug 2019 16:10:53 -0000

PV = Paul Vixie <>
AB = Anne Bennett <>
ES = Erik Sy <>

PV>>> i'll want to see how the network operator's policies for
PV>>> dns monitoring and filtering will be reliably detected,
PV>>> and respected.

AB>> I would think this to be an impossible task;

PV> this draft in another wg appears to be an attempt at such:
PV> i don't know if it can meet the "reliably detected" threshold though.

I took a quick look at the above draft; it specifies a method
for enquiring about "features of a recursive resolver", but
gives no ideas or guidance as to what such features might
consist of, aside from a brief sentence fragment in the
abstract, "such as whether they perform DNSSEC validation or
are available over transports other than what is defined in
RFC 1035".

It seems to me straightforward to use this mechanism to supply
the information *that* a resolver applies filtering, but I don't
see how it could reasonably *describe* the filtering, since
such a description would essentially almost *be* the filtering.

I think your polite assumption that it could be possible for
resolverless DNS to respect a network operator's policies for
DNS filtering is, well, polite.  ;-)

... which brings us to:

ES>> we talked about possible privacy drawbacks of resolver-less
ES>> DNS. However, did we talk about the privacy risks of using a
ES>> traditional DNS resolver? They can monitor the entire browsing
ES>> activities of a user and present the real privacy problem.

PV> DoT (RFC 7858) corrects that privacy problem and is being deployed.

I dispute the idea that DNS over TLS addresses the privacy
problem of the resolver operator having access to all of a
user's DNS queries.

That being said, I think that stating that traditional DNS has the
"real privacy problem", and implying that resolverless DNS doesn't
suffer from a similar problem, is disingenuous.

If I ask a question and expect an answer, *someone* has to hear my
question!  Who would I rather trust: an ISP whose services I pay for,
or a commercial web site where most likely, I *am* the product? 

Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8                                    +1 514 848-2424 x2285