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

Jelte Jansen <> Wed, 30 March 2011 11:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2EBD428C126 for <>; Wed, 30 Mar 2011 04:59:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YPM9imgfL2eE for <>; Wed, 30 Mar 2011 04:59:49 -0700 (PDT)
Received: from ( [IPv6:2001:500:60::65]) by (Postfix) with ESMTP id E36F828C12F for <>; Wed, 30 Mar 2011 04:59:48 -0700 (PDT)
Received: from ( [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "", Issuer "ISC CA" (verified OK)) by (Postfix) with ESMTPS id 5981A5F9891; Wed, 30 Mar 2011 12:01:13 +0000 (UTC) (envelope-from
Received: from [IPv6:2001:df8:0:16:222:43ff:fe24:8028] (unknown [IPv6:2001:df8:0:16:222:43ff:fe24:8028]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by (Postfix) with ESMTPSA id 2B923216C33; Wed, 30 Mar 2011 12:01:09 +0000 (UTC) (envelope-from
Message-ID: <>
Date: Wed, 30 Mar 2011 14:01:04 +0200
From: Jelte Jansen <>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20110223 Thunderbird/3.1.8
MIME-Version: 1.0
To: Paul Vixie <>
References: <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
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 11:59:50 -0000

Hash: SHA1

> the wire change i would like is wholly different.  since clients should
> not need to add caches when they add validation, i'd like the chain of
> rrsig and dnskey to be sent from the recursive server to the stub,
> everything it takes to validate the answer.  to do this, a new EDNS
> option would allow the client to express its closest trust point.  so if
> the client already knows (in a current-transaction cache that is not
> shared with other applications or transactions on the client host) it
> has a valid dnskey for and it's asking for
> then the only RRSIGs or DS/DNSKEY's it needs are for
> and

Note that this makes the assumption that that is actually the trust
point that has a validatable chain, and not a failing one while there is
a higher trust point that would lead to succesful validation (yes yes,
this may or may not be good or bad or local policy or whatever, cue
discussion for multiple chains where some fail).

> again, if we're going to change the servers by adding support for some
> new wire element, let's just make the server do the right kind of failure
> avoidance.  and if we're going to add a new wire element let's have it be
> one that lets cacheless stub validation work.

i would also like to see something like this, btw.

Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla -