lwresd, tsig, and caching

[Edward Lewis <lewis@tislabs.com>]

Recently I visited with the nice folks at Nominum to catch up on DNSSEC in
BIND.  One of the topics that arose was the role of the lwresd.  To start
with, here are some observations:

   1) During the make of BIND - there is "ln named lwresd" (more or less)
      lwresd is basically a copy of named - but reads a different config file.

   2) TSIG has been a sticking point when it comes to using it in general
      queries and responses - where does one store a publically available
      secret on a multi-user machine?

   3) For years now, stub resolvers at a site "pointed" to a recursive server
      to get data, this helped cut down on Internet traffic as the local server
      only did one lookup for potentially many clients.

The new "architecture" of the BIND distribution is to bascially have a
lwresd on each machine instead of a stub resolver.  Since most of the work
in a name server is the resolver, lwresd is basically a copy of named.
"lwresd" means lightweight-resolver-daemon, but this is a slight misnomer.
The daemon is not lightweight, the protocol accessing it is.

The lwresd is designed to be used a forwarding server.  All queries will be
forwarded on to the "legacy" recursive name server as before.  This saves
the Internet undue lookups.

The question that arises is the role of this and DNSSEC.

One set up could be that an application would issue a lwresd call across
localhost to the daemon - without any reference to TSIG or trusted-keys.

The daemon would then forward the query to the recursive server.  The
option here is whether this is done by TSIG (which is no longer publically
needed on the client machine) or with a set of trusted keys.

The recursive server would do the regular work of building an answer.  The
option is whether the answer is cryptographically checked (ad on reply) or
not (cd on query).  Part of this will depend on whether the lwresd plans to
do its own checking or uses TSIG.  Keep in mind that the lwresd machine may
have more or different trusted keys than the recursive server.

So...anyone have opinions on this:

A
   app client<--------------->lwresd<------------->recursive server
               localhost   w/keys, no TSIG           looks up +cd
                          crypto check here
B
   app client<--------------->lwresd<------------->recursive server
               localhost                 TSIG     looks up and checks
                                                   crypto check here

What about feelings that "localhost" is trusted?  Is it true that if
localhost is compromised, you have bigger problems than a volnerable DNS?

What about apps that want to be involved in the security of the DNS lookups
- they would like to display the security of the answer, or say, specify a
secured TSIG/server to use inspite of configured servers.  (As could be the
case with the IETF terminal room & DHCP.)

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: lewis@tislabs.com

Dilbert is an optimist.

Opinions expressed are property of my evil twin, not my employer.