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

Mark Andrews <marka@isc.org> Wed, 30 March 2011 15:21 UTC

Return-Path: <marka@isc.org>
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 37DB23A6B68 for <dnsext@core3.amsl.com>; Wed, 30 Mar 2011 08:21:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 X2noNFt4dnIj for <dnsext@core3.amsl.com>; Wed, 30 Mar 2011 08:21:24 -0700 (PDT)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by core3.amsl.com (Postfix) with ESMTP id 5B8783A6A20 for <dnsext@ietf.org>; Wed, 30 Mar 2011 08:21:23 -0700 (PDT)
Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 0B2665F9891; Wed, 30 Mar 2011 15:22:46 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (unknown [IPv6:2001:df8:0:96:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 0ED5E216C33; Wed, 30 Mar 2011 15:22:44 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id CAA97DB0215; Thu, 31 Mar 2011 02:22:41 +1100 (EST)
To: Nicholas Weaver <nweaver@icsi.berkeley.edu>
From: Mark Andrews <marka@isc.org>
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>
In-reply-to: Your message of "Wed, 30 Mar 2011 07:37:52 PDT." <B433F924-C6B8-497C-9D59-79CD5307C84D@icsi.berkeley.edu>
Date: Thu, 31 Mar 2011 02:22:41 +1100
Message-Id: <20110330152241.CAA97DB0215@drugs.dv.isc.org>
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: Wed, 30 Mar 2011 15:21:26 -0000

In message <B433F924-C6B8-497C-9D59-79CD5307C84D@icsi.berkeley.edu>du>, Nicholas W
eaver writes:
> 
> On Mar 30, 2011, at 6:12 AM, Marc Lampo wrote:
> 
> >=20
> > Mark Andrews <marka@isc.org> wrote:
> >>=20
> >> A validating resolver with direct access to the athoritative servers
> >> can work around a number of operational errors by being able to
> >> retry the query with different servers.
> >=20
> > =46rom the security point of view, letting "resolvers" (on end-user =
> PC's)
> > have access to authoritative servers is not a good idea.
> > End-users should forward there queries to (internal ?) forwarding or
> > caching name servers (only).
> 
> 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.
 
> Its not just NXDOMAIN wildcarding, we now have multiple ISPs which use =
> DNS to man-in-the-middle search properties (google, yahoo, bing), =
> redirecting traffic to a unknown THIRD party, for unknown reasons!

And w/ dnssec you detect this.
 
> Thus end systems should be prepared to bypass these cesspools at the =
> drop of a hat whenever necessary.  The caching/forwarding architecture =
> in DNS has proven itself to be a security disaster, as its has proven to =
> be an active man in the middle on DNS but can not be a MitM on normal =
> traffic.
> 
> 
> 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.
 
> 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.

> This way, DNS is on the same security level as the rest of the traffic: =
> controllable only by a direct MitM. =20
> 
> And mandating that it still be used in cases of DNSSEC failure is a bad =
> idea:  When DNSSEC fails, and its due to adversarial action, its that =
> caching/forwarding service that is most likely to be responsible.

> [1] The "security" policy you desire however can be maintained if the =
> following rule is added on client validation:
> 
> IF No DNSSEC information AND Can not contact ANY authority
> THEN:
> Accept the results from the configured recursive resolver blindly,=20
> 
> Because you have no choice in the matter as your network is controlled =
> by a direct MitM who's blocking all DNS except through the configured =
> resolvers.
> 
> 
> [2] Except for things like key material or other new RRs which are not =
> used to determine which host to contact.=
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org