[dns-operations] DNSSEC impact on applications was Re: security-aware stub resolver
davidb at verisign.com
Tue May 27 14:04:32 UTC 2008
On May 27, 2008, at 9:48 AM, David Conrad wrote:
> 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
>> 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
>> 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...
Size: 3899 bytes
Desc: not available
More information about the dns-operations