[dnsext] Address privacy (was Re: afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00)

Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Tue, 06 September 2011 07:58 UTC

Return-Path: <mohta@necom830.hpcl.titech.ac.jp>
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDB9621F84DD for <dnsext@ietfa.amsl.com>; Tue, 6 Sep 2011 00:58:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.023
X-Spam-Level:
X-Spam-Status: No, score=-0.023 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lFzVwQu4iTpe for <dnsext@ietfa.amsl.com>; Tue, 6 Sep 2011 00:58:00 -0700 (PDT)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id C539021F84DF for <dnsext@ietf.org>; Tue, 6 Sep 2011 00:57:59 -0700 (PDT)
Received: (qmail 3832 invoked from network); 6 Sep 2011 08:06:07 -0000
Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 6 Sep 2011 08:06:07 -0000
Message-ID: <4E65D2A7.3010308@necom830.hpcl.titech.ac.jp>
Date: Tue, 06 Sep 2011 16:58:31 +0900
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1
MIME-Version: 1.0
To: dnsext@ietf.org
References: <20110830162134.GB84494@shinkuro.com> <CA+9kkMCih-NWxaxBRD+9LphZEb2k+ce8NkNBm6HHubJ1kDO9TQ@mail.gmail.com> <CAMbvoaKFvxqVR2GRYxF_WOctdM=0Pdw35vqKKtDyCePdN3VM8g@mail.gmail.com> <6.2.5.6.2.20110905114918.08670a18@resistor.net>
In-Reply-To: <6.2.5.6.2.20110905114918.08670a18@resistor.net>
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
Subject: [dnsext] Address privacy (was Re: afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00)
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Sep 2011 07:58:00 -0000

SM wrote:

> The above-mentioned DNS services are are supposed to speed
> up web browsing.

Do you mean that the motivation is to improve TCP performance by
reducing TTL and *NOT* to reduce privacy?

> I might describe the problem as follows. These DNS services provide an 
> "off-net" recursive resolver service for clients. Clients are generally 
> assigned a DNS server that is topologically close to them, i.e. their 
> ISP's DNS service.

Then, as as an IP address of "a DNS server (resolver is the
correct word, here) that is topologically close to them" is
known to OpenDNS and Google Public DNS, why do you have to
be bothered by client subnet?

I'm afraid your actual motivation is *NOT* performance *BUT*
precise geo-location of clients.

Yes, content providers can still know IP addresses of clietns,
from which precise geo-location may be obtained.

However, I can see no reason why clients privacy information
must unnecessarily known by OpenDNS and Google Public DNS
servers.

> That only works if the content provider can
> determine the "nearest" HTTP service from where the content can be
> served.

For performance purpose, HTTP server "nearest" to "a DNS
resolver that is topologically close to them" should be
enough.

						Masataka Ohta