You may not know much about the Domain Name System—yet—but whenever you use the Internet, you use DNS. Every time you send electronic mail or surf the World Wide Web, you rely on the Domain Name System.
You see, while you, as a human being, prefer to remember the names of computers, computers like to address each other by number. On an internet, that number is 32 bits long, or between 0 and 4 billion or so.[*] That’s easy for a computer to remember because computers have lots of memory ideal for storing numbers, but it isn’t nearly as easy for us humans. Pick 10 phone numbers out of the phone book at random and then try to remember them. Not easy? Now flip to the front of the phone book and attach random area codes to the phone numbers. That’s about how difficult it would be to remember 10 arbitrary internet addresses.
This is part of the reason we need the Domain Name System. DNS handles mapping between hostnames, which we humans find convenient, and internet addresses, which computers deal with. In fact, DNS is the standard mechanism on the Internet for advertising and accessing all kinds of information about hosts, not just addresses. And DNS is used by virtually all internetworking software, including electronic mail, remote terminal programs such as ssh, file transfer programs such as ftp, and web browsers such as Microsoft’s Internet Explorer.
Another important feature of DNS is that it makes host information available all over the Internet. Keeping information about hosts in a formatted file on a single computer only helps users on that computer. DNS provides a means of retrieving information remotely from anywhere on the network.
More than that, DNS lets you distribute the management of host information among many sites and organizations. You don’t need to submit your data to some central site or periodically retrieve copies of the “master” database. You simply make sure your section, called a zone, is up to date on your nameservers . Your nameservers make your zone’s data available to all the other nameservers on the network.
Because the database is distributed, the system also needs to be able to locate the data you’re looking for by searching a number of possible locations. The Domain Name System gives nameservers the intelligence to navigate through the database and find data in any zone.
Of course, DNS does have a few problems. For example, the system allows more than one nameserver to store data about a zone, for redundancy’s sake, but inconsistencies can crop up between copies of the zone data.
But the worst problem with DNS is that despite its widespread use on the Internet, there’s really very little documentation about managing and maintaining it. Most administrators on the Internet make do with the documentation their vendors see fit to provide and with whatever they can glean from following the Internet mailing lists and Usenet newsgroups on the subject.
This lack of documentation means that the understanding of an enormously important internet service—one of the linchpins of today’s Internet—is either handed down from administrator to administrator like a closely guarded family recipe, or relearned repeatedly by isolated programmers and engineers. New zone administrators suffer through the same mistakes made by countless others.
Our aim with this book is to help remedy this situation. We realize that not all of you have the time or the desire to become DNS experts. Most of you, after all, have plenty to do besides managing your zones and nameservers: system administration, network engineering, or software development. It takes an awfully big institution to devote a whole person to DNS. We’ll try to give you enough information to allow you to do what you need to do, whether that’s running a small zone or managing a multinational monstrosity, tending a single nameserver or shepherding a hundred of them. Read as much as you need to know now, and come back later if you need to learn more.
DNS is a big topic—big enough to require two authors, anyway—but we’ve tried to present it as sensibly and understandably as possible. The first two chapters give you a good theoretical overview and enough practical information to get by, and later chapters fill in the nitty-gritty details. We provide a roadmap up front to suggest a path through the book appropriate for your job or interest.
When we talk about actual DNS software, we’ll concentrate almost exclusively on BIND, the Berkeley Internet Name Domain software, which is the most popular implementation of the DNS specs (and the one we know best). We’ve tried to distill our experience in managing and maintaining zones with BIND into this book. (One of our zones, incidentally, was once one of the largest on the Internet, but that was a long time ago.) Where possible, we’ve included the real programs we use in administration, many of them rewritten into Perl for speed and efficiency.
We hope that this book will help you get acquainted with DNS and BIND if you’re just starting out, refine your understanding if you’re already familiar with them, and provide valuable insight and experience even if you know ‘em like the back of your hand.
The fifth edition of this book deals with the new 9.3.2 and 8.4.7 versions of BIND as well as older versions of BIND 8 and 9. While 9.3.2 and 8.4.7 are the most recent versions as of this writing, they haven’t made their way into many vendors’ versions of Unix yet, partly because both versions have only recently been released and many vendors are wary of using such new software. We also occasionally mention other versions of BIND because many vendors continue to ship code based on this older software as part of their Unix products. Whenever a feature is available only in the 8.4.7, or 9.3.2 version, or when there is a difference in the behavior of the versions, we try to point out which version does what.
We use nslookup, a nameserver utility program, very frequently in our examples. The version we use is the one shipped with the 9.3.2 BIND code. Older versions of nslookup provide much, but not quite all, of the functionality in the 9.3.2 nslookup. We’ve used commands common to most nslookups in most of our examples; when this was not possible, we tried to note it.
Besides updating the book to cover the most recent versions of BIND, we’ve added a fair amount of new material to the fifth edition:
Coverage of SPF, the Sender Policy Framework, in Chapter 6
More extensive coverage of dynamic update and NOTIFY, including signed dynamic updates and BIND 9’s new update-policy mechanism, in Chapter 10
Incremental zone transfer, also in Chapter 10
Forward zones, which support conditional forwarding, in Chapter 10
IPv6 forward and reverse mapping using AAAA records and ip6.arpa, respectively, at the end of Chapter 10
Transaction signatures, also known as TSIG, a new mechanism for authenticating transactions, in Chapter 11
An expanded section on securing nameservers, in Chapter 11
An expanded section on dealing with Internet firewalls, in Chapter 11
Coverage of the revised DNS Security Extensions, or DNSSECbis, a mechanism for digitally signing zone data, also in Chapter 11
A new chapter (Chapter 16) on the design of a complete DNS architecture for an organization
ENUM, which maps E.164 telephone numbers to URIs, in Chapter 17
Internationalized Domain Names, or IDN, a standard for encoding Unicode characters in the labels of domain names, in Chapter 17
A revised section on accommodating Active Directory with BIND, in Chapter 17
This book is organized, more or less, to follow the evolution of a zone and its administrator. Chapters 1 and 2 discuss Domain Name System theory. Chapters 3 through 6 help you decide whether or not to set up your own zones, then describe how to go about it, should you choose to. The middle of the book, Chapters 7 through 11, describe how to maintain your zones, configure hosts to use your nameservers, plan for the growth of your zones, create subdomains, and secure your nameservers. Chapters 12 through 16 deal with troubleshooting tools, common problems, and the lost art of programming with the resolver library routines. Chapter 16 puts it all together in an end-to-end architecture.
Here’s a more detailed, chapter-by-chapter breakdown:
Provides a little historical perspective and discusses the problems that motivated the development of DNS, then presents an overview of DNS theory.
Goes over DNS theory in more detail, including the organization of the DNS namespace, domains, zones, and nameservers. We also introduce important concepts such as name resolution and caching.
Covers how to get the BIND software if you don’t already have it, what to do with it once you’ve got it, how to figure out what your domain name should be, and how to contact the organization that can delegate your zone to you.
Details how to set up your first two BIND nameservers, including creating your nameserver database, starting up your nameservers, and checking their operation.
Deals with DNS’s MX record, which allows administrators to specify alternate hosts to handle a given destination’s mail. This chapter covers mail-routing strategies for a variety of networks and hosts, including networks with Internet firewalls and hosts without direct Internet connectivity. The chapter also covers the Sender Policy Framework, which uses DNS to authorize mail servers sending mail from particular email addresses.
Explains how to configure a BIND resolver. We also include notes on the idiosyncrasies of the Windows resolver.
Describes the periodic maintenance administrators must perform to keep their zones running smoothly, such as checking nameserver health and authority.
Covers how to plan for the growth and evolution of your zones, including how to get big and how to plan for moves and outages.
Explores the joys of becoming a parent zone. We explain when to become a parent (create subdomains), what to call your children, how to create them (!), and how to watch over them.
Goes over some less common nameserver configuration options that can help you tune your nameserver’s performance and ease administration.
Describes how to secure your nameserver and how to configure your nameservers to deal with Internet firewalls, and describes two new security enhancements to DNS: the DNS Security Extensions and Transaction Signatures.
Shows the ins and outs of the most popular tools for doing DNS debugging, including techniques for digging obscure information out of remote nameservers.
Is the Rosetta stone of BIND’s debugging information. This chapter will help you make sense of the cryptic debugging information that BIND emits, which in turn will help you better understand your nameserver.
Covers many common DNS and BIND problems and their solutions, and then describes a number of less common, harder-to-diagnose scenarios.
Demonstrates how to use BIND’s resolver routines to query nameservers and retrieve data from within a C program or a Perl script. We include a useful (we hope!) program to check the health and authority of your nameservers.
Presents an end-to-end design for DNS infrastructure, including external nameservers, forwarders, and internal nameservers.
Ties up all the loose ends. We cover DNS wildcards, hosts and networks with intermittent Internet connectivity via dialup, network name encoding, additional record types, ENUM, IDN, and Active Directory.
Contains a byte-by-byte breakdown of the formats used in DNS queries and responses, as well as a comprehensive list of the currently defined resource record types.
Contains a matrix showing the most important features of the most popular BIND releases.
Contains step-by-step instructions on how to compile the 9.3.2 version of BIND on Linux.
Lists the current top-level domains in the Internet domain namespace.
Summarizes the syntax and semantics of each of the parameters available for configuring nameservers and resolvers.
This book is intended primarily for system and network administrators who manage zones and one or more nameservers, but it also includes material for network engineers, postmasters, and others. Not all of the book’s chapters will be equally interesting to a diverse audience, though, and you don’t want to wade through 17 chapters to find the information pertinent to your job. We hope the following roadmap will help you plot your way through the book:
Should read Chapters 1 and 2 for DNS theory, Chapter 3 for information on getting started and selecting a good domain name, then Chapters 4 and 5 to learn how to set up a zone for the first time. Chapter 6 explains how to configure hosts to use the new nameservers. Later, they should read Chapter 7, which explains how to “flesh out” their implementation by setting up additional nameservers and adding zone data. Chapters 12 through 14 describe troubleshooting tools and techniques.
May benefit from reading Chapter 6 to learn how to configure DNS resolvers on different hosts, and Chapter 7 for information on maintaining their zones. Chapter 8 contains instructions on planning for a zone’s growth and evolution, which should be especially valuable to administrators of large zones. Chapter 9 explains parenting—creating subdomains—which is de rigueur reading for those considering the big move. Chapter 10 covers many new and advanced features of the BIND 9.3.2 and 8.4.7 nameservers. Chapter 11 goes over securing nameservers, which may be of particular interest to experienced administrators. Chapters 12 through 14 describe tools and techniques for troubleshooting, which even advanced administrators may find worth reading. Chapter 16 may help administrators get a grasp of the big picture.
Should read Chapters 1 and 2 for DNS theory, then Chapter 5 to find out how DNS and electronic mail coexist. Chapter 12, which describes nslookup and dig, will also help postmasters dig mail-routing information from the domain namespace.
Note that we assume you’re familiar with basic Unix system administration, TCP/IP networking, and programming using simple shell scripts and Perl. We don’t assume you have any other specialized knowledge, though. When we introduce a new term or concept, we’ll do our best to define or explain it. Whenever possible, we’ll use analogies from Unix (and from the real world) to help you understand.
The example programs in this book [*] are available electronically via FTP from the following URLs:
In either case, extract the files from the archive by typing:
% zcat dns.tar.Z | tar xf -
System V systems require the following tar command instead:
% zcat dns.tar.Z | tar xof -
If zcat is not available on your system, use separate uncompress and tar commands.
If you can’t get the examples directly over the Internet but can send and receive email, you can use ftpmail to get them. For help using ftpmail, send an email to email@example.com with no subject and the single word “help” in the body of the message.
You can address comments and questions about this book to the publisher:
O’Reilly Media, Inc.
1005 Gravenstein Highway North
Sebastopol, CA 95472
800-998-9938 (in the United States or Canada)
O’Reilly has a web page for this book, which lists errata and any additional information. You can access this page at:
To comment or ask technical questions about this book, send email to:
For more information about books, conferences, software, Resource Centers, and the O’Reilly Network, see the O’Reilly web site at:
We use the following font and format conventions for Unix commands, utilities, and system calls:
Excerpts from scripts or configuration files are shown in constant-width font:
if test -x /usr/sbin/named -a -f /etc/named.con then /usr/sbin/named fi
Sample interactive sessions, showing command-line input and corresponding output, are shown in constant-width font, with user-supplied input in bold:
% cat /var/run/named.pid 78
If the command must be typed by the superuser (root), we use the sharp, or pound sign (#):
Replaceable items in code are printed in constant-width italics.
Domain names, filenames, functions, commands, Unix manpages, Windows features, URLs, and programming elements taken from the code snippets are printed in italics when they appear within a paragraph.
This book is here to help you get your job done. In general, you may use the code in this book in your programs and documentation. You do not need to contact us for permission unless you’re reproducing a significant portion of the code. For example, writing a program that uses several chunks of code from this book does not require permission. Selling or distributing a CD-ROM of examples from O’Reilly books does require permission. Answering a question by citing this book and quoting example code does not require permission. Incorporating a significant amount of example code from this book into your product’s documentation does require permission.
We appreciate, but do not require, attribution. An attribution usually includes the title, author, publisher, and ISBN. For example: "DNS and BIND, Fifth Edition, by Cricket Liu and Paul Albitz. Copyright 2006 O’Reilly Media, Inc., 0-596-10057-4.”
If you feel your use of code examples falls outside fair use or the permission given above, feel free to contact us at firstname.lastname@example.org.
When you see a Safari® Enabled icon on the cover of your favorite technology book, that means the book is available online through the O’Reilly Network Safari Bookshelf.
Safari offers a solution that’s better than e-books. It’s a virtual library that lets you easily search thousands of top tech books, cut and paste code samples, download chapters, and find quick answers when you need the most accurate, current information. Try it for free at http://safari.oreilly.com.
The Lewis Carroll quotations that begin each chapter are from the Millennium Fulcrum Edition 2.9 of the Project Gutenberg electronic text of Alice’s Adventures in Wonderland and Edition 1.7 of Through the Looking-Glass . Quotations in Chapters 1, 2, 5, 6, 8, and 14 come from Alice’s Adventures in Wonderland, and those in Chapters 3, 4, 7, 9–13, and 15–17 come from Through the Looking-Glass.
The authors would like to thank Ken Stone, Jerry McCollom, Peter Jeffe, Hal Stern, Christopher Durham, Bill Wisner, Dave Curry, Jeff Okamoto, Brad Knowles, K. Robert Elz, and Paul Vixie for their invaluable contributions to this book. We’d also like to thank our reviewers, Eric Pearce, Jack Repenning, Andrew Cherenson, Dan Trinkle, Bill LeFebvre, and John Sechrest for their criticism and suggestions. Without their help, this book would not be what it is (it’d be much shorter!).
For the second edition, the authors add their thanks to their sterling review team: Dave Barr, Nigel Campbell, Bill LeFebvre, Mike Milligan, and Dan Trinkle.
For the third edition, the authors salute their technical review Dream Team: Bob Halley, Barry Margolin, and Paul Vixie.
For the fourth edition, the authors owe a debt of gratitude to Kevin Dunlap, Edward Lewis, and Brian Wellington, their crack review squad.
For the fifth edition, the authors would like to thank their crack team of technical reviewers, João Damas, Matt Larson, and Paul Vixie, and Silvia Hagen for her last-minute help with IPv6.
Cricket would particularly like to thank his former manager, Rick Nordensten, the very model of a modern HP manager, on whose watch the first version of this book was written; his neighbors, who bore his occasional crabbiness for many months; and of course his wife Paige for her unflagging support and for putting up with his tap-tap-tapping during her nap-nap-napping. For the second edition, Cricket would like to add a thank you to his former managers, Regina Kershner and Paul Klouda, for their support of Cricket’s work with the Internet. For the third edition, Cricket acknowledges a debt of gratitude to his partner, Matt Larson, for his co-development of the Acme Razor. For the fourth edition, Cricket thanks his loyal, furry fans, Dakota and Annie, for kisses and companionship, and wonderful Walter B. for popping his head into the office and checking on Dad now and again. For the fifth edition, he must mention the other new addition, the fabulous Baby G. And he sends his thanks to his friends and colleagues at Infoblox for their hard work, their generous support, and their company.
Paul would like to thank his wife, Katherine, for her patience, for many review sessions, and for proving that she could make a quilt in her spare time more quickly than her spouse could write his half of a book.