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, "Configuring Hosts" 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.
| | |
14.3. Potential Problem List | | 14.5. Interoperability and Version Problems |