To:
dnssec@cafax.se
From:
David Blacka <davidb@verisignlabs.com>
Date:
Mon, 10 May 2004 18:40:52 -0400
Content-Disposition:
inline
In-Reply-To:
<16825.1084224745@marajade.sandelman.ottawa.on.ca>
Sender:
owner-dnssec@cafax.se
User-Agent:
KMail/1.6.2
Subject:
Re: dnssec: resolver - application communication
On Monday 10 May 2004 5:32 pm, Michael Richardson wrote:
> {my appologies for reordering}
>
> >>>>> "David" == David Blacka <davidb@verisignlabs.com> writes:
> David> AFAIK, the way to get the cache to "do the right thing" is
> David> CD=1.
>
> I'm not convinced.
>
> Let take an example:
>
> example. secured
> b.example. supposed to be secured, but expired SIG
> c.b.example. secured
>
> Given, QNAME=d.c.b.example.
>
> one has a failure. How can the SASR even *GET* the SOA/DS/NS record for
> c.b.example?
By querying for it with CD=1.
> If CD=1 will force the security-aware-cachine-resolver to ignore that
> it has already failed to get b.example. NS, then great. But, I haven't
> experienced this kind of thing in the field.
Failed to get? In your example, I assume that the resolver *got* b.example NS,
but failed to validate it. CD=1 is supposed to force the security aware
resolver to return what it has, regardless of security status, so if your
cache did not return it, then your cache is broken. CD=1 means, IIRC, that
the resolver should go fetch it again if it didn't cache the bogus data
(which it probably didn't).
Actually, I'm not sure why a SASR would ever submit a query with CD=0.
--
David Blacka <davidb@verisignlabs.com>
Sr. Engineer VeriSign Applied Research