The Versions of BIND

BIND is an acronym for Berkeley Internet Name Daemon. BIND implements this distributed database. For many years , BIND 4 was the one and only implementation, but it grew old and rusty and was replaced by BIND 8. In addition, BIND 4 had many security problems that have been fixed in BIND 8. At any time, the latest version of BIND 8 is the recommended version of BIND, especially for security-conscious sites. However, many sites still use some variant of BIND 4.

A good reason for still using BIND 4 is that most UNIX vendors still ship BIND 4 as their supported version. They have probably also modified it relative to the original version of BIND 4 that they used. On some sites, vendor support is important, so they use BIND 4.

If you use BIND 4 for some other reason, you should be sure you run the latest available version of BIND 4. Some of the most important and pressing security problems of BIND 4 have been fixed in the latest version. Also, if you use BIND 8, you should at all times use the latest available version of it. Chapter 15, "Compiling and Maintaining BIND," covers where to find the latest BIND version and how to get announce mails when new versions are published.

If It's Worth Doing, It's Worth Doing Right

…and this goes doubly for DNS. DNS glues the Internet together (along with several other things of course), and if you mix glue the wrong way, it won't be glue—it will be goo. If you set up DNS incorrectly, a likely outcome will be service disruptions for your users, your customers, and anyone else your organization has relationships with via the Internet. And, let's face it, things such as service disruptions get noticed by users because they create unpleasant situations. The really treacherous part is that DNS problems can blindside you a week, or even weeks, after you made some unrelated change to your network.

So, pay attention to all your DNS- related work. DNS is a simple design, but many of the details in its running can foul up everything.

Together, Chapter 2, "DNS in Practice," and Chapter 3, "Maintenance and Enhancements," are the core of this book, and in one way are all you will ever need to know about DNS and BIND. However, in reality, there is a lot more to it than that, which is why this is not a 100-page booklet.

Part I: Basic DNS

1 DNS Concepts

2 DNS in Practice

3 Maintenance and Enhancements

4 Getting a Domain

Chapter 1. DNS Concepts

DNS Is a Hierarchic, Distributed Database

What Is a Domain?

Zones and Delegation

Reverse Zones

Duplication and Distribution of Zones

How Resolution Works

DNS as a Tree

DNS Is a Hierarchic , Distributed Database

DNS's hierarchy is the result of two things. The most obvious is the domain names , such as www.amazon.com . This is a hierarchic name that is read from left to right. Rightmost is com , which is one of the many hundreds of top-level domains, or TLDs . Of these TLDs, com , edu , and org are the most well-known, but many, many others exist—one for each nation and territory on the planet. The International Standards Organization (ISO) has a standard for two-letter country codes called ISO-3166. The Internet authorities simply adopted these codes as names for these national domains. Under each TLD several more domains exist, such as amazon in our example. In addition, within the amazon domain, you find several more domain names, including the name of a machine (or several machines sharing one name), such as www . Together, the domain names make up www.amazon.com , which is called a fully qualified domain name ( FQDN ) because no part of the name is left out. Both TLD and FQDN are acronyms often found in technical discussions on the Internet.

However, the hierarchy also comes from one other thing, which is linked with the distribution. Distribution is the way in which the contents of the DNS database are dispensed among servers on the Net. These make a hierarchy, almost in direct relation to the domain name structure. Authorities on the Net, called registrars, have authority over com and the other TLDs. They give, or delegate, authority over subdomains to the people who manage those subdomains. For instance, people employed by Amazon manage the amazon.com part of the database with their own set of DNS servers that have authority over the amazon.com domain. It is even possible for Amazon, or any other entity, to have several subdomains with delegated authority. This delegation of authority from com to amazon is a very important feature because it distributes both the administrative and technical responsibilities of managing DNS throughout the Net. Herein lies the point of DNS and the reason it can keep growing while the hosts .txt file could not. The delegation of authority over subdomains ensures that DNS is scalable; no single part of DNS will be bogged down by the weight of its responsibilities.