When the Internet was barely a handful of interconnected networks, only a few key standardized services existed. Given the Internet’s rapid pace of change, two or more decades on, a few of those services remarkably still exist fundamentally unchanged, such as SMTP, HTTP, and DNS.

In a business environment opinions from experienced individuals are usually the main drivers of how businesses make use of these services. For SMTP, you had sendmail . Even if you’re using another MTA (Mail Transfer Agent) on some distributions today, you might be surprised to discover there are references to sendmail still present within that operating system or MTA. For your beloved web servers, the mighty Apache was a given, even though for a while IIS and Roxen, for example, tried hard to make their mark. For DNS, it was always BIND – a standard recognized everywhere.

What Does DNS Do?

The actual core functions of DNS are almost painfully simple. When you converse with a name server it’s really as straightforward as “If I present you with a domain name, will you me tell its IP address?” – or the other way round – “If I give you an IP address, will you tell me its DNS name?” The first question is a forward DNS lookup, and the second is a reverse DNS lookup. Although DNS does a few other things, mostly it addresses these two basic types of queries.

Consider then why a package like BIND, which apparently appeared in the early 1980s, became the de facto standard. With its large, sprawling, cumbersome codebase and its, sometimes unfairly repeated, poor security pedigree, it’s an unusual choice for such simple functions as answering the questions above. For a number of reasons, I suspect, BIND continues to rule the waves for serving DNS on the Internet despite its background of problems.

BIND’s multiple embarrassing security holes, which left the Internet’s most popular DNS server open to really serious attacks over the years, its lengthy config files, and its initial inability to store records in databases – only within flat text files – meant the technical community was understandably looking for alternatives.

The Young Pretender

One of the DNS server alternatives that sprung up was written by the well-known Internet influencer Dan Bernstein  and, as well as writing the phenomenal mail server QMail (second only to sendmail in popularity) among other exceptional contributions, he wrote a DNS server called djbdns (Bernstien’s initials are DJB) .

Much like Qmail, his djbdns name server became the second most used on the Internet behind BIND. To introduce a more appealing nickname for djbdns , the moniker TinyDNS was bandied about, and for many, it stuck, replacing the original name completely. Strictly speaking, the whole package of DNS tools should really be called djbdns ,  and only the actual DNS server element (its DNS data and the authoritative name server) should be called TinyDNS . For simplicity, however, I’ll refer to it as TinyDNS .

The Importance of DNS

Bernstein, a savvy and creative mathematician and programmer, originally devised TinyDNS a the frustrations I’ve already mentioned with BIND. DNS might be simple, but every service online uses it – almost. Forget about key services functioning, even partially, including email and the web, if DNS isn’t behaving. Bernstien’s frustrations, I suspect, were mostly down to the constant threat of security holes being discovered in BIND and the distinct urgency felt by many in fixing them before their critical services were brought down purely because of a name server exploit.

Bernstein’s answer was to write something spectacularly super lightweight, lightning fast, and because of its diminutive code base, exceptionally secure. How secure? You might well ask Well, how does a US$ 1,000 reward sound if you discover a security hole? You have to admit that such an offer certainly exudes confidence (see his security guarantee).

Popularity

Alongside the tiniest of codebases, making it fantastically lightweight relative to BIND, this security claim rocketed TinyDNS to popularity. You could install it on the oldest, lowest powered hardware and still serve DNS queries without any headaches. No wonder it’s so popular. Likely, it was surpassed by BIND only because many businesses historically have relied on BIND – in some cases, for decades.

Hieroglyphics

If you’re used to BIND, then the layout and formatting of the TinyDNS config files are not for the infirm. To get past the issue of this understandable learning curve, Bernstein bundles some useful shell scripts to perform everyday tasks. The contents of the add-mx script shows the way TinyDNS adds an MX record:

#!/bin/sh
exec /usr/local/bin/tinydns-edit data data.new add mx ${1+"$@"}

Once you’ve run the stock script above, try examining how the main config file looks with the MX record added. You might find it easy just to copy and paste directly inside the main config file (incidentally, named data , until it’s compiled with make so it’s significantly faster to process; then, it’s called data.cdb ).

The data file now shows this for the MX entry:

@domainname.com::mail.domainname.com:10:3600

If you ran a similar MX command again adding mail2 , you’d add a secondary MX with a different priority (a.k.a. delivery preference – in other words, the preferred delivery order in which the mail server receives the inbound email).

@domainname.com::mail2.domainname.com:20:3600

Here, you’re telling TinyDNS to answer MX queries for domainname.com , making mail.domainname.com   the first port of call. If that’s unavailable, then mail2.domainname.com   is the second choice. The priorities of 10 and 20 adjust the order of preference, and the 3600 at the end is the time to live (TTL ), or how long in seconds the answer should be trusted to be correct before asking the name server again.