I l@ve RuBoard Previous Section Next Section

8.3 Upgrading from BIND 8 to BIND 9

8.3.1 Problem

You want to upgrade a name server from BIND 8 to BIND 9.

8.3.2 Solution

The good news is that BIND 9's configuration file format is the same as BIND 8's, so you won't need to convert your old named.conf file. However, BIND 9 name servers don't support some configuration options that BIND 8 name servers support. For a list, see the file doc/misc/options in the BIND 9 distribution. Options marked as "obsolete" or "not [yet] implemented" aren't supported. In most cases, you either won't need the old option or can make do with functionality provided by a newer option.

One major change in the configuration file is the controls statement. BIND 8 name servers support both inet and unix control channels (see Recipe Section 3.2). BIND 9, however, only supports a new type of inet control channel, so you'll probably need to modify the name server's controls statement and create an rndc.conf file, per Section 3.3.

The zone data file format is also the same in BIND 8 and BIND 9. However, if you're upgrading from a version of BIND older than 8.2 to BIND 9, you'll need to add $TTL control statements to your zone data files, as described in Section 8.2.

There are aspects of the name server's operation that change in BIND 9. For example, BIND 8 name servers will start even if there are (minor) syntax errors in the named.conf file. A BIND 9 name server won't. This forces you to fix any syntax errors before the name server will start, which is probably a good thing.

BIND 8 name servers will also load zone data files even if they contain (minor) errors. A BIND 9 name server won't. Again, this forces you to fix any errors in the data file before the name server will respond to any queries in the zone.

BIND 9 uses different logging categories than BIND 8 did, so if the name server's named.conf file includes a logging statement, you may need to modify it for use with BIND 9. For example, BIND 8 name servers log all messages not assigned to a category to the default category, whereas BIND 9 name servers log such messages to the general category. See "Category Details" in Chapter 7 of DNS and BIND for a list of all BIND 9 categories and how they correspond to BIND 8's categories.

Finally, BIND 9 name servers don't check whether domain names contain "valid" characters, so the check-names substatement doesn't work.

8.3.3 Discussion

Although it may not affect the name server you're upgrading, the default format BIND 9 uses for sending zone transfers is the many-answers format. BIND 8 name servers understand many-answers zone transfers, though they send one-answers zone transfers by default. If you have older slave name servers that don't speak many-answers, see Recipes Section 8.4 and Section 8.5 for instructions on configuring a BIND 9 name server to speak their language.

In a BIND 8 name server's named.conf file, you could add a zone statement of a non-IN class anywhere. In BIND 9, however, you must add non-IN zone statements to a non-IN view. That means using views and moving all zone statements into view statements, whether or not you have any other use for views. Recipe Section 7.2 shows an example of this.

For a more complete reckoning of the changes between BIND 8 and BIND 9 name servers, see the file doc/misc/migration in the BIND 9 distribution.

8.3.4 See Also

Recipes Section 3.2 and Section 3.3 for the differences in the syntax of the controls statement in BIND 8 and 9, Recipes Section 8.4 and Section 8.5 for instructions on serving old-style, one-answer zone transfers to BIND 4 name servers, Section 7.2 for an example of setting up a non-IN class view, and the "Category Details" section of Chapter 7 of DNS and BIND for lists of categories supported by BIND 8 and BIND 9 name servers.

    I l@ve RuBoard Previous Section Next Section