DirectSlave - solution to add and remove zones on slave without DirectAdmin

[Richard G]

but still refused for zone file.

Check all 3 of the directslave logs, maybe something points in the right direction.

 

[apopovski]

I have made the changes here is the named.conf file.


//
// named.conf
//
// Provided by Red Hat bind package to configure the ISC BIND named(8) DNS
// server as a caching only nameserver (as a localhost DNS resolver only).
//
// See /usr/share/doc/bind*/sample/ for example named configuration files.
//

acl "trusted" {
127.0.0.1;
localhost;
212.110.95.4;
212.110.95.71;
212.110.64.0/19;
212.110.95.69;
10.70.70.0/24;
176.9.117.123;
176.9.117.108;
185.107.216.253;
};

acl "outside" {
176.9.117.123;
176.9.117.108;
212.110.95.4;
212.110.95.71;
212.110.64.0/19;
212.110.95.69;
10.70.70.0/24;
185.107.216.253;
any;
};

include "/etc/rndc.key";

controls {
inet 127.0.0.1 port 953 allow { localhost; 127.0.0.1 ; 212.110.95.71; } keys { "rndc-key"; };
};

options {
# listen-on port 53 { 127.0.0.1; 176.9.117.123;176.9.117.108;};
# listen-on-v6 port 53 { ::1; };
listen-on port 53 { any; };
listen-on-v6 port 53 { any; };
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
secroots-file "/var/named/data/named.secroots";
recursing-file "/var/named/data/named.recursing";
# allow-query { "trusted";};
allow-query { any;};
# allow-recursion {"trusted"; 212.110.95.0/24;};
allow-recursion {212.110.95.0/24;};
allow-transfer { "trusted"; 176.9.117.123; 176.9.117.108;};
# allow-query-cache { "trusted";};

/*
- If you are building an AUTHORITATIVE DNS server, do NOT enable recursion.
- If you are building a RECURSIVE (caching) DNS server, you need to enable
recursion.
- If your recursive DNS server has a public IP address, you MUST enable access
control to limit queries to your legitimate users. Failing to do so will
cause your server to become part of large scale DNS amplification
attacks. Implementing BCP38 within your network would greatly
reduce such attack surface
*/
recursion yes;

dnssec-validation yes;

managed-keys-directory "/var/named/dynamic";
geoip-directory "/usr/share/GeoIP";

pid-file "/run/named/named.pid";
session-keyfile "/run/named/session.key";

/* https://fedoraproject.org/wiki/Changes/CryptoPolicy */
include "/etc/crypto-policies/back-ends/bind.config";

};

logging {
channel default_debug {
file "data/named.run";
severity dynamic;
};
};

zone "." IN {
type hint;
file "named.ca";
};

include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";
include "/var/named/named.conf";

 

[Richard G]

allow-transfer { "trusted"; 176.9.117.123; 176.9.117.108;};

Also possible, but not required as the DS server will not be doing any transferring if it's only a DS server. so you could just as well set this to none.
Only on your DA server, you need the Directslave server ip in the allow-transfer line. Because only the DA server will do transfers.

However, since it's limited here you can also leave it as is.

