djbdns: More Than Just a Mouthful of Consonants

 in
Recently released into the public domain, djbdns is a fast and secure replacement for BIND.
Adding DNS Records

Before we begin, let's see how our DNS data would look in the traditional BIND zone file format (versions 8.2 and greater). Listing 1 shows everything needed to configure forward records for example.com and reverse records for 192.168.10.0/24. This includes the configuration for named.conf, as well as the zone data for example.com and 10.168.192.in-addr.arpa. This clocks in at 38 lines of configuration for our two domains.

As I mentioned, tinydns takes a different approach. Instead of defining records separately for forward and reverse zones, tinydns allows you to combine them into single records. Listing 2 contains the exact same configuration from Listing 1, except in tinydns format. Instead of 38 lines of configuration, we now have only ten lines. Let's go over what these lines do.

The first character of each line is used to specify the type of record or records that should be created. A period (.) line tells tinydns that it is authoritative for example.com:

.example.com::linux2.example.com

This creates an SOA (start of authority) record and sets linux2.example.com as an NS record. If an IP address was provided between the two colons, an A record also would have been created for linux2.example.com with that IP address. This one @ line replaces eight from the BIND zone file:

@example.com:192.168.10.15:mail.example.com:0

This line creates two records. An A record is created for mail.example.com with an address of 192.168.10.15, and an MX record is created for example.com pointing to mail.example.com with a distance of 0. Now, let's start defining our hosts:

=linux1.example.com:192.168.10.10
=linux2.example.com:192.168.10.20
=linux3.example.com:192.168.10.30

These lines each create two records. For example, the first line creates an A record for linux1.example.com with an address of 192.168.10.10 and a PTR record (a reverse record) for 10.10.168.192.in-addr.arpa pointing to linux1.example.com. If you manage both the forward and reverse zones for your network, you probably already can see what a huge time-saver this can be.

Finally, we define simple aliases for our hosts. Each host has an alias that we prefer to use instead of the generic linux{1,2,3} names. To create alias A records, we use + lines, which are exactly like = lines, except PTR records are not created:

+flying.example.com:192.168.10.10         # alias for linux1
+spaghetti.example.com:192.168.10.30      # alias for linux2
+monster.example.com:192.168.10.30        # alias for linux3

Although it's discouraged, you also could define an alias with a CNAME using a C line:

Cnoodly-appendage.example.com:linux1.example.com

All these records go in a single file, which in our case is /service/tinydns/root/data. Save the file, and from that directory run make. This compiles the text file into data.cdb, a constant database. If a data.cdb already exists, tinydns will continue serving from it until the new one is ready, at which point it is moved into place, and tinydns instantly begins using it. The Makefile simply calls the tinydns-data command:

data.cdb: data
    /usr/local/bin/tinydns-data

You can test that your new records are in the database by using the tinydns-get utility. tinydns-get accesses the data.cdb file directly, so you don't need to worry about your test queries being cached anywhere. For example, you can use tinydns-get to see that your MX record is configured properly. First, make sure you are in the /service/tinydns/root directory and that you have run make so that the database is up to date:

# tinydns-get mx example.com
15 example.com:
103 bytes, 1+1+1+2 records, response, authoritative, noerror
query: 15 example.com
answer: example.com 86400 MX 0 mail.example.com
authority: example.com 259200 NS linux2.example.com
additional: mail.example.com 86400 A 192.168.10.15
additional: linux2.example.com 86400 A 192.168.10.20

This shows that linux2.example.com is defined as the authoritative name server for example.com, that mail.example.com is the MX record for the domain, and that its IP address is 192.168.10.15.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

daemontools

Anonymous's picture

Focus should be on useability and safety.
To answer your questions - just for the records:

1) daemontools are an easy way to ensure that a program is run and restarted where necessary. Nowadays you also find 'runit' which works the same.

2) fine - you can put it somewhere else. 'runit' uses /etc/service

3) besides the fact that you can run qmail using a start-stop daemon, qmail is not exactly state of the art anymore

4) some very big sites are using tinydns. Why do you think that there is a speed problem?

5) yes. It is also possible to use vegadns which is a web based system to maintain tinydns records. Data is stored in a database; exported to tinydns using a shell command.

As djbdns is not open source binary distributions have become available.

daemontools....ach!

Anonymous's picture

1) why using daemon tools if linux has already other tools to lunch daemon and software ?
2) as a sysadmin i neglet to fill my "/" with not standard directories
3) Have You ever got problems trying to stop qmail or a piece of it ? ..(ask google) ..daemontools are simply...too much , sometime.Too much effort to keep daemons running, even when You have to stop them.
4) This is a question: how about speed?
5) Second question: importing zones from bind is possible?

StefanoA. rn- italy

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix