DirectSlave/GO 3 - public beta

cjd · Mar 26, 2022

Have you checked that it's working?

Code:

host one.of.your.domains ip.address.of.directslave

Just to do a lookup and see if it's working. Even if it's not writing to disk it should still be able to look up the domains.

Daniel_Dog · Mar 26, 2022

cjd said:
Have you checked that it's working?

Code:

host one.of.your.domains ip.address.of.directslave

Just to do a lookup and see if it's working. Even if it's not writing to disk it should still be able to look up the domains.

When I do a nslookup I get:

root@**directadmin server**:~# nslookup test.nl **ds server**
Server: **DS Server**
Address: **DS IPv6 address**#53

** server can't find test.nl: REFUSED

Is this good?

EDIT:
When I use a domain that should be in the DS then I get:
** server can't find **my domain**: SERVFAIL
But this seems to be because it is missing the .db file of that domain.

cjd · Mar 26, 2022

Is that domain on the DirectAdmin server? And also in the directslave.inc file?

Daniel_Dog · Mar 26, 2022

cjd said:
Is that domain on the DirectAdmin server? And also in the directslave.inc file?

Yes, that domain is added by DirectAdmin to DirectSlave.
It is also in the directslave.inc file. It just does not have a .db file in secondary for that domain that is linked in directslave.inc

cjd · Mar 26, 2022

OK then that's not good, are you sure it's reading the directslave.inc file?

