[dns-operations] DNSSEC impact on applications was Re: security-aware stub resolver
davidb at verisign.com
Tue May 27 12:33:20 UTC 2008
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
More information about the dns-operations