This document lives at http://mandree.home.pages.de/dialup/djbdns.html
This document applies to dnscache-1.00, djbdns-1.01 through -1.05.
djbdns is a collection of DNS client, server (including cache) tools which are secure, fast, have a small memory foot print and are easy to set up. And they haven't caused CERT advisories so far, much unlike BIND.
This document is copyrighted work. It is © copyright 2000/2001 by Matthias Andree.
You may freely copy it as long as you do not modify anything. Daniel J. Bernstein, author of djbdns, is hereby explicitly permitted to include this information into the FAQ accompanying djbdns as long as that software is freely available for all kind of use.
This document shows a procedure meant to simplify the use of dnscache on dial-up connections.
It will alter djbdns' behaviour. Do not contact Daniel J. Bernstein or his dns@list.cr.yp.to mailing list after you have altered your system as shown below. Contact the author of this document instead, find his address at the bottom.
If you are using djbdns (formerly known as dnscache) on a dial-up machine, you may have noticed that Netscape will hang if you're offline and resolving domains takes a lot of time until you finally get the error message. This document outlines how to alleviate this.
There is a way to prevent the timeouts by hiding the root servers' IPs from dnscache and restarting it. After you followed the procedure shown below, djbdns will immediately return "host not found, try again" condition if you try to resolve an external domain while you are off-line. Note that "delegations" for local domains are unaffected, i. e. if you pointed your dnscache to a tinydns at 10.11.12.13 to resolve corp.local domains, dnscache would still resolve these.
This document assumes you have installed a local or external (or both) dns cache as outlined in djbdns' setup instructions. I'm showing this setup for an external cache, but it works for a local cache the same way.
Note the actual difference between internal and external dnscaches consists of the 1.2.3.4 files in root/ip/ in external caches while a local cache only has the root/ip/127.0.0.1 file.
Note that this prodecure will erase djbdns' cache each time you go online or offline.
That should be it. The next time you go online or offline, dnscache will be restarted with the appropriate root servers file @.
Should you for whatever reason want to restore the original behaviour, follow these steps:
Done. DNSCache should behave as before.
If you happen to have erased your original @ file:
Just unpack the original dnscache or djbdns archive and move the @ file into place.
copy /etc/dnsroots.global into place. (Use dnsroots.local instead if you have that.)
I have a patch against djbdns 1.00 here which allows for sending dnscache a SIGHUP to have it re-read its configuration file. It will not lose its cache, if you use svc -h instead of svc -t. Note that on an unpatched dnscache, svc -h will have the same effect as svc -t, namely killing dnscache, which will be re-started by supervise then.
(This will not mention changes to the spelling or layout unless in example code.)