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

Paul Vixie <vixie@isc.org> Thu, 28 January 2010 19:51 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 E4E273A683C; Thu, 28 Jan 2010 11:51:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.562
X-Spam-Level:
X-Spam-Status: No, score=-106.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 aBNxnan4U2d1; Thu, 28 Jan 2010 11:51:05 -0800 (PST)
Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 358463A67FD; Thu, 28 Jan 2010 11:51:05 -0800 (PST)
Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1NaaIh-0008D1-F5 for namedroppers-data0@psg.com; Thu, 28 Jan 2010 19:45:11 +0000
Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from <vixie@vix.com>) id 1NaaIf-0008Ce-4J for namedroppers@ops.ietf.org; Thu, 28 Jan 2010 19:45:09 +0000
Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id C706EA7AEA for <namedroppers@ops.ietf.org>; Thu, 28 Jan 2010 19:45:08 +0000 (UTC) (envelope-from vixie@nsa.vix.com)
From: Paul Vixie <vixie@isc.org>
To: namedroppers@ops.ietf.org
Subject: Re: [dnsext] Re: I-D ACTION:draft-vandergaast-edns-client-ip-00.txt
In-Reply-To: Your message of "Thu, 28 Jan 2010 11:13:29 PST." <EEAAE4BF-BBA9-4141-BECC-A8440715597F@icsi.berkeley.edu>
References: <7c31c8cc1001271556w4918093er6e94e07cb92c4dc4@mail.gmail.com> <6184.1264657589@nsa.vix.com> <4966825a1001280807i768a33ccs98f809366bce33d8@mail.gmail.com> <48894.1264695230@nsa.vix.com> <50A91B20-5AC1-4819-91ED-E5141F068D48@wiggum.com> <52065.1264699087@nsa.vix.com> <FDD5D1103B8EA4D13C4A2C4C@Ximines.local> <EEAAE4BF-BBA9-4141-BECC-A8440715597F@icsi.berkeley.edu>
X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1
Date: Thu, 28 Jan 2010 19:45:08 +0000
Message-ID: <58729.1264707908@nsa.vix.com>
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/>

> From: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
> Date: Thu, 28 Jan 2010 11:13:29 -0800
> 
> > I have to wonder whether the simpler solution to fix this is
> > not just to deploy more resolvers closer to the edge.
> 
> Actually, that IS the fix:  Use the ISP's recursive resolver.
> 
> This is necessary if you want to use something OTHER than the ISP's
> recursive resolver to work well on today's Internet.

i love how somebody else (CDN providers) violate all existing assumptions
(by creating requestor-specific DNS replies) which then makes the Internet
work "less well" for lots of people... who are then constrained from doing
what were previously reasonable things (like using distant recursive servers).

> Do you want third-party DNS providers to not suck for youtube, akamai,
> Google, and a good fraction of the net people use every day?  If so, you
> need this.

if youtube and akamai and google want to suck, let them suck.  they weren't
the first movers and they won't be the last and redrawing the protocol to
support their flawed technical model is not in the global system's interest.

this incoherency should be dealt with more harshly, perhaps by minimizing
TTL to 5 minutes, and sharing a single DNS cache across global providers.

any CDN who relies on what i call "stupid DNS tricks" to deliver their
advantage should upgrade to something at the WWW layer, and leave DNS alone.

especially with DNSSEC coming.