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

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState