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

Alex Bligh <> Wed, 30 March 2011 08:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 808263A6A2B for <>; Wed, 30 Mar 2011 01:33:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.49
X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DldEbCge5Y+h for <>; Wed, 30 Mar 2011 01:32:59 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8473F3A6AF5 for <>; Wed, 30 Mar 2011 01:32:59 -0700 (PDT)
Received: from [] ( []) by (Postfix) with ESMTPSA id 63E55C560B5; Wed, 30 Mar 2011 09:34:37 +0100 (BST)
Date: Wed, 30 Mar 2011 09:34:36 +0000
From: Alex Bligh <>
To: Mark Andrews <>
Message-ID: <1CA2585509A7CF3EC32560F8@nimrod.local>
In-Reply-To: <>
References: <> <0CAE569785C163CFE87B957E@nimrod.local> <>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Subject: Re: [dnsext] caches, validating resolvers, CD and DO
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Alex Bligh <>
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:33:00 -0000

--On 30 March 2011 18:11:05 +1100 Mark Andrews <> wrote:

> You can have different clocks and different sets of trust anchors.
> The upstream could be treating a zone as insecure but you have a
> trust anchor.  The upstream won't filter stale responses for you
> so it won't cope with a authoritative server with stale data and a
> number of other operational errors that you can work around with
> direct access to the authoritative servers.

Hmmm. I think I understand.

And none of these errors that you can work around with "direct"
access to the authoritative servers are ones that
will end up in the BAD cache? As you'll still see these I think.
RFC4035 s3.2.2
>    If the CD bit is set,
>    the name server side SHOULD return the data from the BAD cache;

Isn't the real answer here just to be a full recursive resolver
and *really* access the authoritative nameservers directly?

I take it you are suggesting that the reissued query should always
have DO set as well as CD.

Alex Bligh