Re: [dnsext] afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00

SM <sm@resistor.net> Mon, 05 September 2011 20:02 UTC

Return-Path: <sm@resistor.net>
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 CD03421F8B4A for <dnsext@ietfa.amsl.com>; Mon, 5 Sep 2011 13:02:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.572
X-Spam-Level:
X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 hjB4xea3X-hQ for <dnsext@ietfa.amsl.com>; Mon, 5 Sep 2011 13:02:25 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 85A2021F8B28 for <dnsext@ietf.org>; Mon, 5 Sep 2011 13:02:25 -0700 (PDT)
Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5) with ESMTP id p85K40u9018813 for <dnsext@ietf.org>; Mon, 5 Sep 2011 13:04:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1315253045; bh=qi8a1FonrNj5oOybphBUgOIFzjGyiw4dTWHs4oEIGoo=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=sZ6EwAbhLPslqH5WGZGnNYs2CBZVSSQ5G/zfmu2H/Bbgm0Jh08mnT9fnvHuUOpH+x N0DTW1nSVF9DHnvBKkubc6dLVwPYyW78tQg/6TVj2MS8N+2YQ753SiXAuAZHMQlyOa 1T7GZwnxlCIGXCd96kyMqt61o8bNbEAtWR3mR/6A=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1315253045; bh=qi8a1FonrNj5oOybphBUgOIFzjGyiw4dTWHs4oEIGoo=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=azp3PNRLvB6+nOHLvzifUa09tsVfbercs8NfPXI3lUolY32ZWO6izxl8cHFHvXrY0 k7GZFjdWO8HMncPSEci61B+M3KgnmD85XVx2S0/uUkVwNM2PLzVJqrIIcWWW6gPHSD aLUI/BvAOpcbZfk/okbJ0WUlhc13n+ASlz64Qj0M=
Message-Id: <6.2.5.6.2.20110905114918.08670a18@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Mon, 05 Sep 2011 13:03:48 -0700
To: dnsext@ietf.org
From: SM <sm@resistor.net>
In-Reply-To: <CAMbvoaKFvxqVR2GRYxF_WOctdM=0Pdw35vqKKtDyCePdN3VM8g@mail.g mail.com>
References: <20110830162134.GB84494@shinkuro.com> <CA+9kkMCih-NWxaxBRD+9LphZEb2k+ce8NkNBm6HHubJ1kDO9TQ@mail.gmail.com> <CAMbvoaKFvxqVR2GRYxF_WOctdM=0Pdw35vqKKtDyCePdN3VM8g@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Subject: Re: [dnsext] 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: Mon, 05 Sep 2011 20:02:27 -0000

At 10:09 05-09-2011, Wilmer van der Gaast wrote:
>A short discussion of various CDN techniques is, IMHO, outside the
>scope of an RFC describing an EDNS0 option. Instead, we summarised our

If it wasn't for the intended Experimental status, there a lot of 
topics that cannot be said to be out of scope for this proposal.  In 
the reply to the WG Chairs' comments, it was mentioned that HTTP is 
the main focus.  The following DNS services support edns-client-subnet:

   - OpenDNS
   - Google Public DNS

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.  The above-mentioned DNS services are 
are supposed to speed up web browsing.  That only works if the 
content provider can determine the "nearest" HTTP service from where 
the content can be served.  It does not work well when OpenDNS or 
Google Public DNS are used, hence this proposal to provide some 
client identifier through an EDNS option.

If these DNS services were small fry, I doubt that CDNs would bat an 
eye about the problem.  After all, their existing DNS tricks seemed 
to be working quite well.  If using the DNS services result in slower 
web access, it is a disadvantage for these two services.  The fix 
proposed is for the these DNS services to send a client identifier to the CDNs.

 From Section 9.1 of draft-vandergaast-edns-client-subnet-00:

   "Users who wish their full IP address to be hidden can include an
    edns-client-subnet option specifying the wildcard address 0.0.0.0/0"

It was mentioned previously that:

   "We believe, however, that a perfect solution would require
    making changes to how the user agent works. We can't do that, we
    only get to change the nameservers and recursive resolvers."

And:

   "We don't see this option being enabled by anyone else,
    or worse, by default."

Users who do not wish to provide a client identifier will have to 
update their software to support this specification.

As to being the default, if OpenDNS and Google says that it is better 
for the Internet and I say it isn't, who would you believe?

Regards,
-sm