contrib/bind9/doc/misc/migration

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