djbdns: More Than Just a Mouthful of Consonants
Let's face it, DNS is not the most sexy component of the Internet's infrastructure. It is an old technology and doesn't get the same attention as newer, more flashy tools and software. Your Web site visitors may comment on how cool your new AJAX widget is, but I guarantee they will never tell the world how pleased they are with your DNS response time.
Nevertheless, DNS is crucial to the Internet. It is one of those services that always should “just work”, and it's only when it doesn't work that people notice (and complain, loudly). Readers may remember the great “Google vanishing act” in May 2005, when the search engine giant briefly disappeared from the Internet. Many quickly assumed the site had been hacked, but the problem turned out to be a DNS configuration issue. The mishap was fixed quickly, but it highlighted how even the mightiest of the mighty can be crippled easily by a simple misconfiguration.
My primary goal for this article is to demonstrate that there is a free, secure and easy-to-configure alternative to BIND: djbdns. This article is intended for people who may have some experience with DNS, but who would like to consider new approaches. I assume only a basic understanding of DNS—specifically, familiarity with the basic record types, such as A, CNAME, MX, NS and SOA, as well as the concept of a TTL (time to live).
For the first 15 years of the Internet as we know it, there was only one real choice when it came to DNS server software: BIND. BIND began life as a project by several graduate students at the University of California, Berkeley (thus the acronym, the Berkeley Internet Name Domain). In the early 1990s, the Internet Systems Consortium (ISC) was created to maintain, distribute and support this critical software formally. The ISC released BIND 8 in May 1997 as a major update to the aging BIND 4. Although there were major configuration differences, both BIND 4 and 8 were based on the original Berkeley code from the early and mid-1980s. While trying to raise funding for a major rewrite, one of BIND's authors described this code as “sleazeware produced in a drunken fury”. A new team worked on the rewrite for several years, and BIND 9 was released formally in September 2000.
After years of dealing with security problems in BIND and frustration with its configuration syntax, Dan J. Bernstein began work on djbdns in 1999. Bernstein (or DJB as he is commonly known) already had made a name for himself as the author of qmail, the mail server software that was quickly gaining popularity among system administrators. At the time, Sendmail was the dominant mail server on the Internet, and, like BIND, it was notoriously difficult to configure and had a history of security problems. Bernstein's “thinking outside the box” design decisions about security and configuration simplicity not only catapulted qmail to success, but it also affected the way developers thought about writing software for the increasingly volatile Internet (Postfix, Courier and others were inspired by qmail's security partitioning design). Now that Bernstein had secured and simplified mail, it was time to do the same for DNS. The first alpha of djbdns was released in December 1999, and the current version, djbdns 1.05, eventually was released on February 11, 2001. That's right, the current version is more than seven years old. Remember, DNS is an old protocol, and it doesn't change very often. BIND software updates almost always are for bugfixes or security patches.
In the past, Bernstein's software was controversial because it lacked an explicit license. OS vendors were reluctant to distribute his packages because of the uncertainty around its licensing. However, in December 2007, Bernstein placed djbdns (as well as daemontools and qmail) into the public domain, allowing people to use or distribute it as they see fit.
BIND has been around since the earliest days of the Internet. It's still the most popular DNS server out there, so why should you consider switching to djbdns? For one, djbdns does not have BIND's history of problems. BIND's security record is on par with Sendmail's (not something to be proud of), and configuring it beyond the basics can be downright painful.
To complicate things further, BIND blurs the distinction between the different functions of DNS. There are two primary types of DNS services: DNS caches (also called recursive DNS servers) and DNS servers (also called authoritative servers or name servers).
A DNS cache is what your desktop computer talks to when it needs to find the address for a Web site you are trying to reach. When a cache receives your request for the location of www.google.com, it first checks to see whether it already knows the answer to your question. If it does, it quickly tells you. If it does not know the answer already, it begins by first asking the root servers for the answer. The root servers respond with something similar to “I don't know the answer but the .com servers might; here are their addresses, go ask them.” The caching server continues doing this until it has the IP for www.google.com, and then it returns the answer to your computer. The IP addresses you see in /etc/resolv.conf are for DNS caches. Caches talk to authoritative servers to get answers.
An authoritative server has a much more straightforward responsibility. Its job is simply to publish information from domains for which it is “authoritative”. An authoritative server will give answers only to questions about domains for which it has been explicitly configured. For example, ns1.google.com (one of Google's authoritative DNS servers) never will answer a request for the address of www.microsoft.com (unless Microsoft and Google merge some day).
Although these are completely different services, BIND uses the same server for both. This may seem handy, but it complicates the configuration and quickly can become a security headache.
On the other hand, djbdns adheres to the UNIX philosophy of “do one thing, and do it well”. The server components of djbdns are separated, with dnscache as the caching component and tinydns as the authoritative server (I detail the advantages of each shortly).
This separation allows each program to run individually chrooted as its own unprivileged user. If an attacker is able to crash your DNS cache, it will not impact your authoritative DNS service. A side effect of this is that dnscache and tinydns need separate IP addresses, so that each may bind to port 53. You can't run both on the same IP address.
Cory Wright https://www.corywright.org/
Practical Task Scheduling Deployment
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- Stunnel Security for Oracle
- The Firebird Project's Firebird Relational Database
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- Google's SwiftShader Released
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide