DNS is mostly a directory service. Millions of people and computers use one or more directories every day. Currently, so many directories exist in our world that they have become almost transparent to casual observers. You could say it's a directory kind of world out there and DNS remains a big part of it for people who use the Internet regardless of the device.

In the old days, people often referred to directories as databases and technically they were right. Directories and databases share many characteristics such as the storing of information and the ability to rapidly search through that data. Think of how many times you use your cell phone as a database for personal contacts. In fact, your cell uses its address book as a directory to rapidly find and dial people's telephone numbers.

Directories also differ from databases because people tend to read the contents of a directory far more than they write to it. Directories don't require support for transactions, indexes, triggers and storing of binary objects. Directories provide information people and programs need to perform some activity and directories provide the information quickly.

You might wonder why system administrators have to know the inner workings of DNS. It's a directory, right? People have stored the information in the directory and computers use that information like a phone book. After all, when I bought my domain name, I provided all that contact information and so on. Souldn't that information already exist in my top-level domain server (TLD).

Don't forget, you provided the names of two or more domain name servers. One of those servers will act of the primary directory people will use to look up your domain. The others will act as backup DNS servers. When you specified those servers, you took on the responsibility of creating entries in the Domain Name System for your domain(s).

DNS directories differ from others in the way they're managed. Once someone gets the rights to a domain, a registrar submits the domain name to a TLD server. The registrar also submits the names and IP addresses of the DNS servers that will contain information about the newly registered domain.

Once the submission becomes part of the TLD collection then a system administrator must take over and manage the IP addresses and their respective common names. We call the DNS directory distributed because you have to manage your part of it independently.

As the administrator you're supposed to make sure your servers stay on-line so people can find your web sites. It means you have to correctly map a web site name to its correct IP address using standard DNS protocols.

Web-Enabling Applications?

Aside from security, stability, and accuracy, putting DNS into your infrastructure provides other benefits. It allows you more scalability. This becomes important if you own and operate several active domains or internal authentication services. In short, it's valuable to control your own DNS in today's business environment, instead of having somebody else doing it.

Many companies have web-enabled their core business applications and must maintain their own DNS servers. Businesses do not normally replace working applications. They consider it too costly to upgrade and/or migrate legacy systems. An old saying applies here, "if it ain't broke - don't fix it".

Even so, businesses understand they must keep up with new technologies or lose customers to competitors. It creates a dilemma. If you run a business you have to weigh the costs of upgrading your business applications against the cost of losing business.

So, an industry emerged to help businesses keep their existing legacy applications while modernizing them at the same time. This concept began with a couple of small start-ups in Silicon Valley and grew quickly. The idea worked so well that the major ERP vendors bought out those small start-ups.

Now, companies like SAP and Oracle have web enabled legacy systems. They do this by adding web front-ends while using web-based back-ends to connect disparate systems together. DNS becomes an integral part of web-enabling since such systems need directory servers that can communicate with one another.

DNS also holds a prominent place with the emergence of web services and an executable Internet where people can use applications such as those offered by Google, Yahoo and others. Resolving IP addresses quickly and dependably becomes critical to the success of these products outside on the Internet and inside enterprises.

DNS directories also help manage Local and Wide Area networks. With this requirement DNS configuration and management has become one of the more valuable system administration skill sets to have.

Terminology

As you begin to learn DNS jargon, you will find it unintuitive. In many ways, the jargon feels like a foreign language. It won't make a lot of sense until you work with it for some period of time.

Linux distribution offers the well-known package called BIND to perform DNS functions. Alternatives to BIND exist such as the djbdns suite. Still, many people agree that system administrators should start with BIND because it runs almost all the DNS servers in the world. We won't offer a history lesson on BIND because the subject will put readers to sleep.

Still, we need to address one historical concern. Some people continue to use an antiquated or deprecated release of BIND - version 4. In this series, we'll use the newer releases of BIND 8 and 9. We won't cover BIND 4.

If you work on a system with DNS configuration files that look different from the syntax shown in this series, it's probably because the system uses BIND 4. Like we said above, businesses don't usually replace working systems. It may require a catastrophe to get someone to upgrade to BIND 8 or 9. Because of the potential for security exploits in BIND 4, you should strongly suggest to any user of a BIND 4 system to upgrade.

Name Servers Hosting Other Domains

Think of DNS like you would a telephone directory. If you want to find John and Jane Doe in the phone book, the phone company publishes that information. But if you want to find janedoe.com; a system administrator has to come forward with the name and number and make it part of the distributed DNS directory.

How do admins do this? They create their listing in what DNS aficionados call zone files.

A zone holds the information for a domain or using our phone book analogy for a household. You might have fifteen kids living in the house and you could reach each one of them at the same address and phone number when they're at home. Similarly, you might have fifteen servers and they all live in the same data center.

Part of BIND's versatility allows you to manage multiple zones on one server. To illustrate this, let's say that you administer a server that hosts five different web sites, each with a completely different domain name. Suppose one is red-domain.org, while the others are red-kid.com, red-sister.org and so on. All the owners of the web sites ask you to manage their DNS records.

Each web site is in a different domain. So you have to write a zone file for each web site. In the registrars' databases, your server will be listed as the name server for those domain names.

So, server1.red-domain.org is listed as the guy you contact to find the other kids in the house, like red-kid.com, red-sister.org and the others.

Let's say that someone out there is looking for one of the kids and they call you. You have so many kids and now they each have a cell phone and you forget their numbers. So, you have this listing of your own. It's a directory and you look in it to find which kid is living in the house now and has a cell.

You look in your directory and discover who is there today. You call that little directory /etc/named.conf, which is the name of BIND's configuration file. In a sense, /etc/named.conf is your directory listing of zone files. It provides you with information about the location of each zone on your system. We'll talk about that in the next article.

A Little Something About BIND

Linux distributions typcially use BIND as their default name server. BIND comes with three components. The first is the service or daemon that runs the answering side of DNS. It answers the door when the bell rings. On your system, you'll find the doorbell answerer under the daemon called named (pronounced name-dee).

We call the second item in the BIND bundle the resolver library. The resolver works like a negotiator without an accent. It goes out and looks up the name of a web site and then finds the IP number so you can find the right computer out there in the Internet jungle.

Some folks think of a resolver as a client inside BIND. The resolver code makes queries of DNS servers in an attempt to translate a name to an IP address. You will find that this piece of BIND uses its own little directory called resolv.conf .

Here's the kicker; you also get to configure resolv.conf . Unlike the server, the client is no single program, instead it's a library that the other kids like the web browser or email client can read to resolve a name.

The third part of BIND provides tools like dig command for testing DNS. Go to your console and type dig yahoo.com and see what happens. Later, we'll discuss dig and the other guys in this tool kit.

For now, I just want to get you familiar with some concepts like zones and the idea of configuration files in the /etc/bind directory. Next time, we'll install Bind9 on a Debian system, put it in a chrooted environment and set up a zone to manage. Until then, have some good old July 4th fun.