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.

Unimplemented Options and Changed Defaults

Some BIND 8 configuration options are still unimplemented in BIND 9,

and the default values of some options have changed. 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.

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.

Interoperability Impact of New Query 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.1 2000/06/30 22:44:08 gson Exp $