DNS & BIND

DNS & BINDSearch this book
Previous: 13.3 Potential Problem ListChapter 13
Troubleshooting DNS and BIND
Next: 13.5 Interoperability and Version Problems
 

13.4 Transition Problems

With the release of BIND 4.9, many UNIX operating systems are updating their resolver and name servers to include 4.9's new functionality. Some of 4.9's features, however, may seem like errors to you after you upgrade to a new version of your operating system. We'll try to give you an idea of some changes you may notice in your name service after making the jump.

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.


Previous: 13.3 Potential Problem ListDNS & BINDNext: 13.5 Interoperability and Version Problems
13.3 Potential Problem ListBook Index13.5 Interoperability and Version Problems