IETF Logo Mail Archive

Re: [dnsext] Re: I-D ACTION:draft-vandergaast-edns-client-ip-00.txt

Nicholas Weaver <nweaver@ICSI.Berkeley.EDU> Thu, 28 January 2010 20:22 UTC

Return-Path: <owner-namedroppers@ops.ietf.org>
X-Original-To: ietfarch-dnsext-archive@core3.amsl.com
Delivered-To: ietfarch-dnsext-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B810E28C0FA; Thu, 28 Jan 2010 12:22:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ahiEjqOrPp56; Thu, 28 Jan 2010 12:22:07 -0800 (PST)
Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 249613A6929; Thu, 28 Jan 2010 12:21:42 -0800 (PST)
Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1Naapm-000FbP-UV for namedroppers-data0@psg.com; Thu, 28 Jan 2010 20:19:22 +0000
Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from <nweaver@ICSI.Berkeley.EDU>) id 1Naapk-000Fb9-St for namedroppers@ops.ietf.org; Thu, 28 Jan 2010 20:19:20 +0000
Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id o0SKJFBl022398; Thu, 28 Jan 2010 12:19:15 -0800 (PST)
References: <7c31c8cc1001271556w4918093er6e94e07cb92c4dc4@mail.gmail.com> <6e04e83a1001281107r470b104dj5d3b66919ce69977@mail.gmail.com> <7c31c8cc1001281125l2605b5d0tc528abdb2d35a48@mail.gmail.com> <6e04e83a1001281155y8961ddfy763d4f79d5d45c3f@mail.gmail.com>
In-Reply-To: <6e04e83a1001281155y8961ddfy763d4f79d5d45c3f@mail.gmail.com>
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset="us-ascii"
Message-Id: <4C393F4E-4DAF-4514-ACE4-E0DBB8C63B34@icsi.berkeley.edu>
Content-Transfer-Encoding: quoted-printable
Cc: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>, Wilmer van der Gaast <wilmer@google.com>, namedroppers@ops.ietf.org
From: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
Subject: Re: [dnsext] Re: I-D ACTION:draft-vandergaast-edns-client-ip-00.txt
Date: Thu, 28 Jan 2010 12:19:15 -0800
To: Ted Hardie <ted.ietf@gmail.com>
X-Mailer: Apple Mail (2.1077)
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
List-ID: <namedroppers.ops.ietf.org>
List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with
List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body.
List-Archive: <http://ops.ietf.org/lists/namedroppers/>

On Jan 28, 2010, at 11:55 AM, Ted Hardie wrote:
> And that's the crux of the problem here--this is encouraging
> a part of the infrastructure to pass an association about the query stream
> to an upstream that they didn't before.  Sure, that can be used to provide
> better service.  But it can be used for other things as well, and there seems
> to be no mechanism provided to allow the client to signal its willingness or
> unwillingness to have this invoked on its behalf; without that, I would be
> somewhat reluctant to see it in the wild.

Except this concern is silly in most cases:  The added information flow is from the third party server to the authority server for the domain.

Yet what is the returned value for?  So the client can contact the final server.  

The client has ALREADY given up the privacy to the third party DNS resolver, the additional privacy leakage thereafter would be trivial.

v2.23.0 | Report a Bug | By Email