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

[Blacka, David]

On May 27, 2008, at 2:36 AM, Mark Andrews wrote:

>
>>> 	... It queries for DS records it doesn't have in its cache.  ...
>>
>> ok so that's what i meant when i said building per-application  
>> caches would
>> be expensive, compared to per-host or per-LAN caches.

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.

Now, there is no reason why this cache couldn't be at least be one per  
host.  It is true that the current validating stub code available  
today would cache per-application.

But, keep in mind that this cache isn't anything like as large as a  
normal resolver cache.

>>
>
> 	The only additional traffic is between the application and the
> 	local caching resolver.  The wide area traffic does not change.

I think that there would be some slight leakage of DS traffic.  Since  
the stub validator doesn't know where the zone cuts are, at some point  
it will ask for a DS record at a non-delegation point.  Since the  
upstream resolver (probably) never saw the NODATA response at that  
name (because it *does* know where the zone cuts are), it will have to  
emit a DS query.  Of course, this leakage would only occur once per  
resolver per cache period.


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