Named not starting after yum update

D

Daskew

Verified User
Joined
May 25, 2006
Messages
80
Location
Clitheroe, UK
Hello,
I did a yum update which seemed to have a new version of bind included.

Now named wont start and I get the following error:

[root@fs1 custom]# service named start
Starting named:
Error in named configuration:
zone localhost/IN: loading master file localhost.zone: file not found
_default/localhost/IN: file not found
zone 0.0.127.in-addr.arpa/IN: loading master file named.local: file not found
_default/0.0.127.in-addr.arpa/IN: file not found

Then it goes on to list all the zone files... any help please?

I'm guessing i might have to re-install it through DA but im not sure how.

p.s. This is a multi server DNS setup in case that makes a difference, I don't want to do anything that will wipe any zone files
 
Look in /etc/init.d
After yum update you have a new named (named.rpmnew)
Try to start with named.rpmnew
If everything is ok rename named.rpmnew to named
 
Herbert said:
Look in /etc/init.d
After yum update you have a new named (named.rpmnew)
Try to start with named.rpmnew
If everything is ok rename named.rpmnew to named
Click to expand...

That will solve nothing unless there are multiple named.conf files on the system.
 
Huh?

A better response might be to point out that the file in question is probably named rpm.conf.rpmnew, and of course the zone records have to be added to the new file.

Closer to the point: the problem is probably due to differences in whether or not one (either old or new) was chrooted bind, while the other wasn't, or similarly if one was a recursive (caching) nameserver while the other was authoritative only.

Jeff
 
I had this happen to several of my servers and no they are not chrooted. It like the installation deleted the named.local and localhost.zone.

The easiest fix was to:

Code: 
cd /var/named
wget http://www.directadmin.com/localhost.zone
wget http://www.directadmin.com/named.local

What I don't understand is why the files got deleted. They were there before. And why were only a few servers affected? They are all running the same OS and all run yum update automatically.
 
HI,
I've gone mad over the weekend and had to format the server as I ddin't know how to fix it and broke the server trying guides I didn't understand.

I have another server to update, If I do this and it breaks bind again, will running those commands definitely fix it?

I cannot take the risk of it being down or loosing clients data if it goes wrong again.

Thanks
 
<edit>
I'm wrong; I for some reason was thinking of the wrong files. I probably hadn't had my first cup of coffee yet when I made this post. I'm leaving it in because the thread loses focus without it, but you may safely ignore it and the replies specifically to it, though the general concern about caching nameservers still stands as good information.
</edit>

Replying to both Floyd and to Daskew:

If your named.conf file has references to these files then either your nameserver is a caching nameserver or your named.conf file has some leftover lines from when it was installed as a caching nameserver.

