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

Nicholas Weaver <nweaver@icsi.berkeley.edu> Wed, 30 March 2011 14:36 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 EDA703A6936 for <dnsext@core3.amsl.com>; Wed, 30 Mar 2011 07:36:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.553
X-Spam-Level:
X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 tfjOOIEi-F9I for <dnsext@core3.amsl.com>; Wed, 30 Mar 2011 07:36:14 -0700 (PDT)
Received: from taffy.ICSI.Berkeley.EDU (taffy.ICSI.Berkeley.EDU [192.150.187.26]) by core3.amsl.com (Postfix) with ESMTP id F224A3A687D for <dnsext@ietf.org>; Wed, 30 Mar 2011 07:36:13 -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 28FF436A00D; Wed, 30 Mar 2011 07:37:53 -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>
In-Reply-To: <005301cbeedc$e9653150$bc2f93f0$@lampo@eurid.eu>
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
Message-Id: <B433F924-C6B8-497C-9D59-79CD5307C84D@icsi.berkeley.edu>
Content-Transfer-Encoding: quoted-printable
From: Nicholas Weaver <nweaver@icsi.berkeley.edu>
Date: Wed, 30 Mar 2011 07:37:52 -0700
To: "Marc Lampo" <marc.lampo@eurid.eu>
X-Mailer: Apple Mail (2.1084)
Cc: 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 14:36:15 -0000

On Mar 30, 2011, at 6:12 AM, Marc Lampo wrote:

> 
> Mark Andrews <marka@isc.org> wrote:
>> 
>> 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.
> 
> From 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.  

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!

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!  Don't let the resolver in between validate, you can't trust it anyway so why have it waste cycles?).  

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




This way, DNS is on the same security level as the rest of the traffic: controllable only by a direct MitM.  

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, 

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.