Re: lwresd, tsig, and caching

[Dan Massey <masseyd@isi.edu>]

On Wednesday, April 18, 2001 at 02:32PM, Jakob Schlyter wrote:
| On Tue, 17 Apr 2001, Dan Massey wrote:
| 
| > Ted's Option A:
| >   Having all 2k laptops do their own key chaining and verfication would
| >   be a bad thing in terms of delay, caching, etc...  this doesn't seem
| >   like something that should be encouraged.
| 
| why is this such a bad thing? I would say that local verification is
| better and gives you more control who to trust. in this case, using the
| on-site nameservers at forwarders helps caching and decreases delay.
| 
| in addition to this, I see a problem delegating the verification to some
| nameserver(s) that someone tells me to use (i.e. using dhcp or whatever).
| I might be able to query the server(s) securly, but I have no idea on what
| they trust and why.
| 

You are right, I was not thinking of the forwarders....  there is
an increase in queries and delay, but it is not as bad as I first
thought.

At first, I was picturing 2k laptops all starting at the root and
looking up www.ietf.org (2k total queries to root) vs. the current 
(no dnssec) approach of all 2k laptops sending queries to the 
on-site nameserver that cached www.ietf.org (1 total query to root).  

But instead my laptop can lookup www.ietf.org by sending a query to 
the on-site nameserver (getting back the A record and SIG that I will
check myself).  My laptop will also send the on-site nameserver queries 
asking for the KEY records needed to establish the chain of trust. 
The on-site nameserver should have cached all this information so the 
net result to the outside world is still a single secure query and
I'm still using the on-site cache.  

The number of queries to the on-site namesever will increase.  Each 
laptop will ask for www.ietf.org AND ask for all the KEYs needed for 
the key chaining, but the number of queries sent outside of the meeting
should remain the same.  This seems reasonable.  

The delay will also increase.  If I relied on the on-site namesever for
authenticaion, the first person to lookup www.ietf.org would have 
to wait for the key chaining but the next person would immediately get
a cached, authenticated answer.  Now every laptop has to wait for its
own key chaining to compete, but the key chaining should consist of
queries to and from the on-site nameserver.  Assuming the on-site
nameserver is reasonably fast in replying with cached data, this also
seems reasonable.  

To make this work in practice, the default should be to use whatever
nameservers are in /etc/resolv.conf as forwarders.  Also, these forwarders
must authenticate the data before caching it.  Then I agree that option
A works with what should be an acceptable increase in queries and delay.

Do you also want to use this same approach for your desktop machine or 
does your desktop machine use option B (TSIG to your local nameserver)?
I'm still leaning toward Option B for the desktop...

Dan