Re: [dnsext] need new flag bit in EDNS, "do me no favours" (DMNF)

bmanning@vacation.karoshi.com Mon, 25 October 2010 03:18 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 7E84F3A68A4; Sun, 24 Oct 2010 20:18:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.389
X-Spam-Level:
X-Spam-Status: No, score=-102.389 tagged_above=-999 required=5 tests=[AWL=0.210, 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 QEwfdy4GYaiu; Sun, 24 Oct 2010 20:18:47 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6AABE3A67F6; Sun, 24 Oct 2010 20:18:47 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1PADWR-000JhR-Av for namedroppers-data0@psg.com; Mon, 25 Oct 2010 03:14:55 +0000
Received: from [2001:478:6:0:230:48ff:fe11:220a] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from <bmanning@karoshi.com>) id 1PADWM-000Je2-8K for namedroppers@ops.ietf.org; Mon, 25 Oct 2010 03:14:53 +0000
Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id o9P3CFfS006797; Mon, 25 Oct 2010 03:12:20 GMT
Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id o9P3CFaC006796; Mon, 25 Oct 2010 03:12:15 GMT
Date: Mon, 25 Oct 2010 03:12:15 +0000
From: bmanning@vacation.karoshi.com
To: David Conrad <drc@virtualized.org>
Cc: Roy Arends <roy@nominet.org.uk>, Paul Vixie <vixie@isc.org>, "namedroppers@ops.ietf.org" <namedroppers@ops.ietf.org>
Subject: Re: [dnsext] need new flag bit in EDNS, "do me no favours" (DMNF)
Message-ID: <20101025031215.GB5614@vacation.karoshi.com.>
References: <C8EA875A.83BA%roy@nominet.org.uk> <8D01F5E3-F863-4873-BB0E-654FA89983F7@virtualized.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <8D01F5E3-F863-4873-BB0E-654FA89983F7@virtualized.org>
User-Agent: Mutt/1.4.1i
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 Sun, Oct 24, 2010 at 04:24:54PM -0700, David Conrad wrote:
> On Oct 24, 2010, at 4:01 PM, Roy Arends wrote:
> > On 10/24/10 6:52 PM, "Paul Vixie" <vixie@isc.org> wrote:
> >> opin?  i can write a short i-d on it before beijing.
> 
> I think a short i-d would be worthwhile.
> 
> > The end-game will be applications doing their own resolving. Real control.
> > No third party dependencies. No favors to ask.
> 
> And greatly reduced caching.

	well, at least a greatly reduced attack surface for any given cache that is 
	compromised.

> The problem with applications doing their own resolving is that the 'real control' implies there is someone at the other end of the application that has the understanding and knowledge to make use of that control.  Haven't we seen the implications of this approach with browsers that ask the end user whether or not to accept an SSL cert?

	yes and no.  if you posit that more than one application runs on a target platform,	
	then all apps that run there can use the same local resolver & validator. No real need
	for each app to take resolution into its own hands.  

	didn't we have this conversation about seven years ago?

--bill

> Regards,
> -drc
> 
>