Why you shouldn't use your nameserver as a caching nameserver and also as an authoritative nameserver has been discused ad nauseum in these and other forums many times; you should make sure you don't list your own nameservers (either as 127.0.0.1, localhost, or your own IP#(s) in your /etc/resolv.conf file) and then editing named.conf to no longer look for these files (you may find you have to remove other lines as well once you've removed these lines, before BIND will start without error; if you're not sure what you're doing you may want to hire someone who is.

Important Note: if there are references to your own nameserver in your /etc/resolv.conf file you must first find caching nameservers to use; you can usually get them from your upstream bandwidth provider.

Of course you may get the files and put them where they belong, and then restart the named daemon, but nameservers that are both authoritative and caching are definitely a security risk.

Jeff
 
Thanks for your reply,

My upstream provider provides me with nameservers so thats not an issue for me.

However i'm unsure what i'm looking for in /etc/named.conf

Here's is a copy of mine, would you mind checking it please?

// generated by named-bootconf.pl

options {
directory "/var/named";
/*
* If there is a firewall between you and nameservers you want
* to talk to, you might need to uncomment the query-source
* directive below. Previous versions of BIND always asked
* questions using port 53, but BIND 8.1 uses an unprivileged
* port by default.
*/
// query-source address * port 53;

allow-transfer { none; };
allow-recursion { localnets; };
};

//
// a caching only nameserver config
//
controls {
inet 127.0.0.1 allow { localhost; } keys { rndckey; };
};
zone "." IN {
type hint;
file "named.ca";
};

zone "localhost" IN {
type master;
file "localhost.zone";
allow-update { none; };
};

zone "0.0.127.in-addr.arpa" IN {
type master;
file "named.local";
allow-update { none; };
};

include "/etc/rndc.key";

Then it lists all the zone files, is this setup right?
 
It still does not explain why the files would get deleted.


Of course you may get the files and put them where they belong, and then restart the named daemon, but nameservers that are both authoritative and caching are definitely a security risk.
Click to expand...

In that case I think the default directadmin install would not make references to those files.

Default install from directadmin has this in named.conf:

Code: 
zone "localhost" IN {
        type master;
        file "localhost.zone";
        allow-update { none; };
};

zone "0.0.127.in-addr.arpa" IN {
        type master;
        file "named.local";
        allow-update { none; };
};
 
jeff said:
Replying to both Floyd and to Daskew:

If your named.conf file has references to these files then either your nameserver is a caching nameserver or your named.conf file has some leftover lines from when it was installed as a caching nameserver.
Click to expand...

jeff said:
Of course you may get the files and put them where they belong, and then restart the named daemon, but nameservers that are both authoritative and caching are definitely a security risk.
Click to expand...

Reply to Jeff:

I just started a default install of DA and here are the relevant lines:

Code: 
--14:29:22--  http://66.51.122.131/named.conf
Connecting to 66.51.122.131:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 949 [text/plain]
Saving to: `/etc/named.conf'

100%[=========================================================================================================================================>] 949         --.-K/s   in 0s     

14:29:22 (50.9 MB/s) - `/etc/named.conf' saved [949/949]

--14:29:22--  http://66.51.122.131/named.ca
Connecting to 66.51.122.131:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2769 (2.7K) [text/plain]
Saving to: `/var/named/named.ca'

100%[=========================================================================================================================================>] 2,769       --.-K/s   in 0.1s   

14:29:25 (21.2 KB/s) - `/var/named/named.ca' saved [2769/2769]

--14:29:25--  http://66.51.122.131/localhost.zone
Connecting to 66.51.122.131:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 513 [text/plain]
Saving to: `/var/named/localhost.zone'

100%[=========================================================================================================================================>] 513         --.-K/s   in 0s     

14:29:26 (27.8 MB/s) - `/var/named/localhost.zone' saved [513/513]

--14:29:26--  http://66.51.122.131/named.local
Connecting to 66.51.122.131:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 433 [text/plain]
Saving to: `/var/named/named.local'

100%[=========================================================================================================================================>] 433         --.-K/s   in 0s     

14:29:29 (22.2 MB/s) - `/var/named/named.local' saved [433/433]

So the install copies the files into /var/named and the named.conf it copied has this. You see it for yourself at http://66.51.122.131/named.conf.

Code: 
// generated by named-bootconf.pl

options {
        directory "/var/named";
        /*
         * If there is a firewall between you and nameservers you want
         * to talk to, you might need to uncomment the query-source
         * directive below.  Previous versions of BIND always asked
         * questions using port 53, but BIND 8.1 uses an unprivileged
         * port by default.
         */
        // query-source address * port 53;

	allow-transfer { none; };
	allow-recursion { localnets; }; 
};

//
// a caching only nameserver config
//
controls {
        inet 127.0.0.1 allow { localhost; } keys { rndckey; };
};
zone "." IN {
        type hint;
        file "named.ca";
};

zone "localhost" IN {
        type master;
        file "localhost.zone";
        allow-update { none; };
};

zone "0.0.127.in-addr.arpa" IN {
        type master;
        file "named.local";
        allow-update { none; };
};

include "/etc/rndc.key";

So Jeff you tell me who is at fault for making bind a security risk?
 
Floyd,

I always let CentOS install BIND, and I remove the caching-nameserver RPM if it's installed (and also the chroot-bind RPM).

I'm not sure but I believe DirectAdmin only installs BIND if it's not already installed. Please verify your OS Distribution and whether or not you install BIND before you install DirectAdmin.

If DirectAdmin is installing BIND insecurely then yes, John should look into changing it.

Is that your point?

Jeff
 
I let CentOS install bind as well but DA put the localhost.zone and named.local files in /var/named and also installs the named.conf file that refers to them.

I have on occasion set up a caching name server. But I had problems on servers that never had a caching name server when bind updated this last time. Yum did not touch the named.conf file but it did delete the other two files from /var/named.

My point is that you should not act like it was something we did to break the servers. It was a combination of DA and the bind update. The two did not work together.
 
Your welcome. We are still talking about the topic YOU started. Your questions have been answered.
 
If you read past your thread you will see we are still discussing that. Jeff says no but if that is the case then why does DA do it?
 
You must log in or register to reply here.
Back
Top