DNS and BIND, Third Edition by Paul Albitz, Cricket Liu |, Paperback | Barnes & Noble
DNS and BIND, Third Edition

DNS and BIND, Third Edition

5.0 1
by Paul Albitz, Cricket Liu

DNS and BIND discusses one of the Internet's fundamental building blocks: the distributed host information database that's responsible for translating names into addresses, routing mail to its proper destination, and many other services. As the authors write in the preface, if you're using the Internet, you're already using DNS — even if you don't


DNS and BIND discusses one of the Internet's fundamental building blocks: the distributed host information database that's responsible for translating names into addresses, routing mail to its proper destination, and many other services. As the authors write in the preface, if you're using the Internet, you're already using DNS — even if you don't know it.The third edition covers BIND 4.9, on which most commercial products are currently based, and BIND 8, which implements many important new features and will be the basis for the next generation of commercial name servers. It also covers topics like DNS security (greatly improved with BIND 8.1), asynchronous notification of changes to a zone, dynamic updates, and programming with Perl's Net::DNS module.Whether you're an administrator involved with DNS on daily basis, or a user who wants to be more informed about the Internet and how it works, you'll find that this book is essential reading.Topics include:

  • What DNS does, how it works, and when you need to use it
  • How to find your own place in the Internet's name space
  • Setting up name servers
  • Using MX records to route mail
  • Configuring hosts to use DNS name servers
  • Subdividing domains (parenting)
  • Securing your name server: restricting who can query your server, preventing unauthorized zone transfers, avoiding bogus name servers, etc.
  • Mapping one name to several servers for load sharing
  • Troubleshooting: using nslookup, reading debugging output, common problems
  • DNS programming, using the resolver library and Perl's Net::DNS module

Product Details

O'Reilly Media, Incorporated
Publication date:
Edition description:
Third Edition
Product dimensions:
7.08(w) x 9.20(h) x 1.06(d)

Read an Excerpt

From Chapter 10: Advanced Features and Security

Changing the open files limit

On hosts with many IP addresses, or a low limit on the maximum number If your name server is authoritative for a lot of zones, the named process will open lots of files when it starts up-one per authoritative zone, assuming you use backup files on the zones you're a slave for. Likewise, if the host running your name server has lots of virtual network interfaces, named will require one file descriptor per interface. Most UNIX operating systems place a limit on the number of files any process can open simultaneously. If your name server tries to open more files than this limit permits, you'll see this message in your syslog output...

If your operating system also permits changing that limit on a per-process basis, you can increase it using BIND 8's files substatement...

The default is unlimited (which is also a valid value), although this just means that the server doesn't place any limit on the number of simultaneously open files; the operating system, however, may.

Maintenance Intervals

BIND name servers have always done periodic housekeeping: refreshing zones the server is a slave for, for example. With BIND 8, you can now control how often these chores happen, or whether they happen at all.

Cleaning interval

Name servers older than BIND 4.9 only passively remove state entries from the cache. Before such a name server returns a record to a querier, it checks to see whether the TTL on that, report has expired. If it has, the name server starts the resolution process to find more current data. This means that a BIND4 server may cache a lot of records in a flurry of name resolution, and then just let those records spoil in the cache, taking up valuable memory, even though the records are stale.

BIND 8 now actively walks through the cache and removes stale records once each cleaning interval. This means that a BIND 8 name server will tend to use less memory for caching than a BIND 4 server in the same role. On the other hand, the cleaning process takes CPU time, and on very slow or very busy name servers, you may not want it running every hour.

By default, the cleaning interval is 60 minutes. You can tune the interval with the cleaning-interval substatement to the options statement. For example...

sets the cleaning interval to 120 minutes. To turn off cache cleaning entirely, use a cleaning interval of zero.

Interface interval

We've said already that BIND, by default, listens on all of a host's network interfaces. BIND 8 is actually smart enough to notice when a network interface on the host it's running on comes up or goes down. To do this, it periodically scans the host's network interfaces. This happens once each interface interval, which is 60 minutes by default. If you know the host your name server runs on has no dynamic network interfaces, you can disable scanning for new interfaces by setting the interface interval to zero to avoid unnecessary hourly overhead...

On the other hand, if your host brings up or tears down network interfaces more often than every hour, you may want to reduce the interval.

Statistics interval

