Re: lwresd, tsig, and caching

[Brian Wellington <Brian.Wellington@nominum.com>]

On Wed, 11 Apr 2001, Edward Lewis wrote:

> 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.

And has a different default behavior.  By default, named listens for DNS
queries on port 53 on all interfaces, while lwresd listens for lwres
queries on port 921 of the loopback interface.

> 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.

I wouldn't say lwresd was designed to be used as a forwarding server (any
more than named was), but it can be used as a forwarding server, and this
would be the best use in many situations.

> 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

Either of these would work.  Obviously A would push more of the crypto
verification onto the local machine, which might be more secure, but B
does a better job of caching verified data and reducing the overall work.

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

I would think so.  This is similar to the fact that bind 9 doesn't verify
data on load - if the files on disk don't verify, you have other problems.

> 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.)

If apps want to be more involved with security, there needs to be a richer
API than gethostbyname().  Applications can get call getrrsetbyname() if
they want to do the work of processing A/AAAA/A6 records, and check the
RRSET_VALIDATED bit to see if the data was verified.  If they want to do
the verification themselves, they definitely need to deal with raw DNS
packets.

As for specifying an alternate server, that can be done with lwresd fairly
easily.  If no config file is specified, lwresd will read
/etc/resolv.conf, which will contain the local servers as written by
the DHCP client.  If configured to use /etc/lwresd.conf, the forwarding
servers will not be overwritten by the DHCP client.

Brian