I wanted to run a private DNS cache (an "external cache" in Dan Bernstein's
terms, as it is external to the actual client needing a name resolved)
in conjunction with a private DNS server and a public DNS server.
Here's a picture of what I wanted:
192.168.1.5 eth1 - private IP
+-------+ +---------------------+ eth0 - public IP 1.2.3.4
|client |------------| LRP firewall |-----------------
+-------+ | |
| tinydns-public|
| |
| |
|dnscache |
|tinydns-private |
| |
| |
+---------------------+
When I did an out-of-the-box configuration of the dnscache.lrp and
tinydns.lrp packages, I discovered that I was correctly providing
server info on the public interface. However, internal lookups were
failing for all clients (Solaris and Linux) other than my Windows machine,
which in fact was relying on some mysterious Windows mechanisms rather than
pure DNS. I should note that my public and private tinydns servers were
providing somewhat different information, as the public DNS server offers no
details on purely private machines.
Based on the documentation at
http://cr.yp.to/djbdns/faq/cache.html and
http://cr.yp.to/djbdns/faq/cachex.html, it appears that dnscache should
run on a different IP from tinydns to avoid conflicts.
(See the links http://cr.yp.to/djbdns/faq/cache.html#internal
and http://cr.yp.to/djbdns/faq/cachex.html#mixnmatch
for particular details.)
What I had to
do (at a high level) is the following:
1. Set up another (aliased) IP address on the internal interface.
2. Tell the internal dnscache server to listen on the new aliased address.
3. Tell the dnscache server to use the private tinydns server to resolve
queries in the local domain.
4. Add an entry for the new (aliased) IP address to the private tinydns
server data file.
5. Restart everything.
6. Point clients to the dnscache server IP (the aliased one).
My original internal IP address for the LRP firewall was 192.168.1.254.
My private tinydns server continues to listen at this address.
I wanted my dnscache server to listen on 192.168.1.250.
Here's what I had to do to make the above steps work:
1. In /etc/network.conf, add a line:
eth1_IP_EXTRA_ADDRS="192.168.1.250"
(I chose .250 simply because I have some other stuff at .253, .252,
and .251.) I can't find this parameter explicitly documented
anywhere, but it successfully aliases the second IP to the internal
interface.
2. Restart networking to apply this change: /etc/init.d/network reload
(You can use "ip addr" to verify that eth1 is now listening on
multiple internal addresses.)
3. Change dnscache's default listening address to the new one (using the
menus in lrcfg, or editing /etc/dnscache/env/IP), 192.168.1.250
4. Tell dnscache to rely on the tinydns-private server for things in
my own domain (paradosis.com, in my case). There's no lrcfg option
for this. You'll have to manually edit the following files,
replacing the default 127.0.0.1 entry with the address of the
tinydns-private server (192.168.1.254 in my case):
/etc/dnscache/root/servers/paradosis.com
/etc/dnscache/root/servers/1.168.192.in-addr.arpa
(REMEMBER, your domain is probably not paradosis.com. Use your own
domain instead. If your tinydns server is supplying information on
additional domains, you'll have files for those domains, too. For
example if you have a tinydns server supplying info for
paradosis.com and mywiddleteddybear.com, you'll have three files
in that subdirectory: paradosis.com, mywiddleteddybear.com, and
1.168.192.in-addr.arpa)
5. Restart dnscache: /etc/init.d/dnscache restart
6. Edit your tinydns-private server data file to include A and PTR
records for the new dnscache address. You can use lrcfg to do this, or
edit /etc/tinydns-private/root/data directly. In my case, I used:
=dnscache.paradosis.com:192.168.1.250
7. Restart tinydns: /etc/init.d/tinydns restart
8. Back up etc.lrp, tinydns.lrp, and dnscache.lrp.
9. Change the nameserver entries on your client machines to point to the
new dnscache address (192.168.1.250 in my case). For UNIX/Linux,
you'll edit the nameserver line in /etc/resolv.conf. For Windows
machines, edit the TCP/IP network properties and do the obligatory
reboot.
So far, everything on the internal side is working very well, especially
compared to the seemingly random failures I was getting before. It would
be nice to work some of this into the tinydns and dnscache packages, but
Jacques has already done a marvelous job. :)
Does anyone see any problems with this?
Daryl
Daryl L. Biberdorf [EMAIL PROTECTED]
"And if [God] were to withdraw what we may call his
'constructive power' from existing things, they would
cease to exist, just as they did not exist before they
were made." --St. Augustine, City of God, XII.26
_______________________________________________
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
