Louwrentius

The most commonly used DNS server software is ISC BIND, the "Berkeley Internet Name Daemon". However, this software has a bad security track record and is in my opinion a pain to configure.

Mr. D.J. Bernstein developed "djbdns", which comes with a guarantee: if anyone finds a security vulnerability within djbdns, you will get one thousand dollars. This price has been claimed once. But djbdns has a far better track record than BIND.

Well, attaching your own name to your DNS implementation and tying a price to it if someone finds a vulnerability in it, does show some confidence. But there is more to it. D.J. Bernstein already pointed out some important security risks regarding DNS and made djbdns immune against them, even before it became a serious world-wide security issue. However, djbdns is to this day vulnerable to a variant of this type of attack and the dbndns package is as of 2010 still not patched. Although the risk is small, you must be aware of this. I still think that djbdns is less of a security risk, especially regarding buffer overflows, but it is up to you to decide which risk you want to take.

The nice thing about djbdns is that it consists of several separate programs, that each perform a dedicated task. This is in stark contrast with BIND, which is one single program that performs all DNS functionality. One can argue that djbdns is far more simpler and easy to use.

So this post is about setting up djbdns on a Debian Linux host as a forwarding server, thus a 'DNS cache'. This is often used to speed up DNS queries. Clients do not have to connect to the DNS server of your ISP but can use your local DNS server. This server will also cache the results of queries, so it will reduce the number of DNS queries that will be sent out to your ISP DNS server or the Internet.

Debian Lenny has a patched version of djbdns in its repository. The applied patch adds IPV6 support to djbdns. This is how you install it:

apt-get install dbndns

The dbndns package is actually a fork of the original djbdns software. Now the program we need to configure is called 'dnscache', which only does one thing: performing recursive DNS queries. This is exactly what we want.

To keep things secure, the djbdns software must not be run with superuser (root) privileges, so two accounts must be made: one for the service, and one for logging.

groupadd dnscache

useradd -g dnscache dnscache

useradd -g dnscache dnscachelog

The next step is to configure the dnscache software like this:

dnscache-conf dnscache dnscachelog /etc/dnscache 192.168.0.10

The first two options tell dnscache which system user accounts to use for this service. The /etc/dnscache directory stores the dnscache configuration. The last option specifies which IP address to listen on. If you don't specify an IP address, localhost (127.0.0.1) is used. If you want to run a forwarding DNS server for your local network, you need to make dnscache listen on the IP address on your local network, as in the example.

Djbdns relies on daemontools and in order to be started by daemontools we need to perform one last step:

ln -s /etc/dnscace /etc/service/

Within a couple of seconds, the dnscache software will be started by the daemontools software. You can check it out like this:

svstat /etc/service/dnscache

A positive result will look like this:

/etc/service/dnscache: up (pid 6560) 159 seconds

However, the cache cannot be used just yet. Dnscache is governed by some text- based configuration files in the /etc/dnscache directory. For example, the ./env/IP file contains the IP address that we configured previously on which the service will listen.

By default, only localhost will be able to access the dnscache. To allow access to all clients on the local network you have to create a file with the name of the network in ./root/ip/. If your network is 192.168.0.0/24 (thus 254 hosts), create a file named 192.168.0:

Mini:/etc/dnscache/root/ip# pwd

/etc/dnscache/root/ip

Mini:/etc/dnscache/root/ip# ls

192.168.0

Now clients will be able to use the dnscache. Now you are running a simple forwarding DNS server and it probably took you under ten minutes to configure it. Although djbdns is not very well maintained in Debian Lenny, there is currently not a really good alternative for BIND. PowerDNS is not very secure (buffer overflows) and djbdns / dbndns has in more than 10 years never been affected by this type of vulnerability.

Introduction

When configuring a Linux RAID array, the chunk size needs to get chosen. But what is the chunk size?

When you write data to a RAID array that implements striping (level 0, 5, 6, 10 and so on), the chunk of data sent to the array is broken down in to pieces, each part written to a single drive in the array. This is how striping improves performance. The data is written in parallel to the drive.