Do you see any errors if you do a (it won't say anything if there are no errors):

Code:

named-checkconf /etc/bind/named.conf

If no errors do a full export of what's loaded:

Code:

rndc dumpdb -zones

And then check the export file, usually saved at on Debian:

Code:

/var/cache/bind/named_dump.db

Daniel_Dog · Mar 26, 2022

named-checkconf /etc/bind/named.conf: returns nothing.

rndc dumpdb -zones: returns nothing.

/var/cache/bind/named_dump.db: On the domains from DirectAdmin it says no zone loaded.

I think that the no zone loaded is due to the .db file missing in the secondary folder?
I have also include the dumb file with all the public domains removed.

cjd · Mar 26, 2022

Something is not right. What's the output of the following commands:

Code:

ls -la /etc/bind

cat /etc/bind/named.conf

cat /etc/apparmor.d/local/usr.sbin.named

grep 'named' /var/log/messages | tail

Daniel_Dog · Mar 26, 2022

ls -la /etc/bind
total 64
drwxr-sr-x 3 root bind 4096 Mar 26 15:13 .
drwxr-xr-x 74 root root 4096 Mar 26 12:54 ..
-rw-r--r-- 1 root root 1991 Mar 14 09:25 bind.keys
-rw-r--r-- 1 root root 237 Mar 14 09:25 db.0
-rw-r--r-- 1 root root 271 Mar 14 09:25 db.127
-rw-r--r-- 1 root root 237 Mar 14 09:25 db.255
-rw-r--r-- 1 root root 353 Mar 14 09:25 db.empty
-rw-r--r-- 1 root root 270 Mar 14 09:25 db.local
-rw-rw-r-- 1 root bind 552 Mar 26 15:31 directslave.inc
-rw-r--r-- 1 root bind 499 Mar 26 12:54 named.conf
-rw-r--r-- 1 root bind 498 Mar 14 09:25 named.conf.default-zones
-rw-r--r-- 1 root bind 165 Mar 14 09:25 named.conf.local
-rw-r--r-- 1 root bind 958 Mar 26 15:25 named.conf.options
-rw-r----- 1 bind bind 100 Mar 25 08:39 rndc.key
drwxrwxr-x 2 root bind 4096 Mar 26 12:55 secondary
-rw-r--r-- 1 root root 1317 Mar 14 09:25 zones.rfc1918

cat /etc/bind/named.conf
// This is the primary configuration file for the BIND DNS server named.
//
// Please read /usr/share/doc/bind9/README.Debian.gz for information on the
// structure of BIND configuration files in Debian, *BEFORE* you customize
// this configuration file.
//
// If you are just adding zones, please do that in /etc/bind/named.conf.local

include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";
include "/etc/bind/directslave.inc";

cat /etc/apparmor.d/local/usr.sbin.named
/etc/bind/secondary/** rw,

Do note that the DirectSlave server is in the US so the time might be way off.
And all the denied messages are from before you suggested to use /etc/bind folder for that.

grep 'named' /var/log/messages | tail
Mar 26 12:52:34 **DirectSlave server** kernel: [101678.529258] audit: type=1400 audit(1648317154.825:110): apparmor="DENIED" operation="open" profile="named" name="/etc/namedb/directslave.inc" pid=12951 comm="isc-net-0000" requested_mask="r" denied_mask="r" fsuid=107 ouid=107
Mar 26 12:53:29 **DirectSlave server** kernel: [101733.580324] audit: type=1400 audit(1648317209.877:111): apparmor="DENIED" operation="open" profile="named" name="/etc/namedb/directslave.inc" pid=13017 comm="isc-net-0000" requested_mask="r" denied_mask="r" fsuid=107 ouid=107
Mar 26 12:53:30 **DirectSlave server** kernel: [101733.792817] audit: type=1400 audit(1648317210.085:112): apparmor="DENIED" operation="open" profile="named" name="/etc/namedb/directslave.inc" pid=13028 comm="isc-net-0000" requested_mask="r" denied_mask="r" fsuid=107 ouid=107
Mar 26 12:53:30 **DirectSlave server** kernel: [101734.009311] audit: type=1400 audit(1648317210.305:113): apparmor="DENIED" operation="open" profile="named" name="/etc/namedb/directslave.inc" pid=13038 comm="isc-net-0000" requested_mask="r" denied_mask="r" fsuid=107 ouid=107
Mar 26 12:53:30 **DirectSlave server** kernel: [101734.261225] audit: type=1400 audit(1648317210.557:114): apparmor="DENIED" operation="open" profile="named" name="/etc/namedb/directslave.inc" pid=13048 comm="isc-net-0000" requested_mask="r" denied_mask="r" fsuid=107 ouid=107
Mar 26 12:53:30 **DirectSlave server** kernel: [101734.517082] audit: type=1400 audit(1648317210.813:115): apparmor="DENIED" operation="open" profile="named" name="/etc/namedb/directslave.inc" pid=13058 comm="isc-net-0000" requested_mask="r" denied_mask="r" fsuid=107 ouid=107
Mar 26 13:20:27 **DirectSlave server** kernel: [103351.187771] audit: type=1400 audit(1648318827.365:124): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="named" pid=13332 comm="apparmor_parser"
Mar 26 13:26:59 **DirectSlave server** kernel: [103742.991086] audit: type=1400 audit(1648319219.136:149): apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="named" pid=13565 comm="apparmor_parser"
Mar 26 13:27:18 **DirectSlave server** kernel: [103762.802779] audit: type=1400 audit(1648319238.951:158): apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="named" pid=13586 comm="apparmor_parser"
Mar 26 15:06:28 **DirectSlave server** kernel: [109712.428627] audit: type=1400 audit(1648325188.159:161): apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="named" pid=14606 comm="apparmor_parser"

I did also do a service bind9 status and noticed:

root@vmi543185:~# service bind9 status
● named.service - BIND Domain Name Server
Loaded: loaded (/lib/systemd/system/named.service; enabled; vendor preset: enabled)
Active: active (running) since Sat 2022-03-26 15:25:33 CDT; 2h 18min ago
Docs: man:named(8)
Main PID: 15037 (named)
Tasks: 14 (limit: 9510)
Memory: 46.9M
CPU: 2.114s
CGroup: /system.slice/named.service
└─15037 /usr/sbin/named -f -u bind

Mar 26 17:40:19 **DirectSlave server** named[15037]: zone **DirectAdmin domain**/IN: refresh: retry limit for master **DirectAdmin IP**#53 exceeded (source 0.0.0.0#0)
Mar 26 17:40:19 **DirectSlave server** named[15037]: zone **DirectAdmin domain**/IN: Transfer started.
Mar 26 17:40:19 **DirectSlave server** named[15037]: zone **DirectAdmin domain**/IN: refresh: retry limit for master **DirectAdmin IP**#53 exceeded (source 0.0.0.0#0)
Mar 26 17:40:19 **DirectSlave server** named[15037]: zone **DirectAdmin domain**/IN: Transfer started.
Mar 26 17:40:20 **DirectSlave server** named[15037]: transfer of '**DirectAdmin domain**/IN' from **DirectAdmin IP**#53: failed to connect: connection refused
Mar 26 17:40:20 **DirectSlave server** named[15037]: transfer of '**DirectAdmin domain**/IN' from **DirectAdmin IP**#53: Transfer status: connection refused
Mar 26 17:40:20 **DirectSlave server** named[15037]: transfer of '**DirectAdmin domain**/IN' from **DirectAdmin IP**#53: Transfer completed: 0 messages, 0 records, 0 bytes, 0.107 secs (0 bytes/sec) (serial 0)
Mar 26 17:40:20 **DirectSlave server** named[15037]: transfer of '**DirectAdmin domain**/IN' from **DirectAdmin IP**#53: failed to connect: connection refused
Mar 26 17:40:20 **DirectSlave server** named[15037]: transfer of '**DirectAdmin domain**/IN' from **DirectAdmin IP**#53: Transfer status: connection refused
Mar 26 17:40:20 **DirectSlave server** named[15037]: transfer of '**DirectAdmin domain**/IN' from **DirectAdmin IP**#53: Transfer completed: 0 messages, 0 records, 0 bytes, 0.107 secs (0 bytes/sec) (serial 0)

DirectAdmin named.conf.options:

options {
allow-transfer { none; };
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 { **DirectSlave server IP**; };
allow-transfer { **DirectSlave server IP**; };
notify explicit;
};

And I also did a reboot after making the changes in the named.conf.options on the DirectAdmin server.

Daniel_Dog · Mar 26, 2022

realcryptonight said:
Do note that the DirectSlave server is in the US so the time might be way off.
And all the denied messages are from before you suggested to use /etc/bind folder for that.

I did also do a service bind9 status and noticed:

DirectAdmin named.conf.options:

And I also did a reboot after making the changes in the named.conf.options on the DirectAdmin server.

Found the issue!
The named.conf.options on the directadmin server started with allow-transfer { none; } and I then later added: allow-transfer { 209.126.11.49; };
Removing the first allow-transfer { none; } fixed everything.

cjd · Mar 26, 2022

I was just reading that. Yes that would break things, not allowing the transfers. Glad it's working for you now.

Daniel_Dog · Mar 26, 2022

cjd said:
I was just reading that. Yes that would break things, not allowing the transfers. Glad it's working for you now.

Thank you for all your help. Without you I would never get it working.

Daniel_Dog · Mar 26, 2022

cjd said:
I was just reading that. Yes that would break things, not allowing the transfers. Glad it's working for you now.

Just one last question.

Are there any concerns for the conf files that we gave custom changes when bind9 gets updated by custombuilds/apt?

Richard G · Mar 26, 2022

realcryptonight said:
and I then later added: allow-transfer

That's odd. Directslave is working via the multiserver setup of Directadmin, which does not need that setting because domains are transferred via port 2222.

You wouldn't need this either:

Code:

also-notify { **DirectSlave server IP**; };
   allow-transfer { **DirectSlave server IP**; };

Seems to me you done the setup completely wrong. If you're working with "notify" and port 53, then you're using a bind slave server the normal way, that is not what Directslave is intended to do.

Did you check the manual at directslave.com first?

This software (DirectSlave) is designed for fast & easy slave DNS management, interacting with DirectAdmin powered servers using DirectAdmin multiserver API. Configuration of master DirectAdmin server is not necessary, software provides DirectAdmin multiserver API emulation via HTTP protocol.
You only need to enable Multi Server feature on master DirectAdmin server and set it up to work with DirectSlave.
+ listen to tcp 2222 port and accept DirectAdmin /CMD_API_DNS_ADMIN API commands (port can be changed in config file)

So what is all this fuzz with allowed transfers and things? That was just the reason Directslave was created, so you don't have to use that stuff.

Richard G · Mar 26, 2022

@cjd Your post #268 is incorrect. That is for normal DNS transfer setup, not for Directslave. Check the Directslave Readme please.
You might want to adjust that post to not get future readers on the wrong path.

Daniel_Dog · Mar 26, 2022

Richard G said:
That's odd. Directslave is working via the multiserver setup of Directadmin, which does not need that setting because domains are transferred via port 2222.

You wouldn't need this either:

Code:

also-notify { **DirectSlave server IP**; }; allow-transfer { **DirectSlave server IP**; };

Seems to me you done the setup completely wrong. If you're working with "notify" and port 53, then you're using a bind slave server the normal way, that is not what Directslave is intended to do.

Did you check the manual at directslave.com first?

So what is all this fuzz with allowed transfers and things? That was just the reason Directslave was created, so you don't have to use that stuff.

I get what you mean but for whatever reason without this it will not transfer the zones to the DirectSlave.

Daniel_Dog · Mar 26, 2022

Richard G said:
@cjd Your post #268 is incorrect. That is for normal DNS transfer setup, not for Directslave. Check the Directslave Readme please.
You might want to adjust that post to not get future readers on the wrong path.

I did read the README file but after follow all the steps it did not work completely.
I got the domain from DirectAdmin Multi-Server in the directslave.inc but no .db files where created in the secondary folder with the zone of the domain itself.

EDIT:

And if I look at other install script for DirectSlave that where made for CentOS then they do the same.
But I am not familiar with bind9 configs. So I ignored it with it not working as a result.

Richard G · Mar 26, 2022

I understand what you mean, but there should be a reason for that. I know that in the past if rndc could not run, this would cause an issue. I don't know if that is still the case.

Maybe @roman_m knows it, or since you're using apparmor, it might be caused by that, because normally there are no issues.

As long as people know that now you're not using in fact a normal DNS slave setup, so not like Directslave should be configured.

Which distro and version are you using Debian someting? I'm be bit too lazy to read back.

I might see if I can try to setup the same in some test environment, see if I have the same issue without using apparmor.

Daniel_Dog · Mar 26, 2022

Richard G said:
I understand what you mean, but there should be a reason for that. I know that in the past if rndc could not run, this would cause an issue. I don't know if that is still the case.

Maybe @roman_m knows it, or since you're using apparmor, it might be caused by that, because normally there are no issues.

As long as people know that now you're not using in fact a normal DNS slave setup, so not like Directslave should be configured.

Which distro and version are you using Debian someting? I'm be bit too lazy to read back. I might see if I can try to setup the same in some test environment, see if I have the same issue without using apparmor.

I use:

lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 11 (bullseye)
Release: 11
Codename: bullseye

It is an clean install with nothing on it and I only install certbot and bind9 with:
apt -y install certbot bind9

I am still working on the install script but I should be able to release it in an couple of hours.

cjd · Mar 26, 2022

Richard G said:
@cjd Your post #268 is incorrect. That is for normal DNS transfer setup, not for Directslave. Check the Directslave Readme please.
You might want to adjust that post to not get future readers on the wrong path.

DirectSlave is creating a standard bind slave zone file, it's transferring the domain names themselves via the link to DirectAdmin to be able to create the config file, and doesn't seem to transfer any of the zones themselves via that link. It doesn't work exactly like how DirectAdmin does it between servers, this at least from my experience. If someone has it working that way I would like to know, then it would run more as an independent master. Now the allow-notify/transfer is not really required on the directslave, it's just habit from building DNS nodes that are both masters and slaves at the same time for different domains/server, and I don't like to put the zone config file in the slave storage directory. They actually used to have the information in the README up to version 3.3, this is what it said.

TROUBLESHOOTING
===============

Q: /etc/named/secondary/named.conf is populated with zone entries,
but zone files is not created.
A: This is a primary DNS issue. Check primary server DNS logs.
If you use ISC Bind DNS software, then add following line
to your main DNS server config then restart DNS service.

allow-transfer { directslave.server.ip.address; };

Richard G · Mar 26, 2022

cjd said:
DirectSlave is creating a standard bind slave zone file, it's transferring the domain names themselves via the link to DirectAdmin to be able to create the config file, and doesn't seem to transfer any of the zones themselves via that link. It doesn't work exactly like how DirectAdmin does it between servers, this at least from my experience.

Directslave should in fact work exactly the same as if Directslave was not Directslave but another Directadmin server. There is no difference in how it works for the transfers. At least it was not in version 2 and as far as I know this had not changed.

I had it running this way on the older version, and never had to use any allow transfer or notify settings which are used by normal bind slaves.
However, when I did it, this was with the old version of DS all done on a Centos 6 DA server with a simple Centos 6 VPS.

Indeed I missed the section what it says about the Q and A to add the allow-transfer.
I now also see on some Github page that this also makes use of the allow-notify and allow-transfer and some of these settings on both servers.

So now I'm wondering if that much was changed in version 3.

However, I don't see any benefit in using Directslave if you have to setup almost a complete normal bind slave anyway to get it to work.
So there might be some bug present.

Unfortunately our good friend Roman is from the Ukraine, even Kiev, so he has something else on his mind and I wish him and all the Ukraine people all strength and good wishes.

realcryptonight said:
It is an clean install with nothing on it and I only install certbot and bind9 with:

Thank you. I understand the issue. When your directory's are not populated the correct way, you have to get it to work.

It's a bit late now here, but this really got me curious.
Just to be sure, it's not my intention to offend you both, but since I used this on version 2 which worked very easy with little effort, I like to try and see if I can find why it does not work like it should work. Because I surely believe you as you say there are issues.

I normally work with Centos and now Alma, but I don't mind giving it a try on Debian 11. Maybe try without ssl first.
Can take a couple of days, I'll keep you informed here.

DirectSlave/GO 3 - public beta

Verified User

Verified User

Verified User

Verified User

Verified User

Verified User

Attachments

Verified User

Verified User

Verified User

Verified User

Verified User

Verified User

Verified User

Verified User

Verified User

Verified User

Verified User

Verified User

Verified User

Verified User