Interland DNS
Authoritative Testing

Query performance.

For BIND, cache performance is the same is query performance because BIND reads all the zone files in at start time and serves them from it’s cache. For djbdns, we need to test the query performance of tinydns which will be serving all the authoritative data. We’ll do this by creating a data file for tinydns that serves all the reverse space within 216.122 and point dnsfilter at it (just like in the cache testing). Record all the following data from each run:

Server:
# services start
# watchme.sh ; monitors server CPU and RAM usage.

Client:
# time dnsfilter < iplist-b > b1.out
# time dnsfilter < iplist-b > b2.out
# time dnsfilter < iplist-b > b3.out

Record the results and then proceed to the next dns server (BIND 8) and finally for (BIND 9). Follow the exact same tests as above except alter the commands used to start and stop BIND as documented above.

65,536 queries (Class B) – FreeBSD - 1 client
Server start RAM end RAM CPU Time qps
tinydns 1 1 72 18 3641
tinydns 1 1 74 18 3641
tinydns 1 1 72 18 3641

65,536 queries (Class B) – Solaris – 1 client
tinydns 2 2 96 159 412
tinydns 2 2 97 159 412
tinydns 2 2 96 159 412

As contrasted by dnscache, tinydns isn’t significantly affected by logging. Whereas dnscache chewed through disk space like it was a blue light special, tinydns is fairly lightweight. I first ran the tests with logging on (because I forgot to turn them off) and the times for the runs were at 19 seconds each. With logging off, it dropped to 18 seconds. Full logging with tinydns is not as expensive as I had guessed.