Upgrade 4.9.7->9.1.0, 8.1.2-9.1.0
Mark.Andrews at nominum.com
Mark.Andrews at nominum.com
Mon Feb 12 04:09:34 UTC 2001
>
> Hello,
>
> Where can I to get these migration notes?
This is doc/src/migration, part of the BIND 9 distribution.
I just added the BIND 4 part. I was getting tired of repeating
it.
Mark
>
> 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
> >
>
>
--
Mark Andrews, Nominum Inc.
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews at nominum.com
More information about the bind-users
mailing list