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 one minute. 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/corp.local 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/dnscache
Note that this feature is very different from BIND's forwarding. BIND sends recursive queries to the target servers; dnscache sends normal iterative queries. If the corp.local servers have delegated sub.corp.local, BIND puts the burden on them to contact the sub.corp.local servers, and fails if the corp.local servers don't support recursion; in contrast, dnscache contacts the sub.corp.local servers directly.
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: Here are some case studies.