Upgrade 4.9.7->9.1.0, 8.1.2-9.1.0

[Balgansuren]

Hello,

Where can I to get these migration notes?

Thank you,
Balgaa

On Mon, 12 Feb 2001 Mark.Andrews at nominum.com wrote:

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