Re: lwresd, tsig, and caching

[ted@tednet.nl (Ted Lindgreen)]

[Quoting Edward Lewis, on Apr 11, 20:23, in "lwresd, tsig, and ca ..."]
> 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 ...
> ...

Very interesting, thanks for sharing this with us!

Now for opinions:

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

I guess it helps to give an opinion on the second question first:
 Yes, you have bigger problem if you can not trust localhost. because
 even when you secure the "app <--localhost-->lwresd" communication
 with another TSIG, your hacked "lwresd" can answer whatever it wishes.

Now, with this out of the way, we can simplify the picture above:


 A
    app host      <------------------>     recursive server
                      no TSIG, +cd
    pre-conf keys
    crypto check
 B
    app host      <------------------>     recursive server
                         TSIG
    trusts ad                              pre-conf keys
                                           crypto check

I guess, there will be a third and fourth one also:
 C
    app host      <------------------>     recursive server
                        no TSIG
    hopes ad can                           pre-conf keys
    can be trusted                         crypto check
 D
    app host      <------------------>     recursive server
                      yes/no TSIG
    pre-conf keys                          pre-conf keys
    crypto check                           crypto check

My guess is that all 4 will happen:
A
  The really concerned user, capable enough to setup and maintain
  his/her own security setup. Hopefully this will not be to many
  users, because it may increase DNS load, especially if badly
  setup.

B
  Corporate and other selected user groups, that can rely on a
  capable system administration, who sets up and maintains secure
  recursive servers, and provides the users with TSIG.

C
  The overly majority of random Internet users not being nursed by a
  capable system administration, perhaps concerned, but not concerned
  enough and/or not capable enough to go to catagory A above.
  These people have little choice than to trust a well-known to be
  good administred DNS forwarder, probably the one of their
  (expensive) ISP. This may not be too bad, because of the
  existance of catagory D below.

D
  The "Internet Cops", perhaps professional or self-a pointed, to
  check that the " good administred DNS forwarder" are really doing
  their job properly and raise hell when not.

Now back to a local "lwresd": for the catagories A and D everyone
would really benefit from a solid local daemonprocess to check
and chase and, even more important, cache these results.
I'm not sure if B needs it (I guess TSIG can be added fairly easy
to a stub resolver?), and clearly C keeps using their simple
 stub resolvers.

Regards,
-- Ted.