[prev in list] [next in list] [prev in thread] [next in thread] 

List:       djbdns
Subject:    Re: Too many proxy servers spoil the LAN
From:       Michael Hall <mhall () riverside ! org>
Date:       2001-04-28 18:41:48
[Download RAW message or body]

On Sat, Apr 28, 2001 at 03:31:17AM +0100, Jonathan de Boyne Pollard wrote:

<snip>

> Your setup is poor if the goal is to have a "large site cache".  This is
> because your forwarding proxy DNS servers on "ukia" and "nowthen" forward both
> to your forwarding proxy DNS server on "lodi" *and* to your ISP's (resolving)
> proxy servers.  Remember that "dnscache" picks IP addresses at random from the
> lists in .../servers/* every time that it makes a query.  As a consequence,
> two-thirds of the time the proxy servers on "ukia" and "nowthen" will go
> directly to your ISP's proxy servers, bypassing "lodi" completely, even though
> the information requested might already be in "lodi"'s cache.

Since my original message I've made several changes after thinking about things
some more based on the replies I got. Originally I *assumed* that the entries
were used sequentially but I guess I knew better and I had already changed
../root/servers/@ to contain only my external dnscache (209.102.66.11 - lodi)
and added the ISP's servers to /etc/resolv.conf instead. I made some other
changes as well, my current setup:

machine  running   on             running  on            
--------------------------------------------------------
ukiah    dnscache  127.0.0.1      tinydns  209.102.66.10
lodi     dnscache  209.102.66.11     -           -      
nowthen  dnscache  127.0.0.1      tinydns  209.102.66.12

ukiah, nowthen:

../env/FORWARDONLY = 1
../root/servers/@ = 209.102.66.11

/etc/resolv.conf = 127.0.0.1
                   199.217.72.1
		   199.217.72.2

lodi:

../env/FORWARDONLY = not set
../root/servers/@ = list of root servers

/etc/resolv.conf = 209.102.66.11
                   199.217.72.1
		   199.217.72.2

ukiah, lodi, nowthen:

../root/servers/riverside.org = 209.102.66.10
                                209.102.66.12
../root/servers/8-15.66.102.209.in-addr.arpa = 209.102.66.10
                                               209.102.66.12
		   
#1 has been addressed and incorporated.

#2 is partially addressed as the internal (proxying) caches only forward to
   my external (resolving) cache now if its not already in the local cache.
   And if for whatever reason the local cache is down or it couldn't get it
   from the external cache the ISP's servers will be used (/etc/resolv.conf)

#3 is irrelevant as its not forwarding anymore.

#4 has been addressed and is a resolving server now. Its still a public
   address though, although that will be changed to an internal address
   as its only meant for my network use (and possibly some limited trusted
   users).

Overall its a more optimal (and technically correct?) setup now. Each machine
still has its own cache, either internal (forwarding to external) or 
external (resolving from roots). The ISP's servers are out of the picture
unless for some reason my caches aren't available and they are then called
via the 'resolv.conf'. As I see it now the remaining concerns are changing
the external cache to an internal address (or provide access controls to it)
on my network and eventually work on the ISP's end of things (more below).

> 1.	Remove the 199.*.*.* addresses from the IP address lists used by the
> forwarding proxy servers on "ukia" and "nowthen".  Have them forward *only* to
> the forwarding proxy server on "lodi".

<snip>

> 2.	Have individual forwarding proxy servers on 127.0.0.1 on each machine, each
> forwarding directly to the ISP's resolving proxy server, rather than funneling
> through a single central proxy server on your end of the link.

<snip>

> 3.	Have one, single, forwarding proxy server on 209.102.66.11 (or - better
> still - a private non-loopback IP address assigned to that machine that is
> internal to your LAN, such as one in the 10.*.*.* network for instance), and
> list it in all of the /etc/resolv.conf files on all machines.  Don't run proxy
> servers on any other machines.

<snip>

> 4.	Have one, single, *resolving* proxy server on 209.102.66.11 (or - better
> still - a private non-loopback IP address assigned to that machine that is
> internal to your LAN, such as one in the 10.*.*.* network for instance), and
> list it in all of the /etc/resolv.conf files on all machines.  Don't run proxy
> servers on any other machines.

> The more important consideration here, though, is that your ISP is running
> BIND.  As such, you have no guarantee that your ISP is running a secure proxy
> DNS server that is immune to cache poisoning.  It is important to remember
> that using a forwarding proxy DNS server implicitly places one's trust in the
> proxy DNS servers that one is forwarding to.  One should only use a proxy DNS
> server run either by onesself, or by someone that one trusts (because they are
> close friends, for example, or someone whom one can trust for other reasons
> such as having a service contract with them).  If you don't trust your ISP to
> provide reliable resolving proxy DNS service (And since it uses BIND for this
> there may be good reason not to do so, even though it is your employer.  (-:)
> then your only choice is to run the resolving proxy DNS server *yourself*.
> 
> Since this means that the resolving proxy DNS server is on the near end of the
> expensive link, you no longer need any forwarding proxy DNS servers.  Your DNS
> clients can just talk directly to your resolving proxy DNS server.

Yes, you're absolutely correct and I'm now doing the resolving as such now.
The whole point of all this and setting up djbdns from the start is that I
typically use my network as a guinea pig and experimentation before making
changes, etc. at work (my ISP) since I don't like messing up our production
machines for obvious reasons :-) I'm fairly new there and made some fairly
big changes already (dumping sendmail and going to Posftix) and Bind/DNS is
on my hit list now, its a typical legacy setup from years ago and at least
needs to be redone and have the services (content serving/resolving) split
to start with for now, and hopefully migrated to dnscache/tinydns down the
road (depending on how much influence I have or don't have :-)

Appreciate your reply and detailed explanation!!

--
Why did CNN cancel that cool 'Desert Storm' show ?

Mike Hall,
Unix Admin   - Rock Island Communications           <mikeh@rockisland.com>
System Admin - riverside.org                        <mhall@riverside.org>

[prev in list] [next in list] [prev in thread] [next in thread]