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

bmanning@vacation.karoshi.com Tue, 06 September 2011 20:54 UTC

Return-Path: <bmanning@karoshi.com>
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 CB88121F8EB9 for <dnsext@ietfa.amsl.com>; Tue, 6 Sep 2011 13:54:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.208
X-Spam-Level:
X-Spam-Status: No, score=-6.208 tagged_above=-999 required=5 tests=[AWL=0.391, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 qvQRNsbBTy1u for <dnsext@ietfa.amsl.com>; Tue, 6 Sep 2011 13:54:49 -0700 (PDT)
Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id 4C33221F8EB8 for <dnsext@ietf.org>; Tue, 6 Sep 2011 13:54:49 -0700 (PDT)
Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id p86KtWhn004629; Tue, 6 Sep 2011 20:55:33 GMT
Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id p86KtVlT004628; Tue, 6 Sep 2011 20:55:31 GMT
Date: Tue, 06 Sep 2011 20:55:31 +0000
From: bmanning@vacation.karoshi.com
To: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
Message-ID: <20110906205531.GB4576@vacation.karoshi.com.>
References: <20110830162134.GB84494@shinkuro.com> <CA+9kkMCih-NWxaxBRD+9LphZEb2k+ce8NkNBm6HHubJ1kDO9TQ@mail.gmail.com> <CAMbvoaKFvxqVR2GRYxF_WOctdM=0Pdw35vqKKtDyCePdN3VM8g@mail.gmail.com> <6.2.5.6.2.20110905114918.08670a18@resistor.net> <20110906072857.GA23307@merboo.mamista.net> <CA+9kkMCqp0gMFtVtW95SUYWKKqKZMihzRErkWu7Mcyi5y+K3TQ@mail.gmail.com> <39736B7C-63B4-4C3F-B87F-92D05C7B88AA@icsi.berkeley.edu> <CA+9kkMASFwpNW9J0-9mNkyt+-fgcqPXu4qDK37pQtuqPNHq3KQ@mail.gmail.com> <62A2F704-6DDF-458B-B994-5A0200DE3F03@ICSI.Berkeley.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <62A2F704-6DDF-458B-B994-5A0200DE3F03@ICSI.Berkeley.EDU>
User-Agent: Mutt/1.4.1i
Cc: dnsext@ietf.org
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: Tue, 06 Sep 2011 20:54:50 -0000

On Tue, Sep 06, 2011 at 11:02:15AM -0700, Nicholas Weaver wrote:
> 
> The only information leakage is SUBNET (NOT IP address), TO the authority for the domain.  
> 
> Which would ONLY be an information leakage at all if either:
> 
> a)  The authority is NOT responsible for operating the final server the client eventually contacts 
> b)  The client does NOT use the DNS record to contact a server belonging to the authority
> c)  The client uses a broken tunnel, contacting the final server from a different IP from that used by DNS.

	c) - at one time was very common, most computers had multiple NICs, each with its own IP.
	     in the last decade, it became common for a single NIC with one usable IP, HOWEVER
	     these days, the NIC in my laptop has NINE IPs associated with it (thanks IPv6)...

	     So the channel my machine uses to talk to the DNS likely has little to no relationship
	     with the channel used to talk with other nodes. This is particularly true in walled
	     gardens with DNS lattice... The DNS server has no idea/concept of the topology betwen
	     my node and the target node - This proposal is trying to allow DNS service to 
	     fabricate a synthetic view of a presumed map of Internet topology and then project 
	     that fabrication on its clients.  

	     IMHO, that pretty much exceeds the remit of the DNS. :)

/bill

> 
> 
> 
> And this is ONLY necessary for out-of-path resolvers (eg, Google Public DNS, OpenDNS), where in almost all cases the user has already explicitly opted in!  
> 
> No other resolver really benefits from supporting this anyway, as most of the big nation-spanning ISPs have already gone with a distributed DNS infrastructure, so the IP address of the query to the authority is already giving the authority of the domain information roughly equivalent to what EDNS-client-subnet provides.
> 
> _______________________________________________
> dnsext mailing list
> dnsext@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsext