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

Paul Vixie <> Wed, 30 March 2011 08:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DFA9C28C0E5 for <>; Wed, 30 Mar 2011 01:55:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.499
X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dNWwJvAuNEdG for <>; Wed, 30 Mar 2011 01:55:25 -0700 (PDT)
Received: from (unknown [IPv6:2001:4f8:3:bb:230:48ff:fe5a:2f38]) by (Postfix) with ESMTP id A1F6628C0CE for <>; Wed, 30 Mar 2011 01:55:25 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id D84B4A1055 for <>; Wed, 30 Mar 2011 08:57:02 +0000 (UTC) (envelope-from
From: Paul Vixie <>
In-Reply-To: Your message of "Wed, 30 Mar 2011 19:10:29 +1100." <>
References: <> <0CAE569785C163CFE87B957E@nimrod.local><> <>
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: <>
Subject: Re: [dnsext] caches, validating resolvers, CD and DO
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS Extensions working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 30 Mar 2011 08:55:27 -0000

> From: Mark Andrews <>
> 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 ( 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.