0N/ACopyright (C) 2000, 2001 Internet Software Consortium.
0N/A BIND 8 to BIND 9 Migration Notes
0N/ABIND 9 is designed to be mostly upwards compatible with BIND 8, but
0N/Athere is still a number of caveats you should be aware of when
0N/Aupgrading an existing BIND 8 installation to use BIND 9.
0N/A1. Configuration File Compatibility
0N/A1.1. Unimplemented Options and Changed Defaults
0N/ABIND 9 supports most, but not all of the
named.conf options of BIND 8.
0N/AIf your
named.conf file uses an unimplemented option, named will log a
0N/Awarning message. A message is also logged about each option whose
0N/AThe default of the "transfer-format" option has changed from
0N/A"one-answer" to "many-answers". If you have slave servers that do not
0N/Aunderstand the many-answers zone transfer format (
e.g., BIND 4.9.5 or
0N/Aolder) you need to explicitly specify "transfer-format one-answer;" in
0N/Aeither the options block or a server statement.
0N/A1.2. Handling of Configuration File Errors
0N/AIn BIND 9, named refuses to start if it detects an error in
0N/Aserver to run with a partial configuration. Errors detected during
0N/Asubsequent reloads do not cause the server to exit.
0N/AErrors in master files do not cause the server to exit, but they
0N/Ado cause the zone not to load.
0N/AThe set of logging categories in BIND 9 is different from that
0N/Ain BIND 8. If you have customized your logging on a per-category
0N/Abasis, you need to modify your logging statement to use the
0N/AAnother difference is that the "logging" statement only takes effect
0N/Aafter the entire
named.conf file has been read. This means that when
0N/Athe server starts up, any messages about errors in the configuration
0N/Afile are always logged to the default destination (syslog) when the
0N/Aserver first starts up, regardless of the contents of the "logging"
0N/Astatement. In BIND 8, the new logging configuration took effect
0N/Aimmediately after the "logging" statement was read.
0N/A1.4. Notify messages and Refesh queries
0N/AThe source address and port for these is now controlled by
0N/A"notify-source" and "transfer-source", respectively, rather that
0N/Aquery-source as in BIND 8.
0N/A1.5. Multiple Classes.
0N/AMultiple classes have to be put into explicit views for each class.
0N/A2. Zone File Compatibility
0N/A2.1. Strict RFC1035 Interpretation of TTLs in Zone Files
0N/ABIND 9 strictly complies with the RFC1035 and RFC2308 rules regarding
0N/Aomitted TTLs in zone files. Omitted TTLs are replaced by the value
0N/Aspecified with the $TTL directive, or by the previous explicit TTL if
0N/Athere is no $TTL directive.
0N/AIf there is no $TTL directive and the first RR in the file does not
0N/Ahave an explicit TTL field, the zone file is illegal according to
0N/ARFC1035 since the TTL of the first RR is undefined. Unfortunately,
0N/ABIND 4 and many versions of BIND 8 accept such files without warning
0N/Aand use the value of the SOA MINTTL field as a default for missing TTL
0N/ABIND 9.0 and 9.1 completely refused to load such files. BIND 9.2
0N/Aemulates the nonstandard BIND 4/8 SOA MINTTL behavior and loads the
0N/Afiles anyway (provided the SOA is the first record in the file), but
0N/Awill issue the warning message "no TTL specified; using SOA MINTTL
0N/ATo avoid problems, we recommend that you use a $TTL directive in each
0N/A2.2. Periods in SOA Serial Numbers Deprecated
0N/ASome versions of BIND allow SOA serial numbers with an embedded
0N/Aperiod, like "3.002", and convert them into integers in a rather
0N/Aunintuitive way. This feature is not supported by BIND 9; serial
0N/Anumbers must be integers.
0N/A2.3. Handling of Unbalanced Quotes
0N/ATXT records with unbalanced quotes, like 'host TXT "foo', were not
0N/Atreated as errors in some versions of BIND. If your zone files
0N/Acontain such records, you will get potentially confusing error
0N/Amessages like "unexpected end of file" because BIND 9 will interpret
0N/Aeverything up to the next quote character as a literal string.
0N/A2.4. Handling of Line Breaks
0N/ASome versions of BIND accept RRs containing line breaks that are not
0N/Aproperly quoted with parentheses, like the following SOA:
( 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
2.5. Unimplemented BIND 8 Extensions
$GENERATE: The "$$" construct for getting a literal $ into a domain
name is deprecated. Use \$ instead.
3. 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,
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
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.
When BIND 9 communicates with a server that does support EDNS0, such as
another BIND 9 server, responses of up to 4096 bytes may be
transmitted as a single UDP datagram which is subject to fragmentation
at the IP level. If a firewall incorrectly drops IP fragments, it can
cause resolution to slow down dramatically or fail.
Outgoing zone transfers now use the "many-answers" format by default.
This format is not understood by certain old versions of BIND 4.
You can work around this problem using the option "transfer-format
one-answer;", but since these old versions all have known security
problems, the correct fix is to upgrade the slave servers.
Zone transfers to Windows 2000 DNS servers sometimes fail due to a bug
in the Windows 2000 DNS server where DNS messages larger than 16K are
not handled properly. There will be a hot fix available from
Microsoft to address this issue. In the meantime, the problem can
be worked around by setting "transfer-format one-answer;".
[As of May 4 2001 the hotfix was still being prepared]
4. 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
no-check-names" in
resolv.conf. BIND 9 provides no such protection;
if applications with these flaws are still being used, they should
5. Server Administration Tools
The "ndc" program has been replaced by "rndc", which is capable of
remote operation. Unlike ndc, rndc requires a configuration file;
details. Some of the ndc commands are still unimplemented in rndc.
5.2. Nsupdate Differences
The BIND 8 implementation of nsupdate had an undocumented feature
where an update request would be broken down into multiple requests
based upon the discovered zones that contained the records. This
behaviour has not been implemented in BIND 9. Each update request
must pertain to a single zone, but it is still possible to do multiple
updates in a single invocation of nsupdate by terminating each update
with an empty line or a "send" command.
6. 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
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
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
The BIND 8 named unconditionally sets the umask to 022. BIND 9 does
not; the umask inherited from the parent process remains in effect.
This may cause files created by named, such as journal files, to be
created with different file permissions than they did in BIND 8. If
necessary, the umask should be set explicitly in the script used to
$Id: migration,v 1.41 2001/09/21 17:36:35 gson Exp $