1 Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
2 Copyright (C) 2000, 2001, 2003 Internet Software Consortium.
3 See COPYRIGHT in the source root or http://isc.org/copyright.html for terms.
5 BIND 8 to BIND 9 Migration Notes
7 BIND 9 is designed to be mostly upwards compatible with BIND 8, but
8 there is still a number of caveats you should be aware of when
9 upgrading an existing BIND 8 installation to use BIND 9.
12 1. Configuration File Compatibility
14 1.1. Unimplemented Options and Changed Defaults
16 BIND 9 supports most, but not all of the named.conf options of BIND 8.
17 For a complete list of implemented options, see doc/misc/options.
19 If your named.conf file uses an unimplemented option, named will log a
20 warning message. A message is also logged about each option whose
21 default has changed unless the option is set explicitly in named.conf.
23 The default of the "transfer-format" option has changed from
24 "one-answer" to "many-answers". If you have slave servers that do not
25 understand the many-answers zone transfer format (e.g., BIND 4.9.5 or
26 older) you need to explicitly specify "transfer-format one-answer;" in
27 either the options block or a server statement.
29 1.2. Handling of Configuration File Errors
31 In BIND 9, named refuses to start if it detects an error in
32 named.conf. Earlier versions would start despite errors, causing the
33 server to run with a partial configuration. Errors detected during
34 subsequent reloads do not cause the server to exit.
36 Errors in master files do not cause the server to exit, but they
37 do cause the zone not to load.
41 The set of logging categories in BIND 9 is different from that
42 in BIND 8. If you have customised your logging on a per-category
43 basis, you need to modify your logging statement to use the
46 Another difference is that the "logging" statement only takes effect
47 after the entire named.conf file has been read. This means that when
48 the server starts up, any messages about errors in the configuration
49 file are always logged to the default destination (syslog) when the
50 server first starts up, regardless of the contents of the "logging"
51 statement. In BIND 8, the new logging configuration took effect
52 immediately after the "logging" statement was read.
54 1.4. Notify messages and Refresh queries
56 The source address and port for these is now controlled by
57 "notify-source" and "transfer-source", respectively, rather that
58 query-source as in BIND 8.
60 1.5. Multiple Classes.
62 Multiple classes have to be put into explicit views for each class.
65 2. Zone File Compatibility
67 2.1. Strict RFC1035 Interpretation of TTLs in Zone Files
69 BIND 9 strictly complies with the RFC1035 and RFC2308 rules regarding
70 omitted TTLs in zone files. Omitted TTLs are replaced by the value
71 specified with the $TTL directive, or by the previous explicit TTL if
72 there is no $TTL directive.
74 If there is no $TTL directive and the first RR in the file does not
75 have an explicit TTL field, the zone file is illegal according to
76 RFC1035 since the TTL of the first RR is undefined. Unfortunately,
77 BIND 4 and many versions of BIND 8 accept such files without warning
78 and use the value of the SOA MINTTL field as a default for missing TTL
81 BIND 9.0 and 9.1 completely refused to load such files. BIND 9.2
82 emulates the nonstandard BIND 4/8 SOA MINTTL behaviour and loads the
83 files anyway (provided the SOA is the first record in the file), but
84 will issue the warning message "no TTL specified; using SOA MINTTL
87 To avoid problems, we recommend that you use a $TTL directive in each
90 2.2. Periods in SOA Serial Numbers Deprecated
92 Some versions of BIND allow SOA serial numbers with an embedded
93 period, like "3.002", and convert them into integers in a rather
94 unintuitive way. This feature is not supported by BIND 9; serial
95 numbers must be integers.
97 2.3. Handling of Unbalanced Quotes
99 TXT records with unbalanced quotes, like 'host TXT "foo', were not
100 treated as errors in some versions of BIND. If your zone files
101 contain such records, you will get potentially confusing error
102 messages like "unexpected end of file" because BIND 9 will interpret
103 everything up to the next quote character as a literal string.
105 2.4. Handling of Line Breaks
107 Some versions of BIND accept RRs containing line breaks that are not
108 properly quoted with parentheses, like the following SOA:
110 @ IN SOA ns.example. hostmaster.example.
111 ( 1 3600 1800 1814400 3600 )
113 This is not legal master file syntax and will be treated as an error
114 by BIND 9. The fix is to move the opening parenthesis to the first
117 2.5. Unimplemented BIND 8 Extensions
119 $GENERATE: The "$$" construct for getting a literal $ into a domain
120 name is deprecated. Use \$ instead.
122 2.6. TXT records are no longer automatically split.
124 Some versions of BIND accepted strings in TXT RDATA consisting of more
125 than 255 characters and silently split them to be able to encode the
126 strings in a protocol conformant way. You may now see errors like this
127 dns_rdata_fromtext: local.db:119: ran out of space
128 if you have TXT RRs with too longs strings. Make sure to split the
129 string in the zone data file at or before a single one reaches 255
132 3. Interoperability Impact of New Protocol Features
136 BIND 9 uses EDNS0 (RFC2671) to advertise its receive buffer size. It
137 also sets an EDNS flag bit in queries to indicate that it wishes to
138 receive DNSSEC responses; this flag bit usage is not yet standardised,
139 but we hope it will be.
141 Most older servers that do not support EDNS0, including prior versions
142 of BIND, will send a FORMERR or NOTIMP response to these queries.
143 When this happens, BIND 9 will automatically retry the query without
146 Unfortunately, there exists at least one non-BIND name server
147 implementation that silently ignores these queries instead of sending
148 an error response. Resolving names in zones where all or most
149 authoritative servers use this server will be very slow or fail
150 completely. We have contacted the manufacturer of the name server in
151 case, and they are working on a solution.
153 When BIND 9 communicates with a server that does support EDNS0, such as
154 another BIND 9 server, responses of up to 4096 bytes may be
155 transmitted as a single UDP datagram which is subject to fragmentation
156 at the IP level. If a firewall incorrectly drops IP fragments, it can
157 cause resolution to slow down dramatically or fail.
161 Outgoing zone transfers now use the "many-answers" format by default.
162 This format is not understood by certain old versions of BIND 4.
163 You can work around this problem using the option "transfer-format
164 one-answer;", but since these old versions all have known security
165 problems, the correct fix is to upgrade the slave servers.
167 Zone transfers to Windows 2000 DNS servers sometimes fail due to a
168 bug in the Windows 2000 DNS server where DNS messages larger than
169 16K are not handled properly. Obtain the latest service pack for
170 Windows 2000 from Microsoft to address this issue. In the meantime,
171 the problem can be worked around by setting "transfer-format one-answer;".
172 http://support.microsoft.com/default.aspx?scid=kb;en-us;297936
174 4. Unrestricted Character Set
176 BIND 9 does not restrict the character set of domain names - it is
177 fully 8-bit clean in accordance with RFC2181 section 11.
179 It is strongly recommended that hostnames published in the DNS follow
180 the RFC952 rules, but BIND 9 will not enforce this restriction.
182 Historically, some applications have suffered from security flaws
183 where data originating from the network, such as names returned by
184 gethostbyaddr(), are used with insufficient checking and may cause a
185 breach of security when containing unexpected characters; see
186 <http://www.cert.org/advisories/CA-96.04.corrupt_info_from_servers.html>
187 for details. Some earlier versions of BIND attempt to protect these
188 flawed applications from attack by discarding data containing
189 characters deemed inappropriate in host names or mail addresses, under
190 the control of the "check-names" option in named.conf and/or "options
191 no-check-names" in resolv.conf. BIND 9 provides no such protection;
192 if applications with these flaws are still being used, they should
196 5. Server Administration Tools
198 5.1 Ndc Replaced by Rndc
200 The "ndc" program has been replaced by "rndc", which is capable of
201 remote operation. Unlike ndc, rndc requires a configuration file.
202 The easiest way to generate a configuration file is to run
203 "rndc-confgen -a"; see the man pages for rndc(8), rndc-confgen(8),
204 and rndc.conf(5) for details.
206 5.2. Nsupdate Differences
208 The BIND 8 implementation of nsupdate had an undocumented feature
209 where an update request would be broken down into multiple requests
210 based upon the discovered zones that contained the records. This
211 behaviour has not been implemented in BIND 9. Each update request
212 must pertain to a single zone, but it is still possible to do multiple
213 updates in a single invocation of nsupdate by terminating each update
214 with an empty line or a "send" command.
217 6. No Information Leakage between Zones
219 BIND 9 stores the authoritative data for each zone in a separate data
220 structure, as recommended in RFC1035 and as required by DNSSEC and
221 IXFR. When a BIND 9 server is authoritative for both a child zone and
222 its parent, it will have two distinct sets of NS records at the
223 delegation point: the authoritative NS records at the child's apex,
224 and a set of glue NS records in the parent.
226 BIND 8 was unable to properly distinguish between these two sets of NS
227 records and would "leak" the child's NS records into the parent,
228 effectively causing the parent zone to be silently modified: responses
229 and zone transfers from the parent contained the child's NS records
230 rather than the glue configured into the parent (if any). In the case
231 of children of type "stub", this behaviour was documented as a feature,
232 allowing the glue NS records to be omitted from the parent
235 Sites that were relying on this BIND 8 behaviour need to add any
236 omitted glue NS records, and any necessary glue A records, to the
239 Although stub zones can no longer be used as a mechanism for injecting
240 NS records into their parent zones, they are still useful as a way of
241 directing queries for a given domain to a particular set of name
245 7. Umask not Modified
247 The BIND 8 named unconditionally sets the umask to 022. BIND 9 does
248 not; the umask inherited from the parent process remains in effect.
249 This may cause files created by named, such as journal files, to be
250 created with different file permissions than they did in BIND 8. If
251 necessary, the umask should be set explicitly in the script used to
252 start the named process.
255 $Id: migration,v 1.37.2.3.2.3 2004/11/22 22:33:09 marka Exp $