DirectSlave/GO 3 - public beta

And here we go again.

I added an IP in the directadmin named.conf.options to allow for 2 directslave installs and nothing works anymore.
I get:
client @**id** **directadmin ip**#45181: received notify for zone '**domain**': not authoritative
And no .db files.

And when I remove the second IP from the named.conf.options it still refuses to create the .db files. (I restarted named on DirectAdmin of couse.) :(
 
On DirectAdmin with multiple slave servers, the configuration would look like this:

Code:
  also-notify { slave1ip; slave2ip; slave3ip; slave4ip; };
  allow-transfer { slave1ip; slave2ip; slave3ip; slave4ip; };
  notify explicit;

This is how I have my servers setup on my servers, I have multiple clusters that shows up as 4 servers. They are not DirectSlave but same type of configuration.
 
On DirectAdmin with multiple slave servers, the configuration would look like this:

Code:
  also-notify { slave1ip; slave2ip; slave3ip; slave4ip; };
  allow-transfer { slave1ip; slave2ip; slave3ip; slave4ip; };
  notify explicit;

This is how I have my servers setup on my servers, I have multiple clusters that shows up as 4 servers. They are not DirectSlave but same type of configuration.
Thats what I did with the named.conf.options on DirectAdmin. But with that I get that message and no .db files.
And when I changed it back to just one DirectSlave IP I still got that message and no .db files.
 
Last edited:
Humm that's strange. Did bind stop working on the DirectAdmin/Master server when you made the change? Was bind restarted? Didn't miss typing one of the ";" (that one always gets me once in a while with bind). If you didn't change the slave the problem has to be on the master.
 
Humm that's strange. Did bind stop working on the DirectAdmin/Master server when you made the change? Was bind restarted? Didn't miss typing one of the ";" (that one always gets me once in a while with bind). If you didn't change the slave the problem has to be on the master.
If I do nslookup domain ns1 (ns1 = directadmin bind) then I get the correct IPv4 and IPv6 records back.
I also restarted named in directadmin and bind on the directslave server after every change I made to the conf/options files.
And no both IPs have a ;
My named.conf.options on DirectAdmin:
options {
directory "/var/cache/bind";

// If there is a firewall between you and nameservers you want
// to talk to, you may need to fix the firewall to allow multiple
// ports to talk. See http://www.kb.cert.org/vuls/id/800113

// If your ISP provided one or more IP addresses for stable
// nameservers, you probably want to use them as forwarders.
// Uncomment the following block, and insert the addresses replacing
// the all-0's placeholder.

// forwarders {
// 0.0.0.0;
// };

//========================================================================
// If BIND logs error messages about the root key being expired,
// you will need to update your keys. See https://www.isc.org/bind-keys
//========================================================================
dnssec-validation auto;

listen-on-v6 { any; };
also-notify { directslave1; };
allow-transfer { directslave1; };
notify explicit;
};

EDIT:
For now I just use one directslave just to make it easier to check what is going wrong.
 
Hmmz... I'm at the same place as you know.

I get a Transfer status: REFUSED. After a "deferred due to quota" so I might have been fuzzing too much. Don't know for sure.

But I'm working from a lan so it seems my LAN ip gets in the way.. have to figure some more out.
 
Last edited:
YES.. Ik heb het werkend. Er zit inderdaad een bugje in. Je kunt alles in stellen zonder notify dingens.
Ohja, die apparmor heb ik uitgeschakeld, just to be sure.

Maar schijnbaar is er toch iets veranderd. In plaats van de zones op te halen op de DA Multiserver, vindt er een AFXR plaats. Dat is het probleem, dat zou niet moeten gebeuren.

Feitelijk kun je dus alles opzetten zoals in de Readme van Directslave, alleen zul je op de master, dus de DA server inderdaad even een allow-transfer moeten gebruiken met het ip van de slave server.
Ik heb idem gedaan op de slave server in de named.conf.local en dan werkt alles en worden ook de zone files aangemaakt.

Daar zal Roman dan t.z.t. even naar moeten kijken. Hopelijk is alles goed met hem.

====
Sorry, in my enthousiasm I forgot to write in English, so for everybody else.

YES... I've got it working, it indeed contains a little bug. You can setup everything without using any notify lines.
Just to be sure I disabled apparmor for my testing purposes.

It seems something has changed. Instead of getting the zones via the DA Multiserver method, an AFXR is used. And that's the problem, because that should not happen.

In fact you can configure everything as mentioned in the Readme of Directslave, except hat on the master, so the DA server, you do need to use an allow-transfer line for the ip of the slave server.
I've done the same on the slave sever in the named.conf.local and then everthing works fine and all zone files are created.

Roman might want to have a look at that some time. Hope he's well.
 
Last edited:
YES.. Ik heb het werkend. Er zit inderdaad een bugje in. Je kunt alles in stellen zonder notify dingens.
Ohja, die apparmor heb ik uitgeschakeld, just to be sure.

Maar schijnbaar is er toch iets veranderd. In plaats van de zones op te halen op de DA Multiserver, vindt er een AFXR plaats. Dat is het probleem, dat zou niet moeten gebeuren.

Feitelijk kun je dus alles opzetten zoals in de Readme van Directslave, alleen zul je op de master, dus de DA server inderdaad even een allow-transfer moeten gebruiken met het ip van de slave server.
Ik heb idem gedaan op de slave server in de named.conf.local en dan werkt alles en worden ook de zone files aangemaakt.

Daar zal Roman dan t.z.t. even naar moeten kijken.
I can comfirm, removing the transfer settings from the slave and only have it on the master fixed it.

Thanks @Richard G.
And you might want to make an edit to your previous post and add the text in english. (I speak dutch too but alot of people do not.)

It is late for me but tomorrow I will updste my install script and should finally be able to release it so other users will not face these issues.
 
And it is not working again.

This is the script I made that I use to install DirectSlave: https://github.com/realcryptonight2/debian-install-scripts/blob/master/setup-directslave.sh
For now I also have the apparmor service stopped but I am still missing my .db files.

And I do have the transfer on the DirectAdmin server. And before it also worked. It just stopped working after a VPS wipe and running my install directslave script.

EDIT:

And the /etc/bind/directslave/ is owned by root:bind so it is not a permission problem.

EDIT 2:
It seems to be a permission issue since I do have permission denied in my bind9 log.
 
Last edited:
Found it.

Apparmor was the problem. Even tho I have the service stopped it still blocked the writes of the .db files.
 
And here we go again. On my US VPS:
Mar 28 05:59:02 **US VPS** named[7164]: client @**hidden** **DirectAdmin IP**#54454: received notify for zone '**domain**': not authoritative
And on my german VPS I get:
Mar 28 12:59:02 **DE VPS** named[8570]: zone **domain**/IN: transferred serial 2022032811
Mar 28 12:59:02 **DE VPS** named[8570]: transfer of '**domain**/IN' from **DirectAdmin IP**#53: Transfer status: success
Mar 28 12:59:02 **DE VPS** named[8570]: transfer of '**domain**/IN' from **DirectAdmin IP**#53: Transfer completed: 1 messages, 12 records, 380 bytes, 0.024 secs (15833 bytes/sec) (serial **hidden**)
Mar 28 12:59:02 **DE VPS** named[8570]: zone **domain**/IN: sending notifies (serial **hidden**)

Both VPS server have been setup with my DirectSlave script.
I also would like to note that the US VPS is wiped like 30/40 times in an hour.
So could it be a rate limit I reached due to DirectAdmin making alot of DNS updates?
And the keys constantly changing on the US VPS server due to the reset.

EDIT:
The time differents is due to the different time zones.
And it is weird that the US VPS server has this issue but not the DE VPS server.
 
This is the script I made that I use to install DirectSlave
I'm no scripter so I don't have a clue as to if that is 100% correct. But let's presume yes.

As for Apparmor, I did not remove it, I just stopped the service and then I stopped it for being started at bootup, so I did not uninstall it.

So could it be a rate limit I reached due to DirectAdmin making alot of DNS updates?
That could be the case, I have seen some "deferred" lines in my logs when I was doing a lot of the rewrite command to put over all DNS stuff.

As for time differents, if that might be an issue, why don't you just change the time on that US VPS to European time? I do that all the time. Even on our German servers, I change the keyboard and also time to Europe/Amsterdam while Europe/Berlin is in fact the same.

The only time I had the "not authoritative" notices in my logs, was when everything made contact and I had not used the dns rewrite command yet. After that, I didn't have those notices anymore.
 
Have a strange one..just built a new Ubuntu 20 server and DirectSlave will only listen on IPv6 address but not IPv4.

from netstat:

Code:
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 ns4.internal.clo:domain 0.0.0.0:*               LISTEN
tcp        0      0 localhost:domain        0.0.0.0:*               LISTEN
tcp        0      0 localhost:domain        0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:ssh             0.0.0.0:*               LISTEN
tcp        0      0 localhost:953           0.0.0.0:*               LISTEN
tcp        0      0 localhost:2223          0.0.0.0:*               LISTEN
tcp        0      0 ns4.internal.clouda:ssh       TIME_WAIT
tcp6       0      0 ns4:domain              [::]:*                  LISTEN
tcp6       0      0 ip6-localhost:domain    [::]:*                  LISTEN
tcp6       0      0 [::]:ssh                [::]:*                  LISTEN
tcp6       0      0 ip6-localhost:953       [::]:*                  LISTEN
tcp6       0      0 [::]:2222               [::]:*                  LISTEN
tcp6       0      0 [::]:2224               [::]:*                  LISTEN

My config is:

Code:
background 0

host  *

port            2222
sslport         2224

ssl             on
ssl_cert        /usr/local/directslave/ssl/mycert.crt
ssl_key         /usr/local/directslave/ssl/mykeykey

cookie_sess_id  DS_SESSID
cookie_auth_key <redacted>

debug           1
uid             113
gid             121

pid             /usr/local/directslave/run/directslave.pid
access_log      /usr/local/directslave/log/access.log
error_log       /usr/local/directslave/log/error.log
action_log      /usr/local/directslave/log/action.log

named_workdir   /etc/bind/secondary
named_conf      /etc/bind/secondary/directslave.conf
retry_time      1200
rndc_path       /usr/sbin/rndc
named_format    text

authfile        /usr/local/directslave/etc/passwd

Any suggestions?
 
I don't know if that works, but you could set named to only listen on ipv4 and see if that helps. You have to restart named and directslave afterwards.
I don't know which file that is on Ubuntu. On RH and alike it's /etc/sysconfig/named and then you have to add "OPTIONS=-4" OPTIONS="-4" to the file.
 
Yoooo @roman_m glad to see you again. Some of us were kind of worried since you're living in the danger zone.
We found a little issue since we need to use afxr now which wasn't the case before.

But that's for later, no hurry, more important is that you're alright!
 
Yoooo @roman_m glad to see you again. Some of us were kind of worried since you're living in the danger zone.
We found a little issue since we need to use afxr now which wasn't the case before.

But that's for later, no hurry, more important is that you're alright!
Hi Richard! Glad to see you! Yes, i'm still in Kyiv. There are no active battles around the city... the war is a nightmare anyway, f***g rockets is flying around us daily. I'm fine (have a two legs, two hands and a head), thanks, so I'm back to work.

What's the issue with axfr?

And thank you very much for your participation.
 
What's the issue with axfr?
Well... I haven't used Directslave for a while so I don't know what happened with all updates, so maybe it's working as designed.
But in the beginning we didn't need any afxr and permission to transfer DNS. The only thing needed was the way DA servers were connecting to each other via port 2222. This way they transfer domains.
I now in the beginning with Directslave, also all transfers were done the same way as DA does.

However, this is not working on the current version anymore. As you can see from recent posts.
So instead of the DA Multiserver method, the afxr method is used to do the transfers.

Unless this is changed in later versions, this is the issue I'm talking about. If it's done on purpose, then why has DS stopped working like DA did via the 2222 port only?

As for my participation, you're very welcome.
I'm very happy to hear you're fine and I hope the Ukraïne army will kick Putin out of there. Keep well!
 
The very first version of DS worked exactly as second DirectAdmin - it receive a full zone dump from DA then feed them to Bind.

Version >= 3.0 lost this behaviour for a reason: if you lost the connectivity between primary and secondary and some changes are done on the primary, the secondary does not fetch it. So point is to notify secondary about the new domain "hey bro, we have a new one, here!" and secondary should take care of the rest. Yep, there are a lot of headache with permissions, linux (f**k it!) firewall/apparmor/oomkiller... but if you tune it once, just forget about any issues.

PS: For now, I'm working on custom integrated DNS (based on miekg/dns) secondary-only server to completely get rid of ISC Bind and pack all the stuff in to the single directslave package.

Regards.
 
Back
Top