Enterprise Linux Log - A SearchEnterpriseLinux.com blog

Enterprise Linux Log:

 

A SearchEnterpriseLinux.com blog


A blog for Linux administrators covering Red Hat, SUSE, Ubuntu, Linux in data centers, Oracle Linux, Linux vs. Windows, Linux vs. Unix, interoperability, migration, the Linux kernel and more.

BIND 9.4.2 RC2 is now available

Fresh from the yesterday’s news file, BIND 9.4.2b1 is now available for download. This is a maintenance release candidate for BIND 9.4, but if you are upgrading from BIND 9.4.2rc1 the BIND developer team strongly encourages you to please see the README file before doing anything.

BIND 9.4.2rc2 can be downloaded from:

ftp://ftp.isc.org/isc/bind9/9.4.2rc2/bind-9.4.2rc2.tar.gz

The PGP signature of the distribution is at

ftp://ftp.isc.org/isc/bind9/9.4.2rc2/bind-9.4.2rc2.tar.gz.asc
ftp://ftp.isc.org/isc/bind9/9.4.2rc2/bind-9.4.2rc2.tar.gz.sha256.asc
ftp://ftp.isc.org/isc/bind9/9.4.2rc2/bind-9.4.2rc2.tar.gz.sha512.asc

The signature was generated with the ISC public key, which is available at

http://www.isc.org/about/openpgp/pgpkey2006.txt

A binary kit for Windows 2000, Windows XP and Window 2003 is at:

ftp://ftp.isc.org/isc/bind9/9.4.2rc2/BIND9.4.2rc2.zip
ftp://ftp.isc.org/isc/bind9/9.4.2rc2/BIND9.4.2rc2.debug.zip

The PGP signature of the binary kit for Windows 2000, Windows XP and Window 2003 is at

ftp://ftp.isc.org/isc/bind9/9.4.2rc2/BIND9.4.2rc2.zip.asc
ftp://ftp.isc.org/isc/bind9/9.4.2rc2/BIND9.4.2rc2.zip.sha256.asc
ftp://ftp.isc.org/isc/bind9/9.4.2rc2/BIND9.4.2rc2.zip.sha512.asc
ftp://ftp.isc.org/isc/bind9/9.4.2rc2/BIND9.4.2rc2.debug.zip.asc
ftp://ftp.isc.org/isc/bind9/9.4.2rc2/BIND9.4.2rc2.debug.zip.sha256.asc
ftp://ftp.isc.org/isc/bind9/9.4.2rc2/BIND9.4.2rc2.debug.zip.sha512.asc

There were also a number of bug fixes, which can be dissected and perused at the BIND homepage.

BIND security update, end of life for version 8.0

There are a couple of BIND notifications and updates this morning that I thought I’d share with you. The first is a security notification from the Internet Systems Consortium, which oversees the BIND project.

I. Description: ISC (Internet Systems Consortium) BIND 8 generates cryptographically weak DNS query IDs which could allow a remote attacker to poison DNS caches.

This bug only affects outgoing queries, generated by BIND 8 to answer questions as a resolver, or when it is looking up data for internal uses, such as when sending NOTIFYs to slave name servers.

From the ISC Bind security page:

“The DNS query id generation is vulnerable to analysis which provides a high chance of guessing the next query id. This can be used to perform cache poisoning by an attacker.”

All users are encouraged to upgrade (see below — jack)

II. Impact: A remote attacker could predict DNS query IDs and respond with arbitrary answers, thus poisoning DNS caches.

III. Solution: Upgrade or Patch

This issue is addressed in ISC BIND 8.4.7-P1, available as patch that can be applied to BIND 8.4.7.

The more definitive solution is to upgrade to BIND 9. BIND 8 is being declared “end of life” by ISC due to multiple architectural issues. Please see ISC’s website at www.isc.org/sw/bind/bind8-eol.php for additional information and tools. Note that BIND 8.x.x is End of Life as of August 2007.

On that lat note, we have an end of life update (re: 2008 ) from ISC about BIND 8.

Due to the continuing level of effort required to support BIND 8, ISC has decided to change the status of BIND 8 to ‘end of life’.

ISC strongly encourages users who depend on BIND 8 to migrate to BIND 9 as soon as possible.

It’s never easy to retire a product. The security issues of BIND 8 are many, and 7 years after the release of BIND 9, ISC must devote our efforts to maintaining and enhancing the current version. BIND 9 was always intended as a replacement for BIND 8, thus there are no more BIND 8 releases planned beyond 8.4.7-P1, being released today.

Please see ISC’s website at http://www.isc.org/sw/bind/bind8-eol.php for additional information and migration tools.

BIND releases get version number facelift

According to the BIND mailing list, the Internet Systems Consortium (ISC) is making a minor change to the way it numbers BIND releases as a way to simplify the upgrade process for our users. More information from that mailing list email follows.

The current BIND version numbering scheme consists of three part numbers.

Current Release 9.4.1:

  • 9 - an architecture number,
  • .4 - a major release number, and
  • .1 - a minor release number.

Within the BIND 9 architecture series, major releases can and usually do include “feature” changes (new functionality, new named.conf syntax, etc). Minor releases do not include feature changes, only bugfixes.

Minor releases fall into 2 categories: Security releases and roll-up bugfix releases.

1) Security releases generally consist of the absolute minimum necessary change from the previous release making it easier for users to upgrade quickly, as security releases are usually time critical.

2) Roll-up bugfix releases include whatever bugfixes have accumulated since the last release, and can include a large number of changes. Most of these changes are usually relatively small but the volume of new code in a roll-up bugfix release is generally much larger than in a security release.

Many organizations that use BIND code have rules of one kind or another about how often they can upgrade to new releases from vendors, so unscheduled releases are problematic. The current version numbering scheme also makes it hard for users who have not been following closely to tell the difference between security releases and roll-up bugfix releases.

To facilitate the upgrade process, the ISC and BIND community will begin calling security releases “patch” versions. Version numbers for patched releases will include the same three part version number with an appended patch number (Thus, the first patch to BIND 9.4.1 would be numbered BIND 9.4.1p1).

Security patches will be released both as patches and also as tarballs. Security patches will generally be the minimal change necessary to fix the security problem, so that users whose code vetting process requires them to read every new or changed line of code will be able to incorporate security-related bugfixes quickly.

Roll-up bugfix releases will continue as before as minor releases under the old version numbering scheme. Additionally, roll-up bugfix releases will include any security patches since the previous full release. For example, BIND 9.4.2 would include whatever patches were in BIND 9.4.1p1.

“We realize that any change to the version numbering of an existing product creates a certain amount of angst and confusion, but we think and hope that this revised version numbering scheme will be better for our users in the long run. Thank you for your patience and continued support,” the mailing said.