DNS Failed with automatic CentOS update

We run many clients on CentOS 3.x.

They all have DNS installed through the CentOS RPM manager.

They all do automatic updating through YUM.

Two of the system (not all, just two) updated to the latest version of Bind and when they did, they installed a new copy of /etc/named.conf, changing the old one to /etc/named.conf.rpmsave.

Which of course broke DNS completely.

The other systems updated properly without any difficulty and kept the old /etc/named.conf file.

Has anyone else seen this problem?

Jeff

I can't tell you why only 2 did it and not all (or for CentOS and yum for that matter), but I did have a similarity with bind on Debian.
During the uprade it wanted to replace the current bind data files because they had been edited.blink
If I hadn't been in interactive mode, my guess is it probably would have done a similar thing.

This doesn't help you, but my theory is "It's microsoft trying to take over the world!!!"
j/k - They're already trying to do that.

Ahhh, I'm ready for another vacation

Hey Jeff:

I've seen this once or twice, but not with bind. I think it depends on what version you're upgrading from. If the version you're upgrading to is incompatible with the old version of the config file, you'll get an rpmsave file and the new file gets dropped in. If the file is compatible, but there are significant changes, you'll get an rpmnew file and the current file is left in place.

I agree, and I've posted a comment/complaint to centos-users, as named.conf should NEVER be overwritten since it just breaks everything.

But in our case...

All of these systems are updated at the same time. And all are updated to latest versions as part of the installation process.

So all machines should have been at the same level.



Jeff

I had a similar problem on FC3 recently, luckily I only updated one server and it only has about 7 or 8 domains on it.

This latest bind version from Fedora creates a chroot environment (/var/named/chroot/var/named and /var/named/chroot/etc/named.conf) well this only half worked on this particular box.

Most of the zone files were moved from /var/named/domain.com.db to /var/named/chroot/var/named/domain.com.db and a symlink was created in /var/named

Notice I said most...

Then a named.conf was created or moved to /var/named/chroot/etc that was missing the zone files that weren't copied correctly.

DNS hilarity ensues.

The odd thing is, it was only those domains I don't pay much attention to, so this went on for nearly a week before I noticed it, I ran the update on 7/21.

We did eventually determine the problem but I completely forgot to update the thread .

For some reason on our problem server the caching-nameserver rpm got installed.

They key is to uninstall it.

Unfortunately it deletes the named.conf file when you do it.

So here's what we've written in our internal HowTo:

Save the named.conf also maybe the hints file (usually /var/named/named.ca) ... then remove caching-nameserver ...
then restore your config files and you should not have this issue in the future.

Jeff

I had this problem with FreeBSD 5.4 when I updated the kernel source.

How can I restore the named config files?

The only way I know to restore /etc/named.conf is from a good backup.

You could create on manually, or create a script to write one, based on your zone files.

Jeff

i fell into this trap and i am thankful that this information was posted.

once i restore named.conf, and restart named, shouldn't the domains resolve instantly?

i'm having an issue where only a couple domains resolve now.

in: /etc/sysconfig/named

take out the value of the ROOTDIR and restart named.

fixed.

Thanks a lot Jeff!

Thanks for the post!

I do have this problem.

All DNS entries are gone in the DA DNS administratiob. I had to log into DA and punch in all the name, IP and nameservers.

Will this be fine after rebooting?

So this is what I did...

1) mv /etc/named.conf /etc/named.bak
2) mv /etc/named.conf.rpmsave /etc/named.conf
3) in: /etc/sysconfig/named
code:#ROOTDIR=/var/named/chroot
ROOTDIR=
4) restarted named from DA admin panel.

***** Referring to this...
What happened here anyway? Was it a BIND update?

Save the named.conf also maybe the hints file (usually /var/named/named.ca) ...
What are hint files???

then remove caching-nameserver ...
How and where?

then restore your config files and you should not have this issue in the future.
Why in the future we don't have problem? would YUM update that one day again?

Thanks for the help everyone!