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

Nicholas Weaver <nweaver@ICSI.Berkeley.EDU> Wed, 30 March 2011 18:16 UTC

Return-Path: <nweaver@ICSI.Berkeley.EDU>
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 DCB033A6BB2 for <dnsext@core3.amsl.com>; Wed, 30 Mar 2011 11:16:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.556
X-Spam-Level:
X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 nquXK8GPh8C1 for <dnsext@core3.amsl.com>; Wed, 30 Mar 2011 11:16:35 -0700 (PDT)
Received: from taffy.ICSI.Berkeley.EDU (taffy.ICSI.Berkeley.EDU [192.150.187.26]) by core3.amsl.com (Postfix) with ESMTP id 41E8F3A6BAB for <dnsext@ietf.org>; Wed, 30 Mar 2011 11:16:35 -0700 (PDT)
Received: from gala.icir.org (gala.ICIR.org [192.150.187.49]) (Authenticated sender: nweaver) by taffy.ICSI.Berkeley.EDU (Postfix) with ESMTP id 43F0136A032; Wed, 30 Mar 2011 11:18:14 -0700 (PDT)
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>
In-Reply-To: <20110330152241.CAA97DB0215@drugs.dv.isc.org>
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
Message-Id: <F50154E3-1D42-4791-B8F1-E04B3B7F85C5@ICSI.Berkeley.EDU>
Content-Transfer-Encoding: quoted-printable
From: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
Date: Wed, 30 Mar 2011 11:18:13 -0700
To: Mark Andrews <marka@isc.org>
X-Mailer: Apple Mail (2.1084)
Cc: Marc Lampo <marc.lampo@eurid.eu>, Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>, 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: Wed, 30 Mar 2011 18:16:37 -0000

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....

>> Thus probably the best default policy for DNSSEC validation is:
>> 
>> Validate on the client (sending all requests with DO and CD!
> 
> You don't need CD to validate.
> 
>> Don't let =
>> the resolver in between validate, you can't trust it anyway so why have =
>> it waste cycles?). 
> 
> Because you want it to sort out when a authoritative server has stale
> DNSSEC data, authoritative servers that are not dnssec enabled, .....
> It's much easier for the recursive server handle this directly and
> give the stub resolver answers that have been successfully validated.


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.


EG, I'd WANT clients to be able to visit www.dnssec-failed.org IFF the client is able to contact the root, .org, and Comcast's DNS servers directly.

That way, the client knows that it can trust the DNS information to exactly the same degree that it can trust the rest of its network traffic.


>> If local validation successful, accept.
>> 
>> If failed (For any reason, including no DNSSEC information at all [1]), =
>> the client MUST contact the authorities directly (NOT through the =
>> intermediary systems) and accept the results without validation [2].
> 
> That's nice when you can do it, but there are lots of enviroments
> where you can't.  We need to make those deployment senarios work.
> Failures are not alway malicious.

You notice that the proposed policy ONLY causes a failure IFF:

a)  There is an actual DNSSEC failure-to-validate (not simply "no DNSSEC").  
AND
b)  The client is prohibited from contacting authoritative DNS servers directly.