IETF Logo Mail Archive

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

Mark Andrews <marka@isc.org> Wed, 30 March 2011 11:53 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 4E8A828C11A for <dnsext@core3.amsl.com>; Wed, 30 Mar 2011 04:53:16 -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 KPglorjfZ58V for <dnsext@core3.amsl.com>; Wed, 30 Mar 2011 04:53:14 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by core3.amsl.com (Postfix) with ESMTP id 37C2028C126 for <dnsext@ietf.org>; Wed, 30 Mar 2011 04:53:14 -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.pao1.isc.org (Postfix) with ESMTPS id 24258C9423; Wed, 30 Mar 2011 11:54:49 +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 A498D216C33; Wed, 30 Mar 2011 11:54:48 +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 A5A18DAE0F0; Wed, 30 Mar 2011 22:54:46 +1100 (EST)
To: Paul Vixie <vixie@isc.org>
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><52718.1301475422@nsa.vix.com>
In-reply-to: Your message of "Wed, 30 Mar 2011 08:57:02 -0000." <52718.1301475422@nsa.vix.com>
Date: Wed, 30 Mar 2011 22:54:46 +1100
Message-Id: <20110330115446.A5A18DAE0F0@drugs.dv.isc.org>
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 11:53:16 -0000

In message <52718.1301475422@nsa.vix.com>, Paul Vixie writes:
> > 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.

And in the general case you do ignore the AD bit.  If you are trusting the
AD but you don't need to set DO, AD=1 in the query is enough assuming the
server understands AD=1 which you should know if you are going to trust AD.

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

Which is orthogal to this issue.
 
> > 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.

Which is a seperate issue.

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

The state is not held anywhere.  It's passed back and forward.

> _______________________________________________
> dnsext mailing list
> dnsext@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsext
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

v2.23.0 | Report a Bug | By Email