13.4.1 Resolver Behavior

The changes to the resolver's default search list that we described in Chapter 6 may seem like a problem to your users. Recall that with a domain setting of 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 default domain's parent domain.

13.4.2 Name Server Behavior

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

With BIND 4.9, the name server ignores any "out of zone" resource records in a zone data file. So if you cram PTR records for all your in-addr.arpa domains into one file and load it with a single zone statement or primary directive, the name server will ignore all the records not in the named zone. And that, of course, will mean 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:

Jan  7 13:58:01 terminator named[231]: db.movie:16: data "hp.com" outside zone
     "movie.edu" (ignored)
Jan  7 13:58:01 terminator named[231]: db.movie: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.