Okay, adjusting the statistics interval-the frequency at which the BIND 8 server dumps statistics to the statistics file-won't have much effect on performance. But it fits better here, with the other maintenance intervals, than anywhere else in the book.

The syntax of the statistics-interval substatement is exactly analogous to the other maintenance intervals...

And, as with the other maintenance intervals, the default is 60 minutes, and a setting of zero disables the periodic dumping of statistics.

Name Server Address Sorting

When you are contacting a host that has multiple network interfaces, using a particular interface may give you better performance. If the multihomed host is local and shares a network with your host, one of the multihomed host's addresses is "closer." If the multihomed host is remote, you may see better performance by using one of the interfaces instead of another, but often it doesn't matter much which address is used. In days past, net 10 (the former ARPAnet "backbone") was always closer than any other remote address. The Internet has improved drastically since those days, so you won't often see a marked improvement by preferring one network over another for remote multihomed hosts, but we'll cover that case anyway.

Before we get into address sorting by a name server, you should first look at whether address sorting by the resolver better suits your needs. (See the section called "The sortist Directive" in Chapter 6, Configuring Hosts.) Since your resolver and name server may be on different networks, it often makes more sense for the resolver to sort addresses optimally for its host. Address sorting at the name server works fairly well, but it won't be optimal for every resolver it services. Resolver address sorting was added at 4.9. If your resolver (not your name server) is older than 4.9, you are out of luck. You'll have to make do with address sorting at the name server, which was introduced in 4.8.3.

We should also mention that address sorting is not supported in BIND 8. For BIND 8, the developers removed address sorting because they believed that it had no place in the server.

Local Multihomed Hosts

Let's deal with the local multihomed host first. Suppose you have a source host (i.e., a host that keeps your master sources) on two networks, cleverly called network A and network B, and this host uses NFS to export filesystems to hosts on both networks. Hosts on network A will experience better performance if they use the source host's interface to network A. Likewise, hosts on network B would benefit from using the source host's interface to network B for the address of the NFS mount.

In Chapter 4, Setting Up BIND, we mentioned that BIND returns all the addresses for a multihomed host. There was no guarantee of the order in which 'a DNS server would return the addresses, so we assigned aliases (wh249 and wh253 for wormhole) to the individual interfaces. if one interface was preferable, you (or more realistically, a DNS client) could use an appropriate alias to get the correct address. You can use aliases to choose the "closer" interface (e.g., for setting up NFS mounts), but because of address sorting, they are not always necessary...

Meet the Author

Paul Albitz is a software engineer at Hewlett-Packard. Paul earned a Bachelor of Science degree from the University of Wisconsin, LaCrosse, and a Master of Science degree from Purdue University.

Paul worked on BIND for the HP-UX 7.0 and 8.0 releases. During this time he developed the tools used to run the hp.com domain. Since then Paul has worked on various HP products during his 19 year career: HP JetDirect software, HP OfficeJet fax firmware, HPPhoto web site, and HP Photosmart Premier software.

Paul and his wife Katherine live in San Diego California with their two cats, Gracie and Tiffany.

Cricket Liu matriculated at the University of California's Berkeley campus, that great bastion of free speech, unencumbered Unix, and cheap pizza. He joined Hewlett-Packard after graduation and worked for HP for nine years. Cricket began managing the hp.com zone after the Loma Prieta earthquake forcibly transferred the zone's management from HP Labs to HP's Corporate Offices (by cracking a sprinkler main and flooding Labs' computer room). Cricket was hostmaster@hp.com for over three years, and then joined HP's Professional Services Organization to cofound HP's Internet Consulting Program. Cricket left HP in 1997 to form Acme Byte & Wire, a DNS consulting and training company, with his friend (and now co-author) Matt Larson. Network Solutions acquired Acme in June 2000, and later the same day merged with VeriSign. Cricket worked for a year as Director of DNS Product Management for VeriSign Global Registry Services. Cricket joined Men & Mice, an Icelandic company specializing in DNS software and services, in September, 2001. He is currently their Vice President, Research & Development. Cricket, his wife, Paige, and their son, Walt, live in Colorado with two Siberian Huskies, Annie and Dakota. On warm weekend afternoons, you'll probably find them on the flying trapeze or wakeboarding behind Betty Blue.

Customer Reviews

Average Review:

Write a Review

and post it to your social network


Most Helpful Customer Reviews

See all customer reviews >