Answer: This answer assumes that your boot scripts are already running svscan in a /service directory. dnscache relies on svscan to start it and to restart it at boot time.
You will have to make three decisions:
dnscache-conf dnscache dnslog /etc/dnscacheTell svscan about the new service:
ln -s /etc/dnscache /servicesvscan will start the service within five seconds. Finally, replace the nameserver line in /etc/resolv.conf with
nameserver 127.0.0.1
Now test! Use your web browser. Send some email. Check the logs in /service/dnscache/log/main. If you're familiar with DNS querying tools such as nslookup and dig, you can use them to test dnscache before you replace your nameserver lines; simply send queries to server 127.0.0.1.
Answer: Put
10.1.2.5 10.1.2.6into /service/dnscache/root/servers/moon.af.mil and into /service/dnscache/root/servers/10.in-addr.arpa. Make sure that both files are readable by the DNS cache account. Restart dnscache:
svc -t /service/dnscachednscache will contact the internal servers for information about moon.af.mil and 10.in-addr.arpa. If the moon.af.mil servers delegate darkside.moon.af.mil to another server, dnscache will contact that server for information about darkside.moon.af.mil.
Answer: The following answer is for versions 1.03 and above:
echo 1 > /service/dnscache/env/FORWARDONLYReplace the IP addresses in /service/dnscache/root/servers/@ with the IP address of the external cache. dnscache will send recursive queries to the external cache for any information it doesn't have.
If dnscache is already running, restart it:
svc -t /service/dnscache
Answer: Yes. dnscache is designed to work alongside a separate DNS server. If your IP address is 1.2.3.4, you can run a DNS server such as tinydns on IP address 1.2.3.4 to handle incoming DNS queries, and dnscache on IP address 127.0.0.1 to handle outgoing DNS queries.
You can configure BIND version 8 to listen to IP address 1.2.3.4, leaving 127.0.0.1 alone, by adding
options { interface-interval 0; listen-on { 1.2.3.4; }; };to /etc/named.conf and restarting named. Beware that BIND is a security disaster and a reliability disaster.
Answer: dnscache received a duplicate IP address from the server:
% dnsq a ns-ext.vix.com ns-ext.vix.com 1 ns-ext.vix.com: 117 bytes, 1+1+2+2 records, response, authoritative, noerror query: 1 ns-ext.vix.com answer: ns-ext.vix.com 3600 A 204.152.184.64 authority: vix.com 3600 NS ns-ext.vix.com authority: vix.com 3600 NS ns1.gnac.com additional: ns-ext.vix.com 3600 A 204.152.184.64 additional: ns1.gnac.com 130768 A 209.182.195.77Duplicate addresses violate RFC 2181, section 5.5. In this case, the server is BIND; the repetition of the ns-ext.vix.com address is a BIND bug. (The bug appears to have been fixed in BIND 9.1.)
There are reasonable uses of duplicate addresses for load balancing, so dnscache does not go out of its way to remove repeated addresses when they occur.
Answer: Here are some case studies.