/contrib/bind9/doc/misc/migration

https://bitbucket.org/freebsd/freebsd-head/ · #! · 267 lines · 198 code · 69 blank · 0 comment · 0 complexity · b40e2907cc77d33ed199fafd5882a21b MD5 · raw file

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