14.4 Transition Problems

With the release of BIND 8, and now BIND 9, many Unix operating systems are updating their resolvers and name servers. Some features of the most recent versions of BIND, however, may seem like errors to you after you upgrade to a new version. We'll try to give you an idea of some changes you may notice in your name server and your name service after making the jump.

14.4.1 Resolver Behavior

The changes to the resolver's default search list described in Chapter 6 may seem like a problem to your users. Recall that with a local domain name set to fx.movie.edu, your default search list will no longer include movie.edu. Therefore, users accustomed to using commands like telnet db.personnel and having the partial domain name expanded to db.personnel.movie.edu will have their commands fail. To solve this problem, you can use the search directive to define an explicit search list that includes your local domain name's parent. Or, just tell your users to expect the new behavior.

14.4.2 Name Server Behavior

Before Version 4.9, a BIND name server would gladly load data in any zone from any zone data file that the name server read as a primary master. If you configured the name server as the primary master for movie.edu and told it that the movie.edu data was in db.movie.edu, you could stick data about hp.com in db.movie.edu and your name server would load the hp.com resource records into the cache. Some books even suggested putting the data for all your in-addr.arpa zones in one file. Ugh.

All BIND 4.9 and later name servers ignore any " out of zone" resource records in a zone data file. So if you cram PTR records for all your in-addr.arpa zones into one file and load it with a single zone statement or primary directive, the name server ignores all the records not in the named zone. And that, of course, means loads of missing PTR records and failed gethostbyaddr( ) calls.

BIND does log that it's ignoring the records in syslog. The messages look like this in BIND 9:

Sep 26 13:48:19 terminator named[21960]: dns_master_load: db.movie.edu:16: ignoring out-of-zone data

And like this in BIND 8:

Jan  7 13:58:01 terminator named[231]: db.movie.edu:16: data "hp.com" outside zone
     "movie.edu" (ignored)
Jan  7 13:58:01 terminator named[231]: db.movie.edu:17: data "hp.com" outside zone
     "movie.edu" (ignored)

The solution is to use one zone data file and one zone statement or primary directive per zone.