Copyright (C) 2000  Internet Software Consortium.
See COPYRIGHT in the source root or http://www.isc.org/copyright for terms.


BIND 8 to BIND 9 Migration Notes


BIND 9 is designed to be mostly upwards compatible with BIND 8, but
there is still a number of caveats you should be aware of when
upgrading an existing BIND 8 installation to use BIND 9.


1. Configuration File Compatibility

1.1. Unimplemented Options and Changed Defaults

BIND 9.0.0 supports most, but not all but not of the named.conf
options of BIND 8.  Unimplemented options include those for selective
(per-domain) forwarding, sortlists, statistics, and process limits;
for a complete list, see doc/misc/options.  We plan to implement most
of these in in BIND 9.1.

If your named.conf file uses an unimplemented option, named will log a
warning message.  A message is also logged about each option whose
default has changed unless the option is set explicitly in named.conf.


1.2. Logging

The set of logging categories in BIND 9 is different from that
in BIND 8.  If you have customized your logging on a per-category
basis, you need to modify your logging statement to use the
new categories.

Another difference is that the "logging" statement only takes effect
after the entire named.conf file has been read.  This means that when
the server starts up, any messages about errors in the configuration
file are always logged to the default destination (syslog) when the
server first starts up, regardless of the contents of the "logging"
statement.  In BIND 8, the new logging configuration took effect
immediately after the "logging" statement was read.


2. Zone File Compatibility

2.1. Strict RFC1035 Interpretation of TTLs in Zone Files

BIND 8 allowed you to omit all TTLs from a zone file, and used the
value of the SOA MINTTL field as a default for missing TTL values.

BIND 9 enforces strict compliance with the RFC1035 and RFC2308 TTL
rules.  The default TTL is the value specified with the $TTL
directive, or the previous explicit TTL if there is no $TTL directive.
If there is no $TTL directive and the first RR in the file does not
have an explicit TTL field, the error message "no TTL specified" is
logged and loading the zone file fails.

To avoid problems, use a $TTL directive in each zone file.


2.2. Periods in SOA Serial Numbers Deprecated

Some versions of BIND allow SOA serial numbers with an embedded
period, like "3.002", and convert them into integers in a rather
unintuitive way.  This feature is not supported by BIND 9; serial
numbers must be integers.


2.3. Handling of Unbalanced Quotes

TXT records with unbalanced quotes, like 'host TXT "foo', were not
treated as errors in some versions of BIND.  If your zone files
contain such records, you will get potentially confusing error
messages like "unexpected end of file" because BIND 9 will interpret
everything up to the next quote character as a literal string.


3. Interoperability Impact of New Protocol Features

BIND 9 uses EDNS0 (RFC2671) to advertise its receive buffer size.  It
also sets the AD bit in queries to indicate that it wishes to receive
DNSSEC responses (this usage of the AD bit is not yet standard, but
hopefully it will be soon).

Most older servers that do not support EDNS0 and/or DNSSEC, including
all known versions of BIND, will send a FORMERR or NOTIMP response to
these queries.  When this happens, BIND 9 will automatically retry the
query without EDNS0 and AD.

Unfortunately, there exists at least one non-BIND name server
implementation that silently ignores these queries instead of sending
an error response.  Resolving names in zones where all or most
authoritative servers use this server will be very slow or fail
completely.  We have contacted the manufacturer of the name server in
case and are trying to resolve the issue with them.


$Id: migration,v 1.3 2000/07/14 17:11:07 gson Exp $