The chunk size determines how large such a piece will be for a single drive. For example: if you choose a chunk size of 64 KB, a 256 KB file will use four chunks. Assuming that you have setup a 4 drive RAID 0 array, the four chunks are each written to a separate drive, exactly what we want.

This also makes clear that when choosing the wrong chunk size, performance may suffer. If the chunk size would be 256 KB, the file would be written to a single drive, thus the RAID striping wouldn't provide any benefit, unless manny of such files would be written to the array, in which case the different drives would handle different files.

In this article, I will provide some benchmarks that focus on sequential read and write performance. Thus, these benchmarks won't be of much importance if the array must sustain a random IO workload and needs high random iops.

Test setup

All benchmarks are performed with a consumer grade system consisting of these parts:

Processor: AMD Athlon X2 BE-2300, running at 1.9 GHz.

RAM: 2 GB

Disks: SAMSUNG HD501LJ (500GB, 7200 RPM)

SATA controller: Highpoint RocketRaid 2320 (non-raid mode)

Tests are performed with an array of 4 and an array of 6 drives.

• All drives are attached to the Highpoint controller. The controller is not used for RAID, only to supply sufficient SATA ports. Linux software RAID with mdadm is used.

• A single drive provides a read speed of 85 MB/s and a write speed of 88 MB/s

• The RAID levels 0, 5, 6 and 10 are tested.

• Chunk sizes starting from 4K to 1024K are tested.

• XFS is used as the test file system.

• Data is read from/written to a 10 GB file.

• The theoretical max through put of a 4 drive array is 340 MB/s. A 6 drive array should be able to sustain 510 MB/s.

About the data:

• All tests have been performed by a Bash shell script that accumulated all data, there was no human intervention when acquiring data.

• All values are based on the average of five runs. After each run, the RAID array is destroyed, re-created and formatted.

• For every RAID level + chunk size, five tests are performed and averaged.

• Data transfer speed is measured using the 'dd' utility with the option bs=1M.

Test results

Results of the tests performed with four drives:

Test results with six drives:

Analysis and conclusion

Based on the test results, several observations can be made. The first one is that RAID levels with parity, such as RAID 5 and 6, seem to favor a smaller chunk size of 64 KB.

The RAID levels that only perform striping, such as RAID 0 and 10, prefer a larger chunk size, with an optimum of 256 KB or even 512 KB.

It is also noteworthy that RAID 5 and RAID 6 performance don't differ that much.

Furthermore, the theoretical transfer rates that should be achieved based on the performance of a single drive, are not met. The cause is unknown to me, but overhead and the relatively weak CPU may have a part in this. Also, the XFS file system may play a role in this. Overall, it seems that on this system, software RAID does not seem to scale well. Since my big storage monster (as seen on the left) is able to perform way better, I suspect that it is a hardware issue.

because the M2A-VM consumer-grade motherboard can't go any faster.

Inotify is a mechanism in the Linux kernel that reports when a file system event occurs.

The inotifywait comand line utility can be used in shell scripts to monitor directories for new files. It can also be used to monitor files for changes. Inotifywait must be installed and is often not part of the base installation of your Linux distro. However, if you need to monitor a directory or some task like that, it is worth the effort. (apt-get install inotify-tools).

Here is how you use it:

inotifywait -m -r -e close_write /tmp/ | while read LINE; do echo $LINE | awk '{ print $1 $3 }'; done

Let's dissect this example one part at a time. The most interesting part is this:

inotifywait -m -r -e close_write /tmp/

What happens here? First, inotifywait monitors the /tmp directory. The monitoring mode is specified with the -m option, otherwise inotifywait would exit after the first event. The -r option specifies recursion, beware of large directory trees. The -e option is the most important part. You only want to be notified of new files if they are complete. So only after a close_write event should your script be notified of an event. A 'create' event for example, should not cause your script to perform any action, because the file would not be ready yet.

The remaining part of the example is just to get output like this:

/tmp/test1234/blablaf

/tmp/test123

/tmp/random.bin

This output can be used to use as an argument to other scripts or functions, in order to perform some kind of action on this file.

This mechanism is specific to Linux. So it is not a OS independent solution.