• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

[Issue with DNS Server (BIND) after having added a new IP]

Originally posted by jamesyeeoc
By 'valid' I meant: are both IPs listed both currently assigned to your server, or is one of them the 'old' IP which should have been removed?

The .pid file does not exist if the process is not started. But since your domains are resolving it has to be running.

Have you done a:

ps -ax |grep 'named'

to see if named (bind) is actually running as a process?

And a locate command to see if named.pid exists anywhere on your system:

locate named.pid

By writing "ps -ax |grep 'named'" in the console command I get ""Warning: bad syntax, perhaps a bogus '-'? see /usr/share/doc/procps-3.2.3/FAQ

7523 pts/0 R+ 0:00 grep named"


and when I write down "locate named.pid" nothing happens
 
Originally posted by dhthwy
zone "61.171.209.in-addr.arpa" {
type master;
file "61.172.209.in-addr.arpa";
allow-transfer {
common-allow-transfer;
};

I'm not a DNS expert but

the in-addr.arpa zone is for class C delegation.
reverse won't work if you only have two IP's using that zone.

your ISP should have given you a different zone to use
for CNAME delegation.

see: http://www.faqs.org/rfcs/rfc2317.html

your domains are probably in your parent ISP's nameservers. that would explain why they still resolve. what are your domain names?

I'm new to plesk but I think you can configure plesk to run named as root. there's a file called sysconfig.named.in in psa/etc

I'd try having it run as root if you can and see what happens.

No they are directly forwarded to the IP, not to the ISP nameservers. I've done the forwarding / dns configuration.

I really wouldn't want to have plesk running as root as it is too risky.

I'm not sure I understand what you are trying to say, but when I reverse DNS both IPs, the result is the one above (in addr arpa thing)

Thanks for the help nonetheless :)
 
If you need to know anything let me know... I'll write it down here whenever I get the time.

Thanks again
 
What i was saying is that your PTR records are useless unless you have a full /24 or a cnamed zone but that's off topic and isn't the reason your named won't start.

try a killall -9 named
that will kill named if its running.

I think your security settings have been changed and has broken named. I mentioned to try running it as root just as a test to see if it will run. you don't have to keep it running as root.
 
I tried to run it a while ago with a command I saw in another thread on the same problem, and I didn't work (from root)

the service is said to be down and when you want to launch it, there is an error (cf: the log on the main post)


thanks
 
isn't there anyone there who is able to help me?

This unstability issue in Plesk may happen to just anybody out there
 
yet another bump, please any experimented user which may give me some indication or request information :[
 
Hi!

I have/had a similiar problem with named/bind (Plesk 7.5.4, Suse 9.3).

Please check whether the named service is running.

/etc/init.d/named restart

If this fails, check the warn logfile under /var/log for the reason.

I got a "loading configuration: permission denied".

This happened after I added a domain with Plesk.

Solution:

Plesk changed the rights on /var/lib/named/etc/named.conf

It should be

Owner: RW, Group: R, World: R

Plesk set

Owner: RW, Group: none, World: none.

After correcting this with chmod back to 644, the problem was solved.

But as far as I can see, Plesk has currently a lot of problems where handling internal files improperly. I have a similiar problem with mailman's where it only runs after deleting mm_cfg.pyc and restarting mailman.

Bye,

Andreas
 
Originally posted by akxak
Hi!

I have/had a similiar problem with named/bind (Plesk 7.5.4, Suse 9.3).

Please check whether the named service is running.

/etc/init.d/named restart

If this fails, check the warn logfile under /var/log for the reason.

I got a "loading configuration: permission denied".

This happened after I added a domain with Plesk.

Solution:

Plesk changed the rights on /var/lib/named/etc/named.conf

It should be

Owner: RW, Group: R, World: R

Plesk set

Owner: RW, Group: none, World: none.

After correcting this with chmod back to 644, the problem was solved.

But as far as I can see, Plesk has currently a lot of problems where handling internal files improperly. I have a similiar problem with mailman's where it only runs after deleting mm_cfg.pyc and restarting mailman.

Bye,

Andreas

HI,
First of all thanks for taking the time for helping me, its apreciated.

I cannot restart it from the root either, and many of the aformentioned (the same as on the first page of the topic in which I pasted the log) message log file errors have to do with permissions.

While my named.conf isn't in /var/lib/named/etc/named.conf but in /etc, it was 644 so I suppose this is not the problem.
 
My named.conf is also in /etc, but the file is not really there, but is symlinked to /var/lib/named/etc (try an ls -l on the directory to see the symlink).

It might be the same for your system.

Bye,

Andreas
 
Thanks for the help :)

the directory you mentioned was empty, should I create it and upload it with the correct CHMOD settings ?
 
That depens where the symlink of your named.conf in /etc points to. If you can open the symlink and view its content, then the file is anywhere.

If you do not use Suse 9.3, your named might be anywhere else.

Check the target of the symlink.

Bye,

Andreas
 
I've written whereis named, and it gave me back the following information:

"named: /usr/sbin/named"(<= this one is chmod 755) and "/etc/named.conf"(<= this has the "windows shortcut icon" but I could open it and see its actual content, its on chmod 644" and "/usr/share/man/man8/named.8.gz"(<= 644)
 
Well, do not only check the permissions of the symlink, go to the directory as stated in the symlink and check the permissions of the file there.

Bye,

Andreas
 
Originally posted by akxak
Well, do not only check the permissions of the symlink, go to the directory as stated in the symlink and check the permissions of the file there.

Bye,

Andreas

How do we know the direction of the symlink? :confused: :eek: :p

I'm new to Unix server management :D

Thanks for help
 
Log into the server (via SSH).

cd /etc
ls -l named.conf

the result will be something like

@named.conf -> /var/lib/named/etc/named.conf

There you see the real path

Switch to that dir

cd /var/lib/named/etc

ls -l named.conf

then you see the permissions. They should be

-rw-r--r--

If they are not, you can correct them with

chmod 644 named.conf

Bye,

Andreas
 
It is already chmodded 644 :( I guess your solution is not the right one

Thanks however for taking the time to try and help me its apreciated













anyone else has any suggestion please??
 
Back
Top