To:
dnssec@cafax.se
From:
David Blacka <davidb@verisignlabs.com>
Date:
Tue, 11 May 2004 10:12:42 -0400
Content-Disposition:
inline
In-Reply-To:
<6988.1084283845@marajade.sandelman.ottawa.on.ca>
Sender:
owner-dnssec@cafax.se
User-Agent:
KMail/1.6.2
Subject:
Re: dnssec: resolver - application communication
On Tuesday 11 May 2004 9:57 am, Michael Richardson wrote: > >>>>> "David" == David Blacka <davidb@verisignlabs.com> writes: > >> 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. > > David> Failed to get? In your example, I assume that the resolver > David> *got* b.example NS, but failed to validate it. CD=1 is > David> supposed to force the security aware resolver to return what > David> it has, regardless of security status, so if your cache did > David> not return it, then your cache is broken. CD=1 means, IIRC, > David> that the resolver should go fetch it again if it didn't cache > David> the bogus data (which it probably didn't). > > If I ask: > c.b.example. CD=1 > > and my resolver fails to validate b.example, does it continue? Yes. > Consider the question again from the point of view of a broken NS > (vs a broken DS). What do you mean by "broken"? My point is that SASRs do not need to bypass their full resolver, nor do they need to get the entire validation chain back in one round trip. I am not making a statement as to what security aware resolvers should return to applications. -- David Blacka <davidb@verisignlabs.com> Sr. Engineer VeriSign Applied Research