Re: [DNSOP] EDNS0 clientID is a wider-internet question

Paul Vixie <> Tue, 25 July 2017 08:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4DE7312F280 for <>; Tue, 25 Jul 2017 01:07:54 -0700 (PDT)
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, RP_MATCHES_RCVD=-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 gf-0Zj-mmX5K for <>; Tue, 25 Jul 2017 01:07:52 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C548F127978 for <>; Tue, 25 Jul 2017 01:07:52 -0700 (PDT)
Received: from [] (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by (Postfix) with ESMTPSA id 2DADA61FF3; Tue, 25 Jul 2017 08:07:52 +0000 (UTC)
Message-ID: <>
Date: Tue, 25 Jul 2017 01:07:49 -0700
From: Paul Vixie <>
User-Agent: Postbox 5.0.16 (Windows/20170718)
MIME-Version: 1.0
To: Jacob Hoffman-Andrews <>
CC: Paul Wouters <>, Christopher Morrow <>, dnsop WG <>, Ted Lemon <>, George Michaelson <>
References: <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [DNSOP] EDNS0 clientID is a wider-internet question
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 25 Jul 2017 08:07:54 -0000

Jacob Hoffman-Andrews wrote:
> I agree: The EDN0 Client ID draft seems quite bad from a privacy
> perspective, and I believe it should not be adopted.
> More broadly, enforcing content blocks with DNS is an anti-pattern. If
> we're assuming that the entity doing the content blocking has
> administrative access to DNS clients, they can simply install content
> blockers there.

i think content blocking is a reach -- in your interpretation.

this is about CDN. as in, how to decide which address record set to give 
a dns client, given that all you know is the recursive server address, 
yet you're trying to implement policy for an expected tcp session that 
might immediately follow.

> ... The draft even acknowledges the ineffectiveness of DNS-based content
> blocking:
>>    DNS filtering products are easy circumvented and should not be
>>    considered real security measures.  With commonly available tools it
>>    is trivial to discover the non-filtered DNS responses and use them in
>>    place of the filtered responses.
> So it seems incorrect to propagate a privacy-harming DNS extension that
> is ineffective at its stated goals.

your reasoning is flawed. there are indeed privacy problems here. the 
data miners and data scientists and aggregators of the world will have a 
much better idea which end user a dns request was generated for, in the 
case where all they see is above the recursive not below, and this 
option is used. that's a fine reason to oppose adoption.

but it's got precious little to do with content filtering. as i wrote in 
a recent circleid article, dns-level content filtering will only work 
when end users believe that the recursive name server operator has 
aligned interests, and for that reason one shouldn't say "it's easy to 
bypass" but rather "end-user cooperation is required."

this draft would be more adoption-worthy if it used similar language.

see also:

P Vixie