Re: [dnsext] Re: EDNS client IP should be opt-in (Was: I-D ACTION:draft-vandergaast-edns-client-ip-00.txt

Michael Graff <mgraff@isc.org> Tue, 02 February 2010 22:11 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 2DD5C3A688D; Tue, 2 Feb 2010 14:11:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 SISZYQxFBvLp; Tue, 2 Feb 2010 14:11:27 -0800 (PST)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 26AE63A68B8; Tue, 2 Feb 2010 14:11:16 -0800 (PST)
Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1NcQur-000NZs-W4 for namedroppers-data0@psg.com; Tue, 02 Feb 2010 22:08:13 +0000
Received: from [2001:4f8:3:36::28] (helo=white.flame.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from <mgraff@isc.org>) id 1NcQun-000NZ9-VE for namedroppers@ops.ietf.org; Tue, 02 Feb 2010 22:08:10 +0000
Received: from white.flame.org (localhost [127.0.0.1]) by white.flame.org (Postfix) with ESMTP id 760A217D1E6; Tue, 2 Feb 2010 22:08:09 +0000 (UTC)
Received: from bigmac.home.flame.org (unknown [IPv6:2001:4f8:fff9:13:21d:4fff:fe47:6790]) (using SSLv3 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by white.flame.org (Postfix) with ESMTPSA id C6E3417D1E5; Tue, 2 Feb 2010 22:08:06 +0000 (UTC)
Message-ID: <4B68A241.3020701@isc.org>
Date: Tue, 02 Feb 2010 16:08:01 -0600
From: Michael Graff <mgraff@isc.org>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1
MIME-Version: 1.0
To: Wilmer van der Gaast <wilmer@google.com>
CC: DNSEXT WG <namedroppers@ops.ietf.org>
Subject: Re: [dnsext] Re: EDNS client IP should be opt-in (Was: I-D ACTION:draft-vandergaast-edns-client-ip-00.txt
References: <7c31c8cc1001271556w4918093er6e94e07cb92c4dc4@mail.gmail.com> <4B66E441.6090104@nic.cz> <4966825a1002010729m32b5ccfel94f7cb09d8b5e458@mail.gmail.com> <20100202113421.GA31244@nic.fr> <4966825a1002020355s41a182edvbc2fc8045af4a36e@mail.gmail.com> <4B681EB5.9040403@nic.cz> <71552.1265143879@nsa.vix.com> <7c31c8cc1002021327l4397502bk647f96813ac37948@mail.gmail.com> <4B689CB8.9030702@isc.org> <7c31c8cc1002021355p6e00eaeeq98b447466549e4ad@mail.gmail.com>
In-Reply-To: <7c31c8cc1002021355p6e00eaeeq98b447466549e4ad@mail.gmail.com>
X-Enigmail-Version: 1.0
OpenPGP: id=BE9E0FA6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
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/>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2010-02-02 3:55 PM, Wilmer van der Gaast wrote:
> Only clients of open resolvers and customers of ISPs with more peering
> points than resolvers will benefit from this. Everybody else can
> completely ignore this extension.

As a client that is likely true.  However, as the topic of this posting
is opt-in, not default config, perhaps that's the important thing to
discuss.

I see the huge benefit large hosting providers get from this extension.
 As a client, I'd benefit hugely from this perhaps, and my iPhone
experience may be better than ever.

However, there is a privacy concern, and that is what the opt-in
discussion is all about.

I also think this is more wide-spread than just the client side.  The
servers will need to be modified to provide address information as well,
and there is no way to do this in AXFR without special changes to group
by address/netmask and add OPT records to AXFR.

I suspect this will affect interop, and no mention of how to tag this
additional data, signal a slave can handle it, nor what happens when a
slave does not handle it is mentioned in the draft.

- --Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAktookEACgkQ+NNi0s9NRJ0ydwCfbJ4soBJ/NHmrFPgdeAfZbmRq
sCQAnRoj2kRwmLGbU56+GQViz0Z7aDRn
=ZPdD
-----END PGP SIGNATURE-----