IETF Logo Mail Archive

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

Paul Wouters <paul@xelerance.com> Mon, 25 October 2010 17:08 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 912AE3A6A62; Mon, 25 Oct 2010 10:08:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.395
X-Spam-Level:
X-Spam-Status: No, score=-2.395 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599]
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 qUKsBRSko-ch; Mon, 25 Oct 2010 10:08:50 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9DB7B3A6A34; Mon, 25 Oct 2010 10:08:50 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1PAQUS-000I2f-Dv for namedroppers-data0@psg.com; Mon, 25 Oct 2010 17:05:44 +0000
Received: from newtla.xelerance.com ([193.110.157.143]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from <paul@xelerance.com>) id 1PAQUO-000I24-OJ for namedroppers@ops.ietf.org; Mon, 25 Oct 2010 17:05:40 +0000
Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 272B1C2F9; Mon, 25 Oct 2010 13:05:37 -0400 (EDT)
Date: Mon, 25 Oct 2010 13:05:36 -0400
From: Paul Wouters <paul@xelerance.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)
In-Reply-To: <8D01F5E3-F863-4873-BB0E-654FA89983F7@virtualized.org>
Message-ID: <alpine.LFD.1.10.1010251302160.6683@newtla.xelerance.com>
References: <C8EA875A.83BA%roy@nominet.org.uk> <8D01F5E3-F863-4873-BB0E-654FA89983F7@virtualized.org>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
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, 24 Oct 2010, David Conrad wrote:

>> The end-game will be applications doing their own resolving. Real control.
>> No third party dependencies. No favors to ask.
>
> And greatly reduced caching.

Why?

unbound already supports a changing forwarder statement via unbound-control, and
even deals with the forwarder changing between DNSSEC (in)capable forwarders. And
it also detects stripped DNSSEC data.

So why can't you use DHCP obtained resolvers as forwards (and thus their cache)
AND do DNSSEC processing yourself?

And if you'd have to remove a bad forwarder, well then that cache was malicious
anyway and it should not get any usage to begin with.

Paul

v2.23.0 | Report a Bug | By Email