[dns-operations] DNSSEC impact on applications was Re: security-aware stub resolver

[David Blacka]

On May 27, 2008, at 9:48 AM, David Conrad wrote:

> Hi,
>
> On May 27, 2008, at 5:33 AM, Blacka, David wrote:
>> To be clear, what the validating stub needs to cache is validated,
>> trusted DNSKEYs (and, if desired, trusted DS RRs), since it is the  
>> one
>> determining that they are trusted.  Otherwise, it would have to build
>> the trust chain down from the trust anchor every time.
>
> What would be the advantage of having a caching validated stub  
> resolver as opposed to having a full validating caching resolver and  
> using some form of more intelligent IPC to obtain information from  
> that caching resolver?

I don't know that there is an architectural advantage.  But there is a  
practical one: you can build the caching validating resolver now (and,  
in fact, people have), whereas you need to design this IPC for the  
latter suggestion.

>> But, keep in mind that this cache isn't anything like as large as a
>> normal resolver cache.
>
> I'm confused.  Wouldn't it need to do pretty much everything a full  
> validating caching resolver would need to do?

No, it wouldn't.  A validating stub always asks an upstream resolver  
for stuff with CD=1.  It only needs to talk to one resolver, and it  
need not cache all sorts of DNS data that the full resolver needs to  
cache.  As I said, all it needs to cache are DNSKEYs.

I can see where you might get lost, though.  The DNSSEC RFCs all are  
written with certain model in mind, and in that model, DNSSEC  
validation is done as a component of the iterative resolution  
algorithm.  But, it doesn't need to be done that way.

--
David Blacka                          <davidb at verisign.com>
Sr. Engineer          VeriSign Platform Product Development






-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3899 bytes
Desc: not available
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20080527/1c66da2a/attachment.bin>