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

Sean Leach <sleach@wiggum.com> Thu, 28 January 2010 16:31 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 B1B333A6958; Thu, 28 Jan 2010 08:31:37 -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 xqWTm97Xs2vT; Thu, 28 Jan 2010 08:31:36 -0800 (PST)
Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id D046C3A6405; Thu, 28 Jan 2010 08:31:36 -0800 (PST)
Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1NaXC6-000Ds0-W2 for namedroppers-data0@psg.com; Thu, 28 Jan 2010 16:26:11 +0000
Received: from [209.85.221.200] (helo=mail-qy0-f200.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <sleach@wiggum.com>) id 1NaXC0-000Dox-OO for namedroppers@ops.ietf.org; Thu, 28 Jan 2010 16:26:04 +0000
Received: by qyk38 with SMTP id 38so382832qyk.9 for <namedroppers@ops.ietf.org>; Thu, 28 Jan 2010 08:26:03 -0800 (PST)
Received: by 10.224.51.6 with SMTP id b6mr6339125qag.383.1264695962202; Thu, 28 Jan 2010 08:26:02 -0800 (PST)
Received: from gil.pvt.wiggum.com (gil.wiggum.com [75.148.126.99]) by mx.google.com with ESMTPS id 21sm1066897iwn.6.2010.01.28.08.26.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 28 Jan 2010 08:26:01 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Apple Message framework v1077)
Subject: Re: [dnsext] Re: I-D ACTION:draft-vandergaast-edns-client-ip-00.txt
From: Sean Leach <sleach@wiggum.com>
In-Reply-To: <48894.1264695230@nsa.vix.com>
Date: Thu, 28 Jan 2010 09:25:59 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <50A91B20-5AC1-4819-91ED-E5141F068D48@wiggum.com>
References: <7c31c8cc1001271556w4918093er6e94e07cb92c4dc4@mail.gmail.com> <6184.1264657589@nsa.vix.com> <4966825a1001280807i768a33ccs98f809366bce33d8@mail.gmail.com> <48894.1264695230@nsa.vix.com>
To: namedroppers@ops.ietf.org
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 9:13 AM, Paul Vixie wrote:

>> From: Carlo Contavalli <ccontavalli@google.com>
>> Date: Thu, 28 Jan 2010 16:07:05 +0000
>> 
>> On Thu, Jan 28, 2010 at 5:46 AM, Paul Vixie <vixie@isc.org> wrote:
>>> if we're going to add client identity to the query, can we do so in a more
>>> general way?  i'd like to know lat-long, country, isp, language, and
>>> adult/child.  and the ip address should be multiprotocol, covering
>>> ipv6.
> 
>> The doc does cover ipv6, and allows for other protocols to be supported,
>> if necessary.
> 
> great.
> 
>> Rather than adding client identity, what we're trying to do is address
>> a concrete problem that affects CDNs, open resolvers, and many large
>> sites, that for whatever reason, use the source ip of the query to
>> determine which reply to return to the user.
> 
> i don't think that's a general enough solution to be worth standardizing.
> please investigate the larger context of client identity, beyond the needs
> of CDN's.
> 


I have to agree with and Carlo/Wilmer here (no surprise) that we should keep this focused as this is a real (and growing) problem that we (UltraDNS) face all the time as well.  Both from our anycast recursive service and for our auth DNS customers whose end users utilize OpenDNS, Google DNS etc.  There are more and more anycast recursive systems popping up daily it seems, so the problem is only going to get worse.

Adding identity etc. feels like a different problem that doesn't need to be solved with this standard.  Just my .02