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.

Configuration File Compatibility

Unimplemented Options and Changed Defaults
BIND 9.1 supports most, but not all but not of the named.conf options of BIND 8. For a complete list of implmented options, see doc/misc/options.

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.

In particular, if you see a warning message about the default for the "auth-nxdomain" option having changed, you can suppress it by adding one of the following lines to the named.conf options { } block:

auth-nxdomain no; # conform to RFC1035
auth-nxdomain yes; # do what BIND 8 did by default

Handling of Configuration File Errors
In BIND 9, named refuses to start if it detects an error in named.conf. Earlier versions would start despite errors, causing the server to run with a partial configuration. Errors detected during subsequent reloads do not cause the server to exit.

Errors in master files never cause the server to exit.

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.

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

Notify messages and Refesh queries
The source address and port for these is now controlled by "notify-source" and "transfer-source", respectively, rather that query-source as in BIND 8.

Multiple Classes
Multiple classes have to be put into explicit views for each class.

Zone File Compatibility

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.

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.

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.

Handling of Line Breaks
Some versions of BIND accept RRs containing line breaks that are not properly quoted with parentheses, like the following SOA:

@ IN SOA ns.example. hostmaster.example.
( 1 3600 1800 1814400 3600 )

This is not legal master file syntax and will be treated as an error by BIND 9. The fix is to move the opening parenthesis to the first line.
Unimplemented BIND 8 Extensions
$GENERATE: The "$$" construct for getting a literal "$" into a domain name is deprecated. Use "\$" instead.

Interoperability Impact of New Protocol Features
BIND 9 uses EDNS0 (RFC2671) to advertise its receive buffer size. It also sets an EDNS flag bit in queries to indicate that it wishes to receive DNSSEC responses; this flag bit usage is not yet standardized, but we hope it will be.

Most older servers that do not support EDNS0, including prior 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.

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 they are working on a solution.

Unrestricted Character Set
BIND 9 does not restrict the character set of domain names - it is fully 8-bit clean in accordance with RFC2181 section 11.

It is strongly recommended that hostnames published in the DNS follow the RFC952 rules, but BIND 9 will not enforce this restriction.

Historically, some applications have suffered from security flaws where data originating from the network, such as names returned by gethostbyaddr(), are used with insufficient checking and may cause a breach of security when containing unexpected characters; see for details. Some earlier versions of BIND attempt to protect these flawed applications from attack by discarding data containing characters deemed inappropriate in host names or mail addresses, under the control of the "check-names" option in named.conf and/or "options no-check-names" in resolv.conf. BIND 9 provides no such protection; if applications with these flaws are still being used, they should be upgraded.

Server Administration Tools
The "ndc" program has been replaced by "rndc", which is capable of remote operation. Unlike ndc, rndc requires a configuration file; see the man pages in doc/man/bin/rndc.1 and doc/man/bin/rndc.conf.5 for details. Some of the ndc commands are still unimplemented in rndc.

No Information Leakage between Zones
BIND 9 stores the authoritative data for each zone in a separate data structure, as recommended in RFC1035 and as required by DNSSEC and IXFR. When a BIND 9 server is authoritative for both a child zone and its parent, it will have two distinct sets of NS records at the delegation point: the authoritative NS records at the child's apex, and a set of glue NS records in the parent.

BIND 8 was unable to properly distinguish between these two sets of NS records and would "leak" the child's NS records into the parent, effectively causing the parent zone to be silently modified: responses and zone transfers from the parent contained the child's NS records rather than the glue configured into the parent (if any). In the case of children of type "stub", this behavior was documented as a feature, allowing the glue NS records to be omitted from the parent configuration.

Sites that were relying on this BIND 8 behavior need to add any omitted glue NS records, and any necessary glue A records, to the parent zone.

Although stub zones can no longer be used as a mechanism for injecting NS records into their parent zones, they are still useful as a way of directing queries for a given domain to a particular set of name servers.