Re: [dnsext] caches, validating resolvers, CD and DO

Derek Atkins <warlord@MIT.EDU> Thu, 31 March 2011 13:55 UTC

Return-Path: <derek@ihtfp.com>
X-Original-To: dnsext@core3.amsl.com
Delivered-To: dnsext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4A7E3A6B0E for <dnsext@core3.amsl.com>; Thu, 31 Mar 2011 06:55:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.388
X-Spam-Level:
X-Spam-Status: No, score=-101.388 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_13=0.6, 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 FIb7wxvNjH1e for <dnsext@core3.amsl.com>; Thu, 31 Mar 2011 06:55:15 -0700 (PDT)
Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by core3.amsl.com (Postfix) with ESMTP id 8DA5A28C16A for <dnsext@ietf.org>; Thu, 31 Mar 2011 06:55:14 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 382122602C3; Thu, 31 Mar 2011 09:56:51 -0400 (EDT)
Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 06630-07; Thu, 31 Mar 2011 09:56:47 -0400 (EDT)
Received: from pgpdev.ihtfp.org (IHTFP-DHCP-100.IHTFP.ORG [192.168.248.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id 08E8B260024; Thu, 31 Mar 2011 09:56:47 -0400 (EDT)
Received: (from warlord@localhost) by pgpdev.ihtfp.org (8.14.4/8.14.3/Submit) id p2VDuhbt024049; Thu, 31 Mar 2011 09:56:43 -0400
From: Derek Atkins <warlord@MIT.EDU>
To: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
References: <20110330062335.BA8C9DAC3C4@drugs.dv.isc.org> <0CAE569785C163CFE87B957E@nimrod.local> <46410.1301468733@nsa.vix.com> <20110330081029.867FDDAD484@drugs.dv.isc.org> <alpine.LSU.2.00.1103301218140.5244@hermes-1.csi.cam.ac.uk> <005301cbeedc$e9653150$bc2f93f0$@lampo@eurid.eu> <B433F924-C6B8-497C-9D59-79CD5307C84D@icsi.berkeley.edu> <20110330152241.CAA97DB0215@drugs.dv.isc.org> <F50154E3-1D42-4791-B8F1-E04B3B7F85C5@ICSI.Berkeley.EDU>
Date: Thu, 31 Mar 2011 09:56:43 -0400
In-Reply-To: <F50154E3-1D42-4791-B8F1-E04B3B7F85C5@ICSI.Berkeley.EDU> (Nicholas Weaver's message of "Wed, 30 Mar 2011 11:18:13 -0700")
Message-ID: <sjmvcyz1jhg.fsf@pgpdev.ihtfp.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Virus-Scanned: Maia Mailguard 1.0.2a
Cc: Marc Lampo <marc.lampo@eurid.eu>, dnsext@ietf.org
Subject: Re: [dnsext] caches, validating resolvers, CD and DO
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Thu, 31 Mar 2011 13:55:15 -0000

Nicholas Weaver <nweaver@ICSI.Berkeley.EDU> writes:

> On Mar 30, 2011, at 8:22 AM, Mark Andrews wrote:
>>> OH GOD NO!
>>> 
>>> The problem is that the forwarding or caching nameservers are a security =
>>> disaster.  They lie, cheat, and manipulate results with reckless =
>>> abandon. =20
>> 
>> And w/ dnssec you detect this.
>
> Until they strip DNSSEC information.  You MUST validate locally....

I disagree.  I run a local network in my house and run local caching
recursive resolvers.  I have all my hosts on my network resolve through
my local caches.  I run all my machines, therefore I trust my cache.  I
see no reason to *require* all my machines to bypass the local cache.
Moreover, in my case I see no reason to require all my machines to
perform local validation.  I trust myself.

Therefore, calling it a MUST is wrong.

> You want the end client to have its own policy on what to do on DNSSEC
> failure, not be dependent on the resolver's policy, and thus
> validating clients really should use CD with every request.

I agree in principle, however that policy can also be "trust the caching
recursive resolver."  Saying that the client MUST validate does not
allow for this trusting policy.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available