Bug 143786

Firstly, the bind package does not touch named.conf or any named 
configuration files.
The caching-nameserver package always does replace named.conf and
saves any existing named.conf as named.conf.rpmsave - this packages
consists entirely of the named configuration files and could not 
install / update itself if it did not provide these files.

Upgrade from bind-9.2.4-EL3_10 to bind-9.2.4-5_EL3 was thorougly
tested, and the state of the named service was always preserved
after upgrade. Which version of bind were you upgrading from? 

As already stated above I upgraded from bind-9.2.4-EL3_10 to
bind-9.2.4-5_EL3.

Wouldn't it make more sense for caching-nameserver to provide its
config files as *.rpmnew files during update instead of replacing all
the previously working files and leaving named in an unusable state?

Named should never have been left in an unusable state - this is the
core problem of this bug and will be remedied.
Possibly there are problems upgrading from previous releases of 
caching-nameserver which have not been caught during testing.
caching-nameserver HAS to backup and replace the BIND configuration
files - it consists entirely of them . 
By installing caching-nameserver, users are requesting that a 
caching only nameserver configuration be installed. If the caching
nameserver RPM did not replace the configuration files, there would
be no way for it to guarantee that after installation, a caching
nameserver was in place; nor could it be upgraded.
If this is not what you want, backup the BIND configuration files 
and remove the caching-nameserver RPM from the system. 

Please, if anyone is reading this bug before upgrading from 
bind-9.2.4-EL3_10 to bind-9.2.4-5_EL3, do:
  rpm -Uvv
{bind,bind-chroot,bind-libs,bind-utils,bind-devel,caching-nameserver}*.rpm
 2>&1 | tee /tmp/bind-upgrade.log
and append the /tmp/bind-upgrade.log to this bug report or send it 
to jvdias.
I've run the above command on all the RHEL-3 platforms available to
me with no errors or problems observed.

It seems the only reproducible problem from this bug report is that
the named service is still off after upgrade from bind-9.2.4-EL3_10
to bind-9.2.4-5_EL3 .  

The caching-nameserver package does back up and replace the user's
customized configuration files, but always does leave in place the
default "caching-only-nameserver" configuration that does allow
named to run and function as a caching-only-nameserver - see the
points made in comment #3 above - and this is "not a bug" .

Reviewing the CVS versions, I've found the sysv-init problem: 
From the very first version of the /etc/init.d/named script 
(named.init), no default chkconfig levels were specified:

#!/bin/bash
#
# named           This shell script takes care of starting and stopping
#                 named (BIND DNS server).
#
# chkconfig: - 55 45

These lines have remained unchanged since version  8.2.3-1 of 
Red Hat BIND.

That means that it was up to administrators to do something like :
# chkconfig --level=345  named on
# chkconfig --level=0126 named off

So, what happens during upgrade is:

1. bind-9.2.4-5_EL3 is installed
2. bind-9.2.4-EL3_10 (brokenly) does "chkconfig --del named" when
   it is erased during upgrade.
3. bind-9.2.4-5_EL3 does restart the server if it was running before
   upgrade, and does " chkconfig --add named " - but this is not
   enough, because /etc/init.d/named does not specify default 
   run-levels. 
  
So what needs to happen is to record the current runlevels of named
in bind-9.2.4-EL3_10's '%triggerpreun' and restore them in its 
'%triggerpostun' . bind-9.2.4-6_EL3 will do so, and will be available
at:
  http://people.redhat.com/~jvdias/bind/RHEL-3 
while being pushed to RHEL-3 updates .


  

bind-9.2.4-6_EL3 is now  available at:
  http://people.redhat.com/~jvdias/bind/RHEL-3 
and will be pushed to RHEL-3 updates .

bind-9.2.4-7_EL3 will be in RHEL-3-U5 and fixes all remaining problems
with upgrades from previous BIND releases.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2005-001.html