Copyright (C) 2000 Internet Software Consortium.

See COPYRIGHT in the source root or http://isc.org/copyright.html 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.

1.3. Case sensitivity

In BIND 9, ACL names are case sensitive. In BIND 8 they were case

insensitive.

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.6 2000/08/22 00:58:12 gson Exp $