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

Nicholas Weaver <nweaver@ICSI.Berkeley.EDU> Mon, 01 February 2010 15:42 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 A9B0C28C15C; Mon, 1 Feb 2010 07:42:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.426
X-Spam-Level:
X-Spam-Status: No, score=-106.426 tagged_above=-999 required=5 tests=[AWL=-0.127, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 CCC8UFJATIYb; Mon, 1 Feb 2010 07:42:14 -0800 (PST)
Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 8D29A28C13E; Mon, 1 Feb 2010 07:42:14 -0800 (PST)
Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1NbyKr-000LHF-9z for namedroppers-data0@psg.com; Mon, 01 Feb 2010 15:37:09 +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 1NbyKY-000LEu-KR for namedroppers@ops.ietf.org; Mon, 01 Feb 2010 15:36:50 +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 o11FZ5JK004534; Mon, 1 Feb 2010 07:36:04 -0800 (PST)
Subject: Re: [dnsext] Re: I-D ACTION:draft-vandergaast-edns-client-ip-00.txt
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset="utf-8"
From: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
In-Reply-To: <4B66E441.6090104@nic.cz>
Date: Mon, 01 Feb 2010 07:36:04 -0800
Cc: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>, namedroppers@ops.ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <1A458DCC-DE62-4B65-A8DC-092B451485ED@icsi.berkeley.edu>
References: <7c31c8cc1001271556w4918093er6e94e07cb92c4dc4@mail.gmail.com> <4B66E441.6090104@nic.cz>
To: Ondřej Surý <ondrej.sury@nic.cz>
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 Feb 1, 2010, at 6:25 AM, Ondřej Surý wrote:
> On 28.1.2010 00:56, Wilmer van der Gaast wrote:
>> Hello everyone,
>> 
>> I spoke to Olafur about this idea in Hiroshima last year. I'm afraid
>> the deadline for Anaheim already passed, but we hope we can discuss it
>> on-line in the meantime and decide if it should become a WG item in
>> Maastricht later this year.
>> 
>> To summarize the I-D: It specifies an EDNS0 option that carries IP
>> address information (by default only the first 24 bits to preserve
>> privacy) of the user that triggered a DNS resolution. This should
>> allow authoritative nameservers that give geo-targeted responses to be
>> more accurate, even in cases where the resolver and its users aren't
>> close to each other. To preserve the ability to cache such responses
>> efficiently, the option in the response can indicate which exact
>> subnet it should be cached for.
>> 
>> Comments are more than welcome.
> 
> #1: There should be a way how to ask recursive resolver if he has set edns-client-ip on query or not, so end client knows if authoritative server knows his IP or not. (let's call it stalk flag)
> 
> 
> On 28.1.2010 20:02, Nicholas Weaver wrote:
> >> it's not worth a global upgrade to DNS in its current form.
> >
> > It can be done WITHOUT a global upgrade: you can do it with JUST
> > upgrades to the recursive resolvers and authorities desiring such
> > behavior, see my note on fallbacks from the resolver point of view.
> 
> No you can't.  Since all end users would loose privacy from day zero, since this proposal is opt-out, not opt-in.  Therefore you need to do a global upgrade.

I still don't get what your obsession is here:  DNS is already horrible from a privacy perspective, and third party resolvers make it worse:

OpenDNS specifically keep IP adresses for two days, and aggregate information beyond it.

Google Public DNS is roughly the same, and Google's public DNS is specifically FOR aggregate discovery of information.  Third party DNS costs money, and the ONLY money Google makes from Public DNS is as the result of data mining information.

If you want privacy, you DO NOT USE THIRD PARTY DNS!

And there is no real benefit for network-provided DNS to use this feature.



The leakage to upstream authorities unrelated to the final name in this draft is primarily through the design decision of DNS where the whole query is sent to the upstream authority (and typos etc).

Except in the case of third party resolvers, the upstream authorities and typo authorities is going to effectively get this level of information anyway (because of the direct DNS resolver identity tends to convey most of this outside the 3rd party resolver case, after all, thats WHY this draft is proposed!), and you're assuming this information doesn't cache more (so the upstream authorities don't see most of this).


DNS is specifically used so the end system can talk to the end site, so leakage from the end user to the end authority (and in most cases, the typo authority when it doesn't NXDOMAIN, and how many typos nxdomain these days?) is a complete nonissue.



Basically, if you want privacy of your IP, you don't do normal DNS, you HAVE to use the same mechanism for DNS that you use to provide the same privacy of your IP for your final traffic or some other mechanism.  

EG, route the request through your web proxy or an open proxy.  

Some 3%+ of NATs out there we tested will proxy external DNS requests (and a few of those even have a full recursive resolver), so route your request through THEM.  

Or Tor.  Or the squid proxy you're using for your HTTP traffic, or....


The existing DNS infrastructure would be so bad by your query (after all, the goal is to basically put third party DNS on the same footing as first-party DNS, which puts it on the same privacy footprint!) that you need to add significant privacy preservation to the DNS architecture before you should consider this a threat.