Issue Slave DNS Manager: "named" service doesn't work on primary server

[ingmarcofilippini]

Hello to all,
I have installed Plesk Obsidian 18.0.31 on a CentOS machine.
Plesk works as the primary DNS for my websites and everything seems to work under the "named-chroot" service.
I then installed the "Slave DNS Manager" extension following the official procedure and configuring the slave DNS server (always CentOS machines) with "named" service installed and everything is working.

When I try to sync DNS zones from Plesk to Slave DNS server I get this error:

/usr/sbin/rndc -b "192.168.1.101" -s "100.200.300.401" -p "53" -y "rndc-key" -c "/usr/local/psa/var/modules/slave-dns-manager/slave_100.200.300.401.conf"

status rndc: connection to remote host closed
This may indicate that
* the remote server is using an older version of the command protocol,
* this host is not authorized to connect,
* the clocks are not synchronized,
* the key signing algorithm is incorrect, or
* the key is invalid.

Error code: 1

The IP address "100.200.300.401" it was invented now and is a public IP.


I've checked everything possible but I can't figure it out.
The only thing I can notice is that "named" service is not working on my primary Plesk server, if I check its status it has this error:

● named.service - Berkeley Internet Name Domain (DNS)
   Loaded: loaded (/usr/lib/systemd/system/named.service; disabled; vendor preset: disabled)
  Drop-In: /usr/lib/systemd/system/named.service.d
           └─disable.conf
   Active: failed (Result: exit-code) since mar 2020-11-24 15:31:10 CET; 21min ago

nov 24 15:31:10 plesk.example.com systemd[1]: Starting Berkeley Internet Name Domain .....
nov 24 15:31:10 plesk.example.com sh[6649]: Service 'named' was not restarted because...t.
nov 24 15:31:10 plesk.example.com sh[6649]: If you want to restart the 'named' servic...'.
nov 24 15:31:10 plesk.example.com systemd[1]: named.service: control process exited, ...=1
nov 24 15:31:10 plesk.example.com systemd[1]: Failed to start Berkeley Internet Name ...).
nov 24 15:31:10 plesk.example.com systemd[1]: Unit named.service entered failed state.
nov 24 15:31:10 plesk.example.com systemd[1]: named.service failed.
Hint: Some lines were ellipsized, use -l to show in full.
[root@rpsweb01 ~]# systemctl status named.service
● named.service - Berkeley Internet Name Domain (DNS)
   Loaded: loaded (/usr/lib/systemd/system/named.service; disabled; vendor preset: disabled)
  Drop-In: /usr/lib/systemd/system/named.service.d
           └─disable.conf
   Active: failed (Result: exit-code) since mar 2020-11-24 15:31:10 CET; 1h 51min ago

nov 24 15:31:10 plesk.example.com systemd[1]: Starting Berkeley Internet Name Domain .....
nov 24 15:31:10 plesk.example.com sh[6649]: Service 'named' was not restarted because...t.
nov 24 15:31:10 plesk.example.com sh[6649]: If you want to restart the 'named' servic...'.
nov 24 15:31:10 plesk.example.com systemd[1]: named.service: control process exited, ...=1
nov 24 15:31:10 plesk.example.com systemd[1]: Failed to start Berkeley Internet Name ...).
nov 24 15:31:10 plesk.example.com systemd[1]: Unit named.service entered failed state.
nov 24 15:31:10 plesk.example.com systemd[1]: named.service failed.
Hint: Some lines were ellipsized, use -l to show in full.

Another thin I point out is that they are 2 servers on the same private network and they go out with the same firewall but have a NAT on 2 different public IPs. On the firewall obviously all the ports are open for the 2 hosts.

Do you have in mind what it could be? It seems to me that the problem is at the very origin on primary server with Plesk. The "named" ("bind") service practically does not work right away when Plesk starts.

Thanks a lot.
Marco

 

[IgorG]

Perhaps RNDC secret key from the file /etc/named.conf does not match the key in /etc/rndc.conf.
Make sure that there is the same RNDC key in files /etc/named.conf and /etc/rndc.conf on both servers. For example:

# less /etc/named.conf |grep secret
secret "CeMgS23y0oWE20nyv0x40Q==";

# less /etc/rndc.conf |grep secret
secret "CeMgS23y0oWE20nyv0x40Q==";

 

[ingmarcofilippini]

Perhaps RNDC secret key from the file /etc/named.conf does not match the key in /etc/rndc.conf.
Make sure that there is the same RNDC key in files /etc/named.conf and /etc/rndc.conf on both servers. For example:

# less /etc/named.conf |grep secret
secret "CeMgS23y0oWE20nyv0x40Q==";

# less /etc/rndc.conf |grep secret
secret "CeMgS23y0oWE20nyv0x40Q==";

Thanks for the reply, Igor.
I checked that too.
Here a doubt arises: in the named.conf file I pasted my key provided by Plesk (the name of the key also has my public IP in the name), in the rndc.key file there was already a key. Do I just have to change "secret" or even the name of the key which in this case is generic and does not coincide with the one in named.conf?
Also, I don't see the rndc.key file invoked with "include" in the named.conf file. It's correct?

I have really tried to read all the forums, articles, tutorials but I don't find my mistake.

 

[ingmarcofilippini]

