Upgrade 4.9.7->9.1.0, 8.1.2-9.1.0

Mon Feb 12 01:57:50 UTC 2001

> 
> Hello,
> 
> Currently, we are using Solaris 2.6/SPARC and Solaris 7/SPARC.
> It includes BIND-4.9.7 (primary) and BIND-8.1.2 (secondary).
> 
> I want to upgrade it to 9.1.0, but unfortunately I don't know exact
> procedure of upgrade. I have compiled/installed source of 9.1.0 on
> Solaris/SPARC (in /usr/local). I need help to convert old 4.9.7, 8.1.2
> config file to 9.1.0.
> 
> Also I don't know 9.1.0 configuration file structure.
> 
> Please send me suggestion and helpful information.
> 
> Thanks,
> Balgaa
> System Admin
> 
> 

Copyright (C) 2000, 2001  Internet Software Consortium.
See COPYRIGHT in the source root or http://isc.org/copyright.html for terms.

		   BIND 4 to BIND 9 Migration Notes

To transition from BIND 4 to BIND 9 you first need to convert your
configuration file to the new format.  The is conversion tool in
contrib/named-bootconf that allows you to this.

	named-bootconf.sh < /etc/named.boot > /etc/named.conf

BIND 9 uses a system assigned port for the UDP queries it makes rather
that port 53 that BIND uses.  This may conflict with some firewalls.
The following directives in /etc/named.conf allow allow you to specify
a port to use.

	query-source address * port 53;
	transfer-source * port 53;
	notify-source * port 53;

BIND 9 no-longer uses the minimum field to specify the TTL of records
without a explicit TTL.  Use $TTL directive to specify a default TTL
before the first record without a explict TTL.

	$TTL 3600
	@	IN	SOA	ns1.example.com. hostmaster.example.com. (
				2001021100
				7200
				1200
				3600000
				7200 )

BIND 9 does not support multiple CNAMES with the same owner name.

	Illegal:
	www.example.com. CNAME host1.example.com.
	www.example.com. CNAME host2.example.com.

BIND 9 does not support "CNAMES with other data" with the same owner name,
ignoring DNSSEC records (SIG, NXT, KEY) that BIND 4 did not support.

	Illegal:
	www.example.com. CNAME host1.example.com.
	www.example.com. MX 10 host2.example.com.

BIND 9 is less tolerant of errors in master files so check your logs and
fix any errors reported.

                   BIND 8 to BIND 9 Migration Notes

BIND 9 is designed to be mostly upwards compatible with BIND 8, but
there is still a number of caveats you should be aware of when
upgrading an existing BIND 8 installation to use BIND 9.

1. Configuration File Compatibility

1.1. Unimplemented Options and Changed Defaults

BIND 9.1 supports most, but not all but not of the named.conf options
of BIND 8.  For a complete list of implmented options, see
doc/misc/options.

If your named.conf file uses an unimplemented option, named will log a
warning message.  A message is also logged about each option whose
default has changed unless the option is set explicitly in named.conf.

In particular, if you see a warning message about the default for the
"auth-nxdomain" option having changed, you can suppress it by adding
one of the following lines to the named.conf options { } block:

   auth-nxdomain no;	# conform to RFC1035
   auth-nxdomain yes;	# do what BIND 8 did by default

1.2. Handling of Configuration File Errors

In BIND 9, named refuses to start if it detects an error in
named.conf.  Earlier versions would start despite errors, causing the
server to run with a partial configuration.  Errors detected during
subsequent reloads do not cause the server to exit.

Errors in master files never cause the server to exit.

1.3. Logging

The set of logging categories in BIND 9 is different from that
in BIND 8.  If you have customized your logging on a per-category
basis, you need to modify your logging statement to use the
new categories.

Another difference is that the "logging" statement only takes effect
after the entire named.conf file has been read.  This means that when
the server starts up, any messages about errors in the configuration
file are always logged to the default destination (syslog) when the
server first starts up, regardless of the contents of the "logging"
statement.  In BIND 8, the new logging configuration took effect
immediately after the "logging" statement was read.

1.4. Case sensitivity

In BIND 9, ACL names are case sensitive.  In BIND 8 they were case
insensitive.

1.5. Notify messages and Refesh queries

The source address and port for these is now controlled by
"notify-source" and "transfer-source", respectively, rather that
query-source as in BIND 8.

1.6. Multiple Classes.

Multiple classes have to be put into explicit views for each class.

1.7. New Reserved Words

When specifying the names of entities like ACLs, logging channels, or
views, they can be written with or without surrounding double quotes.
However, the quotes are required if the name is identical to an option
name or other reserved word.  Since BIND 9 has a number of new options
and reserves some additional words for anticipated future options, it
is possible that some of these option names conflict with existing
names in named.conf.  For example, instead of

   acl internal { 127.0.0.1/32; 10.0.0.0/8; };

you need to write

   acl "internal" { 127.0.0.1/32; 10.0.0.0/8; };

because "internal" is now a reserved word.

2. Zone File Compatibility

2.1. Strict RFC1035 Interpretation of TTLs in Zone Files

BIND 8 allowed you to omit all TTLs from a zone file, and used the
value of the SOA MINTTL field as a default for missing TTL values.

BIND 9 enforces strict compliance with the RFC1035 and RFC2308 TTL
rules.  The default TTL is the value specified with the $TTL
directive, or the previous explicit TTL if there is no $TTL directive.
If there is no $TTL directive and the first RR in the file does not
have an explicit TTL field, the error message "no TTL specified" is
logged and loading the zone file fails.

To avoid problems, use a $TTL directive in each zone file.

2.2. Periods in SOA Serial Numbers Deprecated

Some versions of BIND allow SOA serial numbers with an embedded
period, like "3.002", and convert them into integers in a rather
unintuitive way.  This feature is not supported by BIND 9; serial
numbers must be integers.

2.3. Handling of Unbalanced Quotes

TXT records with unbalanced quotes, like 'host TXT "foo', were not
treated as errors in some versions of BIND.  If your zone files
contain such records, you will get potentially confusing error
messages like "unexpected end of file" because BIND 9 will interpret
everything up to the next quote character as a literal string.

2.4. Handling of Line Breaks

Some versions of BIND accept RRs containing line breaks that are not
properly quoted with parentheses, like the following SOA:

	@	IN SOA	ns.example. hostmaster.example.
			( 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
line.

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,
but we hope it will be.

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
EDNS0.

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.

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
<http://www.cert.org/advisories/CA-96.04.corrupt_info_from_servers.html>
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
the control of the "check-names" option in named.conf and/or "options
no-check-names" in resolv.conf.  BIND 9 provides no such protection;
if applications with these flaws are still being used, they should
be upgraded.

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; 
see the man pages in doc/man/bin/rndc.1 and doc/man/bin/rndc.conf.5 for
details.  Some of the ndc commands are still unimplemented in rndc.

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
configuration.

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
parent zone.

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
servers.

$Id: migration,v 1.22 2001/02/12 01:55:18 marka Exp $
--
Mark Andrews, Nominum Inc.
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews at nominum.com