djbdns-related software

Dumpcache

This is a patch to djbdns that will enable you to dump the cache from a running dnscache, or load a previously dumped cache at startup. Together with the patch is a perl program, prettycache.pl, that will display for you a human readable version of a dnscache cache dump.

Configuration

After applying the patch and recompiling, the programs dnscache and dnscache-conf will have been modified.

dnscache now takes three new environment variables: DUMPCACHE, which is the name of the file into which the cache will be dumped; DUMPCACHETMP, which is the name of a temporary file, and SLURPCACHE, which is the name of a cache dump which will be read at startup. Don't forget that dnscache runs chrooted in .../root and under a special uid (dnscache by default).

The modifications to dnscache-conf make it prepare for you a directory .../root/dump with the correct permissions, and set environment variables DUMPCACHE=dump/dumpcache, DUMPCACHETMP=dump/dumpcache.tmp and SLURPCACHE=dump/slurpcache in the env directory.

Slurping

Upon startup, if the variable SLURPCACHE is not present, or if it is present but doesn't point to an existing file, dnscache starts with a blank cache (as it used to). If the file SLURPCACHE exists but can't be read, dnscache aborts. If the file contains at some point incorrect data, the rest of the data is ignored and not entered into the initial cache. Any data whose TTL has expired is not retained either (note that the TTL stored in the cache dump is an expiration date, not a TTL in seconds).

You could for instance have a symbolic link from slurpcache to dumpcache so that the previously dumped cache is loaded at startup.

If the file pointed by SLURPCACHE exists, a line like

@400000003aae843722f41114 slurp 844

will be written to the log at startup, to show the number of cache entries that were slurped. 0 means that no file with the given name was found.

Dumping

To dump the cache, send a SIGALRM to dnscache, for instance by running

svc -a /service/dnscache

A line like

@400000003aae844537504934 dump err 0

will be written to the log. 0 means that all is ok (the dump has been done), 9999 means that the variable DUMPCACHE or DUMPCACHETMP has not been set, any other number is the errno that occured during the dump. Usually you'll get ENOENT or EACCES if you have forgotten that dnscache is chrooted.

Examining a dump

The program prettycache.pl will take a cache dump and display it for you. You'll want to run it through tai64nlocal, or use the -ttl switch to get TTLs (from "now") instead of TAI dates.

Cache structure

The entries are displayed in the order they have been entered into the cache, oldest first. The cache uses hashes internally, with insertion at the head, so that for a given entry (type, domain) only the last one (the most recent one) will be taken into account by dnscache. For instance if you see in the dump

@4000000039c96ec700000000 a a.gtld-servers.net. 198.41.3.38
...
@4000000039ca97ce00000000 a a.gtld-servers.net. 198.41.3.38

only the last entry will be used.

A tool could very well be written to clean things up, contributions are welcome.

Acknowledgements

Felix von Leitner, for his packages of Dan's libraries (http://www.fefe.de/djb/);
Matthias Andree, for his patch to reload the roots (http://home.pages.de/~mandree/djb/dns/). This patch convinced me to use a signal instead of the previous (hacky) method to trigger a dump;
Russel Nelson, for his djbdns.org page of resources;
Dan Bernstein, of course.

Download

the dumpcache patch to djbdns-1.05,
the program prettycache, to visualize a dump.

Last updated 2001/03/13.

Efgé