In my opinion the problem is on the primary Plesk machine, just because the status of "named" is on "failed", but maybe it has nothing to do with this, also because "named-chroot" on Plesk machine works correctly.

 

[IgorG]

The keys in these files should not be different. If so, fix it.

 

[ingmarcofilippini]

The keys in these files should not be different. If so, fix it.

I confirm that the keys are perfectly the same in both files.

    key "rndc-key-100.200.300.401" {
      algorithm hmac-md5;
      secret "NAQ2ZTBhMmi4MDBlNzliNjg0yTdjOA==";
    };

on /var/log/messages of the secondary server I see these lines:

Nov 25 09:56:40 slavedns named[12978]: network unreachable resolving './NS/IN': 2001:503:ba3e::2:30#53
Nov 25 09:56:40 slavedns named[12978]: network unreachable resolving './DNSKEY/IN': 2001:503:c27::2:30#53
Nov 25 09:56:40 slavedns named[12978]: network unreachable resolving './NS/IN': 2001:503:c27::2:30#53
Nov 25 09:56:40 slavedns named[12978]: network unreachable resolving './DNSKEY/IN': 2001:500:9f::42#53
Nov 25 09:56:40 slavedns named[12978]: network unreachable resolving './NS/IN': 2001:500:9f::42#53
Nov 25 09:56:40 slavedns named[12978]: network unreachable resolving './DNSKEY/IN': 2001:dc3::35#53
Nov 25 09:56:40 slavedns named[12978]: network unreachable resolving './NS/IN': 2001:dc3::35#53
Nov 25 09:56:40 slavedns named[12978]: network unreachable resolving './DNSKEY/IN': 2001:500:200::b#53

 

[IgorG]

Please check that ports are not firewalled to Slave DNS server:

# nmap -p53,953 ip_of_lave_dns_server

If they are filtered configure firewall on a slave DNS server and intermediate firewalls where applicable, so the master server will be able to access slave DNS server via port 953.

 

[ingmarcofilippini]

Please check that ports are not firewalled to Slave DNS server:

I confirm that the ports are open on the firewalls of the two servers and on the physical firewall (there is a NAT of all the ports on the public IP of the 2 machines).

# nmap -p53,953 ip_of_lave_dns_server

This is the output of nmap on the public IP of the slave server:

PORT STATE SERVICE
53/tcp  open  domain
953/tcp open  rndc

The slave server in the named.conf file has these lines:

options {
        listen-on port  53 { any; };
        listen-on-v6 port 53 { ::1; };

It is on port 53, in fact on Plesk I configure it on 53 in the Slave DNS extension. It's correct? If I use 953 the host does not reach me, even if I change it to "listen" of the slave server.

 

[ingmarcofilippini]

on /var/log/messages of the primary Plesk server I see these line a little suspicious:

Nov 25 11:10:10 ccplesk01 named[5151]: unable to open '/etc/bind.keys'; using built-in keys instead

The fact is that even if I uninstall the "Slave DNS Manager" extension and restart my Plesk server, the "named" service doesn't work on Plesk anyway. I don't understand if it's normal or not.

 

[tkalfaoglu]

the "named" service doesn't exist on my system either. named-chroot service exists and is enabled. Huge source of confusion IMHO.

 

[ingmarcofilippini]

Hi @IgorG, thanks for your support.

@tkalfaoglu Yes, I got confused; the "named" service has absolutely nothing to do with this problem. Thanks for your support.

The problem actually I think is on the physical firewall of my network, ie from the outside the DNS slave server does not respond correctly on port 953 of the RNDC, or it could be that something is wrong with the permissions, even if I set everything to "any".

I solved it by going to modify Plesk to use my local network IP (removing the public shared IP necessary for NAT), so I configured the DNS slave server with the extension, using the local IP of the DNS slave server, in this way it solves everything locally therefore does not go through the physical firewall and remains in my network (Plesk and the DNS slave are in the same local network).

Now it seems that the two sides are communicating correctly, but the records are not synchronized, although at the refresh it does not give me any errors from Plesk.

In the Slave server log I find these errors:

received control channel command 'refresh example.com IN '
zone example.com/IN: refresh: unexpected rcode (REFUSED) from master 100.200.300.401#53 (source 0.0.0.0#0)
zone example.com/IN: Transfer started.
transfer of 'example.com/IN' from 100.200.300.401#53: connected using 192.168.1.102#46969
transfer of 'example.com/IN' from 100.200.300.401#53: failed while receiving responses: REFUSED
transfer of 'example.com/IN' from 100.200.300.401#53: Transfer status: REFUSED
transfer of 'example.com/IN' from 100.200.300.401#53: Transfer completed: 0 messages, 0 records, 0 bytes, 0.001 secs (0 bytes/sec)

100.200.300.401 is the public IP address for my Plesk server and 192.168.1.102 is the local IP address for my slave DNS server.


MF

 

[ingmarcofilippini]

Actually from Plesk it seems to be connected correctly, but then it does not actually exchange zone data.

If I launch this from the Plesk terminal:

# rndc -b 192.168.1.101 -s 192.168.1.102 -p 953 -y rndc-key refresh example.com IN

The result is this again:

rndc: connection to remote host closed
This may indicate that
* the remote server is using an older version of the command protocol,
* this host is not authorized to connect,
* the clocks are not synchronized,
* the key signing algorithm is incorrect, or
* the key is invalid.