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

Michael Richardson <> Wed, 30 March 2011 07:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BD2733A6B23 for <>; Wed, 30 Mar 2011 00:32:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.57
X-Spam-Status: No, score=-1.57 tagged_above=-999 required=5 tests=[AWL=1.029, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AeGNROIUTmAN for <>; Wed, 30 Mar 2011 00:32:53 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7040A3A6B15 for <>; Wed, 30 Mar 2011 00:32:53 -0700 (PDT)
Received: from list by with local (Exim 4.69) (envelope-from <>) id 1Q4pvC-0006YZ-Qu for; Wed, 30 Mar 2011 09:34:31 +0200
Received: from ([]) by with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <>; Wed, 30 Mar 2011 09:34:30 +0200
Received: from mcr by with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <>; Wed, 30 Mar 2011 09:34:30 +0200
From: Michael Richardson <>
Date: Wed, 30 Mar 2011 07:34:20 +0000
Lines: 21
Message-ID: <>
References: <> <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
User-Agent: Loom/3.14 (
X-Loom-IP: (Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/534.10 (KHTML, like Gecko) Chrome/8.0.552.237 Safari/534.10)
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 07:32:54 -0000

Paul Vixie <vixie <at>> writes:
> 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

I'd like to see this too.
A place where I think this is super useful with is lldns/bonjour, for the 
adhoc disconnected case.  I claim to be on the wire, and 
when I do that I include the chain of rrsig/dnskey from . (or whatever anchor 
point you say you already have).