BIND DNS domain : No DNS zone found for domain

After upgrading to 3.58 some settings/configurations with BIND or Virtualmin are corrupt. When I Validate my virtual servers, I’m now getting an error “BIND DNS domain : No DNS zone found for domain” for all domains. I’m not sure if this is a bug. I’ve been searching for anything related to this but haven’t seen anything close.

How can I restore these settings or fix this error.
Backup virtual server reports “Copying records in DNS domain …
… domain not found!”
I’ve restored a backup and everything is still there but I still have the same error.
BIND still has all the DNS info when I go to the BIND module in Webmin.

I’m on CentOS 5.1

Any help or ideas much appreciated.

Casey

First time I have seen this happen. We would need to have access to your box of course to fix this error.

We’ve seen this show up with several upgrades from CentOS 5.1 to 5.2.

It seems like something happens to switch the BIND install from using a chrooted configuration to a non-chrooted configuration…which means that all of your zone files are sitting unusued in /var/named/chroot/var/named, while BIND is looking in /var/named.

Is there a quick fix, I keep hitting my head. I’ve even compared two systems for differences and I must be overlooking something.

Casey

Look at your startup script for named and remove the "-t " part. But this file will be over-written each time you upgrade bind.

Look at your startup script for named and remove the "-t " part. But this file will be over-written each time you upgrade bind.

As Scott mentioned, this change would get overwritten (or cause the initscript to stop being updated–depends on whether it’s a %config file in the RPM).

Changes like this on CentOS/RHEL/Fedora are usually made in /etc/sysconfig. In this case, check the contents of /etc/sysconfig/named. On my systems with chroot enabled, I see this:

ROOTDIR=/var/named/chroot

I still have no clue why all these distro’s are even doing this.

The last time bind had any sort of security issue was 5 years ago and that’s when they should have used chroot.

Forcing chroot now not only pisses me off but totally screws up everyones bind and zone files. It’s rude and shows complete lack off flippin common sense.

Forcing chroot now not only pisses me off but totally screws up everyones bind and zone files. It's rude and shows complete lack off flippin common sense.

It seems like they agree with you…but they’re changing it to non-chroot without warning. Which is, I think, even worse than keeping chroot. :wink:

But, maybe it is going the other way. I dunno.

Mandriva is even worse – those french idiots have completely ruined bind – so badly that I had to use chattr +i on the init script just to make sure they can never screw up my zones.

Well, I’ve been checking out the settings and comparing them side by side with my other system and they are the same, even down to ROOTDIR=/var/named/chroot

I’ve uninstalled bind and re-installed it via Yum but to my surprise that didn’t do anything.

I’ve been a little slow on this as I’ve been out sick basically since the issue happen.

I’m not the best as trying to get these fixed on my own but I appreciate any help.

Casey

I think we have done all we can as helping on here – I would suggest paying a few bucks ($25) at least for me to login and look at what is wrong or if Joe/Jamie have time they probably will do it for free.

I saw this same problem when I upgraded. For me, I noticed that the bind upgrade had renamed my named.conf file and replaced it with a new one. I just moved the old file back and restarted bind.

That did the trick. Thanks!

Thanks for all your help everybody!

Casey

I noticed that the bind upgrade had renamed my named.conf file and replaced it with a new one.

Brilliant! I can’t believe I didn’t think of that. I’ve seen it happen many times over the years with various services, and for some reason didn’t think to mention it.

Yes, checking for .rpmsave files after an upgrade that breaks stuff is a good practice.