acl "outside" {

I don't know why you put all the ip's in there since you have the "any" as last line anyway, so in that case every ip is allowed.

But it looks good. I never use ACL's and just keep it simple, but I don't use many servers so that's another reason.

controls {
inet 127.0.0.1 port 953 allow { localhost; 127.0.0.1 ; 212.110.95.71; } keys { "rndc-key"; };
};

this one is totally unknown to me at the moment. So I've looked it up, but you don't need that at all.
Not a single remove service, not even your own DA server is required to use your rndc system on your DS server. Only localhost so only the DS server itself will use rndc to restart named. So this line is obsolete / not necessary at all.

I think it should work like this.
Still having zone file issues?

 

[apopovski]

Error on master server :
Dec 23 18:29:08 galaxy named[1366314]: client @0x7f2b7c6159a0 212.110.95.4#60865 (proba2.mk): zone transfer 'proba2.mk/AXFR/IN' denied

error on slave server:
Dec 23 17:31:10 ns2 named[1725]: zone proba2.mk/IN: Transfer started.
Dec 23 17:31:10 ns2 named[1725]: transfer of 'proba2.mk/IN' from 176.9.117.108#53: connected using 212.110.95.4#45969
Dec 23 17:31:10 ns2 named[1725]: transfer of 'proba2.mk/IN' from 176.9.117.108#53: failed while receiving responses: REFUSED
Dec 23 17:31:10 ns2 named[1725]: transfer of 'proba2.mk/IN' from 176.9.117.108#53: Transfer status: REFUSED
Dec 23 17:31:10 ns2 named[1725]: transfer of 'proba2.mk/IN' from 176.9.117.108#53: Transfer completed: 0 messages, 0 records, 0 bytes, 0.029 secs (0 bytes/sec) (serial 0)

nothing in directslave logs for the past one hour.

 

[Richard G]

zone transfer 'proba2.mk/AXFR/IN' denied

AFXR denied, looks like the "allow-transfer" on the master server is not setup correctly.

Or.....

transfer of 'proba2.mk/IN'

The domain proba2.mk is non existing or not resolving yet, an nslookup proba2.mk does not give any ip.

I have to work somewhere else now. Might be back in an hour or 2.

 

[apopovski]

I don't know why you put all the ip's in there since you have the "any" as last line anyway, so in that case every ip is allowed.

But it looks good. I never use ACL's and just keep it simple, but I don't use many servers so that's another reason.

It was from previous setting when it wasnt set to any. I just didnt remove it. It makes no difference I believe since not used. Just for me to remember which IPs are there.

this one is totally unknown to me at the moment. So I've looked it up, but you don't need that at all.
Not a single remove service, not even your own DA server is required to use your rndc system on your DS server. Only localhost so only the DS server itself will use rndc to restart named. So this line is obsolete / not necessary at all.

Well I will disable this. The thing is that for many years we have a kind of twisted dns setup and it was like that from who knows when. Initially long time ago we had primary dns and secondary dns with separate webserver. After moving on towards cpanel the webserver become webserver and ns3. In that situation the zones were pushed from ns3 towards primary dns and ns2. On the dns and ns2 we only added manually to revers zones our /24s that we had but were part of the local network.

I think it should work like this.
Still having zone file issues?

still no zone file transfer unfortunately.

 

[Richard G]

still no zone file transfer unfortunately.

No but that domain does not exist according to internet, because proba2.mk is not resolving. But if I'm correct also non existing test domains should work. So maybe that is no problem.

The thing is that for many years we have a kind of twisted dns setup and it was like that from who knows when.

Why not try with something that DA creates, without all the fuzz.

Just try first if default simple things work. Backup your /etc/named.conf files from both your DS and DA server, then try and use just this:

On your DS server:

options {
        listen-on port 53 { any; };
        listen-on-v6 port 53 { any; };
        directory       "/var/named";
        dump-file       "/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";
        memstatistics-file "/var/named/data/named_mem_stats.txt";
        secroots-file   "/var/named/data/named.secroots";
        recursing-file  "/var/named/data/named.recursing";
        version "private";
        allow-recursion { localnets; localhost; };
        allow-notify { 12.34.56.789; };
        allow-transfer { none; };
        allow-query     { any; };
        empty-zones-enable no;

        dnssec-enable yes;
        dnssec-validation auto;

        managed-keys-directory "/var/named/dynamic";
        geoip-directory "/usr/share/GeoIP";

        pid-file "/run/named/named.pid";
        session-keyfile "/run/named/session.key";

        /* https://fedoraproject.org/wiki/Changes/CryptoPolicy */
        include "/etc/crypto-policies/back-ends/bind.config";
};

logging {
        channel default_debug {
                file "data/named.run";
                severity dynamic;
        };
};

zone "." IN {
        type hint;
        file "named.ca";
};

include "/etc/rndc.key";
include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";
include "/etc/named/directslave.inc";

Change the "allow-notify" ip to your DA server ip and change the last "include" line to the correct location of your directslave.inc file or named.conf if you put that name in your directslave.conf file.

Now use this on the DA server:

options {
        listen-on port 53 { any; };
        listen-on-v6 port 53 { any; };
        directory       "/var/named";
        dump-file       "/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";
        memstatistics-file "/var/named/data/named_mem_stats.txt";
        secroots-file   "/var/named/data/named.secroots";
        recursing-file  "/var/named/data/named.recursing";
        version "private";
        allow-recursion { localhost; localnets; };
        allow-transfer { 98.76.54.321; };
        allow-query     { any; };
        empty-zones-enable no;

        dnssec-validation yes;

        managed-keys-directory "/var/named/dynamic";
        geoip-directory "/usr/share/GeoIP";

        pid-file "/run/named/named.pid";
        session-keyfile "/run/named/session.key";

        /* https://fedoraproject.org/wiki/Changes/CryptoPolicy */
        include "/etc/crypto-policies/back-ends/bind.config";
};

logging {
        channel default_debug {
                file "data/named.run";
                severity dynamic;
        };
};

zone "." IN {
        type hint;
        file "named.ca";
};

include "/etc/rndc.key";
include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";

In here change the allow-transfer to your Directslave server ip.

In both configs you can eventually leave out the /etc/rdnc.key include but it should work with it.

You can copy and paste them to be sure to not forget some accolade or ; or something.

Now restart named on both servers. Try to transfer a domain. Does it work? If yes, then you can go play with ACL's if you need them.
But in fact, they are not needed as no other system then only the one with the ip can transfer something.

If this does not work, then we can seach on other places, then for sure the named.conf files or ACL's are not causing odd things.

 

[apopovski]

Hello Richard,

Thank you for the help and assistance I appreciate it a lot. I have done what you wrote above and its working now. I had to adjust something in terms of directory file. When I set the above with working directory to /etc/named/secondary I got the following error :

dumping master file: /etc/named/secondary/tmp-jJbtna8ryV: open: permission denied

Since it was a different error from previous I believed it was related to local file/folder permissions. On one post related to the error itself it was mentioned that system security settings might prevent saving dns zones files on other locations other then /var/named location. (it was for ubuntu and apparmor preventing this). So for that reason in directslave.conf I set the directory folder to /var/named/slaves I recreated the test domain and the file was created within and zone was written in include file.

In short I believe the whole circus was around allow-transfer settings on DA server which brings me to a question why when you add a server in a multi-server settings its ip is not added to the named.conf on DA server. Also will this setting remain or maybe some custombuild update will replace allow-tranfer setting.

Need to check now if everything will be good with live production of directslave and setting up the third name server.

Thank you again for all the help.
Alex

 

[Richard G]

why when you add a server in a multi-server settings its ip is not added to the named.conf on DA server.

The reason for this is that the multi-server setup of DA normally does not work that way. It's intended for use between 2 DA servers or a personal license only working as DNS slave. In that case the communication is done directly between both DA servers via port 2222.
This is the same way that Directslave worked in the beginning.

However, Roman discovered some flaw if one of the systems was offline some time and changes were made, slave was not updated or something so he changed how Directslave worked, and had the DA multi-server setup send the changes but let Directslave work kind of like a real bind slave, which requires the transfer-allow and notify settings. So that is the reason.

If you would use a personal license as DNS slave only for multi server setup, this issue would not have occured, however Directslave works just as fine once you have it running and is free.

As for my help, you're welcome.
And you know where to be if you encounter other issues or questions.

 

[apopovski]

Thank you Richard I understand now if I knew we could have made the change from start but at least the issue is resolved.

I have removed the nftables and firewalld installed iptables and csf its all good. I have one small issue which I am kind of stuck now. Not that is crucial but if I could figure out a way too fix it would save me some future work. I have installed letsencrypt standalone version and certificate is generated. I have created symblic links inside csf/ui folder towards the cert file under letsencrypt folder. CSF user interface is working and accessible. However I am having a problem to make it work under directslave. The problem is that directslave runs under named user and the certificates are created as root. There are several ways to do it (various scripts etc) but I just wondered what would be the best way to do it.

 

[apopovski]

Just an update I noticed that the original certification files under /etc/letsencrypt/archive: fullchain1.pem and privkey1.pem are owned by named. So i tried symlink: ln -s /etc/letsencrypt/archive/ns2.mol.com.mk/privkey1.pem /usr/local/directslave/ssl/privkey.pem as root but the symlink file were created with root:root rather then then having permissions like the original file. Not sure should I try and use chown -h on sym link file or its should be done some other way. Actually I did try chown -h and it changes the permissions of the sym file to named:named but still the file is not accessable I assume due to the fact that archive/ns2.mol.com.mk is owned by root.

 

[Richard G]

Sorry I can't help you with that. I don't have my DS running in https mode. Maybe best is to create a seperate topic for that as this is more LE related than DS related.

 

[urgido]

Hi

Since couple of days ago I am experimenting an issue deleting dns zones from directslave.inc. When I add a domain on my DirectAdmin server the dns zone are replicated correclty to DirectSlave but when I remove the domain on Directadmin's server the dns zones keeps on DirectSlave server. Here is what I have.

2025/07/16 09:16:46 Failed to move .tmp file rename /etc/named/directslave.inc.tmp /etc/named/directslave.inc: no such file or directory

under /etc/named: -rw-r--r-- 1 named named 41679 Jul 16 09:21 directslave.inc

DEBUG: &{MethodOST URL:/CMD_API_DNS_ADMIN Proto:HTTP/1.0 ProtoMajor:1 ProtoMinor:0 Header:map[Authorization:[Basic HGjGHGJKghAH] Content-Length:[94] User-Agent:[DA-Socket-Class]] Body:0xc000146500 GetBody: ContentLength:94 TransferEncoding:[] Close:true Host:IP_DIRECTSLAVE Form:map[] PostForm:map[] MultipartForm: Trailer:map[] RemoteAddr:IP_DIRECTADMIN_SERVER:60258 RequestURI:/CMD_API_DNS_ADMIN TLS: Cancel: Response: ctx:0xc000256b70}

The db files are deleted from secondary folder but the zones keep at directslave.inc so, I need to manual remove the domain from this file and then restart named.



Can somebody guide me how I can fix it? Any help is really appreciate.
Thanks

 

[Richard G]

I had posted a post, but deleted it. Seems the issue is back in my case too:

2025/03/13 14:59:33 Failed to move .tmp file rename /etc/named/directslave.inc.tmp /etc/named/directslave.inc: no such file or directory

I'm going to do some test later on today. Might have fixed it in march, but I'm not sure now anymore.

 

[zEitEr]

2025/03/13

The error is 4 months old. Do you have any new occurrences, Richard?

 

[Richard G]

Do you have any new occurrences, Richard?

Not yet, but that could also be because no domains were removed on the servers connected with DS. That's why I said I would do some testing later today.

I just now had time do to the test and the error still occurs indeed.

2025/07/16 19:18:40 Failed to move .tmp file rename /etc/named/directslave.inc.tmp /etc/named/directslave.inc: no such file or directory

I thought I had fixed the issue, but that was probably on the previous VPS. However, this error is quite clear. The directslave.inc.tmp is non existing (becasue the directslave.inc is). Only reason can be that it has no rights to be created by named.

And now I remember what I did last time. I changed owner of the /etc/named directory to named.
So one can do either that, or set the write permissions of the folder to the named group.

And then everything is working as designed again.

 

[urgido]

Not yet, but that could also be because no domains were removed on the servers connected with DS. That's why I said I would do some testing later today.

I just now had time do to the test and the error still occurs indeed.

2025/07/16 19:18:40 Failed to move .tmp file rename /etc/named/directslave.inc.tmp /etc/named/directslave.inc: no such file or directory

I thought I had fixed the issue, but that was probably on the previous VPS. However, this error is quite clear. The directslave.inc.tmp is non existing (becasue the directslave.inc is). Only reason can be that it has no rights to be created by named.

And now I remember what I did last time. I changed owner of the /etc/named directory to named.
So one can do either that, or set the write permissions of the folder to the named group.

And then everything is working as designed again.

Currently, I had named as owner and group.