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

Paul Vixie <vixie@isc.org> Wed, 30 March 2011 08:55 UTC

Return-Path: <vixie@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 DFA9C28C0E5 for <dnsext@core3.amsl.com>; Wed, 30 Mar 2011 01:55:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.499
X-Spam-Level:
X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 dNWwJvAuNEdG for <dnsext@core3.amsl.com>; Wed, 30 Mar 2011 01:55:25 -0700 (PDT)
Received: from nsa.vix.com (unknown [IPv6:2001:4f8:3:bb:230:48ff:fe5a:2f38]) by core3.amsl.com (Postfix) with ESMTP id A1F6628C0CE for <dnsext@ietf.org>; Wed, 30 Mar 2011 01:55:25 -0700 (PDT)
Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id D84B4A1055 for <dnsext@ietf.org>; Wed, 30 Mar 2011 08:57:02 +0000 (UTC) (envelope-from vixie@isc.org)
From: Paul Vixie <vixie@isc.org>
To: dnsext@ietf.org
In-Reply-To: Your message of "Wed, 30 Mar 2011 19:10:29 +1100." <20110330081029.867FDDAD484@drugs.dv.isc.org>
References: <20110330062335.BA8C9DAC3C4@drugs.dv.isc.org> <0CAE569785C163CFE87B957E@nimrod.local><46410.1301468733@nsa.vix.com> <20110330081029.867FDDAD484@drugs.dv.isc.org>
X-Mailer: MH-E 8.2; nmh 1.3; XEmacs 21.4 (patch 22)
Date: Wed, 30 Mar 2011 08:57:02 +0000
Message-ID: <52718.1301475422@nsa.vix.com>
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 08:55:27 -0000

> From: Mark Andrews <marka@isc.org>
> Date: Wed, 30 Mar 2011 19:10:29 +1100
> 
> DO=1 is ALL you require to do your own authentication 99.99999999%
> of the time.

as long as you're planning to ignore the AD bit, sure.  but i still think
that we should be able to ask the recursive validator for a longer chain
since the transaction-level cache will otherwise have to be built up over
many round trips.

> CD=0 DOES NOT mean you are not authenticating.

so noted.

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

i'd like to consider the validating nonrecursive noncaching case first,
since that's the closest analogue to how dns works today.  if i'm in a
hotel room or coffee shop behind NAT and/or firewall and the only UDP/53
destination i can reach is the isp's recursive caching dnssec-aware name
server then i'd like to be able to get everything i need for trustworthiness
of an answer (www.yourbankhere.com IN AAAA) in a single round trip.

> A validating resolver behind a cache does not have this recovery
> path.  The EDNS option is designed to give it that recovery path.

i think that any state held in the validating nonrecursive noncaching
initiator that has to do with the authority servers would be a mistake.