When I give the command v-add-remote-dns-host, it only transfers the dns domain but without records:
As a result, I cannot register the glues in my registrar, due to DNS2 failure.
Mak sure to include the changes in bind config…
Yes, I did exactly as you asked, more precisely this part:
Master → Slave DNS cluster with the Hestia API
Preparing your Slave server(s):
- Whitelist your master server IP in Configure Server → Security → Allowed IP addresses for API
- Enable API access for admins (or all users).
- Create an API key under the admin user with at least the sync-dns-cluster permission.
- Create a new DNS sync user as follows:
- Has email address (something generic)
- Has the role
dns-cluster - You may want to set ‘Do not allow user to log in to Control Panel’ if they are not a regular user
- Edit
/usr/local/hestia/conf/hestia.conf, changeDNS_CLUSTER_SYSTEM='hestia'toDNS_CLUSTER_SYSTEM='hestia-zone'. - Edit
/etc/bind/named.conf.options, do the following changes, then restart bind9 withsystemctl restart bind9:
bash
# Change this line
allow-recursion { 127.0.0.1; ::1; };
# To this
allow-recursion { 127.0.0.1; ::1; your.master.ip.address; };
# Add this line
allow-notify{ your.master.ip.address; };
Preparing your Master server:
- On the Master server, open
/etc/bind/named.conf.options, do the following changes, then restart bind9 withsystemctl restart bind9.
bash
# Change this line
allow-transfer { "none"; };
# To this
allow-transfer { your.slave.ip.address; };
# Or this, if adding multiple slaves
allow-transfer { first.slave.ip.address; second.slave.ip.address; };
# Add this line, if adding multiple slaves
also-notify { second.slave.ip.address; };
- Run the following command to enable each Slave DNS server, and wait a short while for it to complete zone transfers:
bash
v-add-remote-dns-host <your slave host name> <port number> '<accesskey>:<secretkey>' '' 'api' '<your chosen slave user name>'
If you still want to use admin and password authentication (not recommended):
bash
v-add-remote-dns-host slave.yourhost.com 8083 'admin' 'strongpassword' 'api' 'user-name'
- Check it worked by listing the DNS zones on the Slave for the dns-user with the CLI command
v-list-dns-domains dns-useror by connecting to the web iterface as dns-user and reviewing the DNS zones.
And as you can see, this is the result:
Here are the config files:
I did some tests and discovered that Records are not transferred when the DNS_CLUSTER_SYSTEM option is set to ‘hestia-zone’ in the MASTER.
If you change the MASTER to ‘hestia’ it transfers correctly.
But this has the effect of hiding the option to enable DNSSEC on the MASTER.
The same happens with SLAVE if you change it to ‘hestia’, the Enable DNSSEC option disappears.
From what I understand by reading the documentation, the DNS_CLUSTER_SYSTEM option must only be changed in the SLAVE, it doesn’t say anything about the MASTER.
But with this I can’t enable DNSSEC.
I repeated the test 3 times to see if it was a typing error, each time reinstalling completely, including Debian 12 with a minimal installation.
For hestia-zone is required other wise DNSSEC doesn’t work…
But I have never tried it on local networks It will not surprise me if it doesn’t work…
Run:
rndc notify {domain}
And check /var/log/syslog
This is the output from /var/log/syslog:
2024-02-15T03:42:26.115798-03:00 isp1 systemd[1]: Reloading nginx.service - nginx - high performance web server…
2024-02-15T03:42:26.119715-03:00 isp1 systemd[1]: Reloaded nginx.service - nginx - high performance web server.
2024-02-15T03:42:30.203973-03:00 isp1 systemd[1]: Reloading apache2.service - The Apache HTTP Server…
2024-02-15T03:42:30.245597-03:00 isp1 apachectl[102096]: AH00558: apache2: Could not reliably determine the server’s fully qualified domain name, using isp1.reloaded.com.br. Set the ‘ServerName’ directive globally to suppress this message
2024-02-15T03:42:30.257931-03:00 isp1 systemd[1]: Reloaded apache2.service - The Apache HTTP Server.
2024-02-15T03:42:30.411832-03:00 isp1 systemd[1]: Reloading nginx.service - nginx - high performance web server…
2024-02-15T03:42:30.414737-03:00 isp1 systemd[1]: Reloaded nginx.service - nginx - high performance web server.
2024-02-15T03:44:01.575958-03:00 isp1 CRON[102953]: (admin) CMD (sudo /usr/local/hestia/bin/v-update-sys-queue restart)
2024-02-15T03:45:01.622816-03:00 isp1 CRON[103001]: (admin) CMD (sudo /usr/local/hestia/bin/v-update-sys-queue backup)
2024-02-15T03:45:01.623413-03:00 isp1 CRON[103002]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
2024-02-15T03:45:01.623597-03:00 isp1 CRON[103003]: (admin) CMD (sudo /usr/local/hestia/bin/v-update-sys-rrd)
2024-02-15T03:45:01.624258-03:00 isp1 CRON[103005]: (admin) CMD (sudo /usr/local/hestia/bin/v-update-sys-queue dns-cluster)
2024-02-15T03:46:01.303526-03:00 isp1 CRON[103414]: (admin) CMD (sudo /usr/local/hestia/bin/v-update-sys-queue restart)
2024-02-15T03:48:01.351327-03:00 isp1 CRON[103484]: (admin) CMD (sudo /usr/local/hestia/bin/v-update-sys-queue restart)
2024-02-15T03:50:01.398329-03:00 isp1 CRON[103556]: (admin) CMD (sudo /usr/local/hestia/bin/v-update-sys-queue dns-cluster)
2024-02-15T03:50:01.398514-03:00 isp1 CRON[103557]: (admin) CMD (sudo /usr/local/hestia/bin/v-update-sys-queue restart)
2024-02-15T03:50:01.399122-03:00 isp1 CRON[103558]: (admin) CMD (sudo /usr/local/hestia/bin/v-update-sys-queue backup)
2024-02-15T03:50:01.399616-03:00 isp1 CRON[103559]: (admin) CMD (sudo /usr/local/hestia/bin/v-update-sys-rrd)
2024-02-15T03:52:01.078976-03:00 isp1 CRON[104012]: (admin) CMD (sudo /usr/local/hestia/bin/v-update-sys-queue restart)
2024-02-15T03:54:01.127339-03:00 isp1 CRON[104079]: (admin) CMD (sudo /usr/local/hestia/bin/v-update-sys-queue restart)
2024-02-15T03:55:01.174176-03:00 isp1 CRON[104127]: (admin) CMD (sudo /usr/local/hestia/bin/v-update-sys-queue dns-cluster)
2024-02-15T03:55:01.174363-03:00 isp1 CRON[104128]: (admin) CMD (sudo /usr/local/hestia/bin/v-update-sys-rrd)
2024-02-15T03:55:01.174539-03:00 isp1 CRON[104129]: (admin) CMD (sudo /usr/local/hestia/bin/v-update-sys-queue backup)
2024-02-15T03:55:01.174710-03:00 isp1 CRON[104130]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
2024-02-15T03:56:01.860194-03:00 isp1 CRON[104542]: (admin) CMD (sudo /usr/local/hestia/bin/v-update-sys-queue restart)
2024-02-15T03:58:01.907122-03:00 isp1 CRON[104612]: (admin) CMD (sudo /usr/local/hestia/bin/v-update-sys-queue restart)
2024-02-15T04:00:01.955609-03:00 isp1 CRON[104684]: (admin) CMD (sudo /usr/local/hestia/bin/v-update-sys-rrd)
2024-02-15T04:00:01.955812-03:00 isp1 CRON[104685]: (admin) CMD (sudo /usr/local/hestia/bin/v-update-sys-queue backup)
2024-02-15T04:00:01.955991-03:00 isp1 CRON[104686]: (admin) CMD (sudo /usr/local/hestia/bin/v-update-sys-queue dns-cluster)
2024-02-15T04:00:01.956164-03:00 isp1 CRON[104687]: (admin) CMD (sudo /usr/local/hestia/bin/v-update-sys-queue restart)
2024-02-15T04:02:01.640847-03:00 isp1 CRON[105140]: (admin) CMD (sudo /usr/local/hestia/bin/v-update-sys-queue restart)
2024-02-15T04:04:01.695507-03:00 isp1 CRON[105205]: (admin) CMD (sudo /usr/local/hestia/bin/v-update-sys-queue restart)
2024-02-15T04:05:01.742629-03:00 isp1 CRON[105255]: (admin) CMD (sudo /usr/local/hestia/bin/v-update-sys-queue dns-cluster)
2024-02-15T04:05:01.742813-03:00 isp1 CRON[105256]: (admin) CMD (sudo /usr/local/hestia/bin/v-update-sys-rrd)
2024-02-15T04:05:01.742988-03:00 isp1 CRON[105257]: (admin) CMD (sudo /usr/local/hestia/bin/v-update-sys-queue backup)
2024-02-15T04:05:01.743355-03:00 isp1 CRON[105258]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
2024-02-15T04:05:51.236535-03:00 isp1 systemd[1]: Created slice user-1000.slice - User Slice of UID 1000.
2024-02-15T04:05:51.237348-03:00 isp1 systemd[1]: Starting [email protected] - User Runtime Directory /run/user/1000…
2024-02-15T04:05:51.246214-03:00 isp1 systemd[1]: Finished [email protected] - User Runtime Directory /run/user/1000.
2024-02-15T04:05:51.247580-03:00 isp1 systemd[1]: Starting [email protected] - User Manager for UID 1000…
2024-02-15T04:05:51.311188-03:00 isp1 systemd[105659]: Queued start job for default target default.target.
2024-02-15T04:05:51.312505-03:00 isp1 systemd[105659]: Created slice app.slice - User Application Slice.
2024-02-15T04:05:51.312616-03:00 isp1 systemd[105659]: Reached target paths.target - Paths.
2024-02-15T04:05:51.312708-03:00 isp1 systemd[105659]: Reached target timers.target - Timers.
2024-02-15T04:05:51.312826-03:00 isp1 systemd[105659]: Starting dbus.socket - D-Bus User Message Bus Socket…
2024-02-15T04:05:51.313039-03:00 isp1 systemd[105659]: Listening on dirmngr.socket - GnuPG network certificate management daemon.
2024-02-15T04:05:51.313130-03:00 isp1 systemd[105659]: Listening on gpg-agent-browser.socket - GnuPG cryptographic agent and passphrase cache (access for web browsers).
2024-02-15T04:05:51.313208-03:00 isp1 systemd[105659]: Listening on gpg-agent-extra.socket - GnuPG cryptographic agent and passphrase cache (restricted).
2024-02-15T04:05:51.313271-03:00 isp1 systemd[105659]: Listening on gpg-agent-ssh.socket - GnuPG cryptographic agent (ssh-agent emulation).
2024-02-15T04:05:51.313323-03:00 isp1 systemd[105659]: Listening on gpg-agent.socket - GnuPG cryptographic agent and passphrase cache.
2024-02-15T04:05:51.318565-03:00 isp1 systemd[105659]: Listening on dbus.socket - D-Bus User Message Bus Socket.
2024-02-15T04:05:51.318654-03:00 isp1 systemd[105659]: Reached target sockets.target - Sockets.
2024-02-15T04:05:51.318711-03:00 isp1 systemd[105659]: Reached target basic.target - Basic System.
2024-02-15T04:05:51.318761-03:00 isp1 systemd[105659]: Reached target default.target - Main User Target.
2024-02-15T04:05:51.318818-03:00 isp1 systemd[105659]: Startup finished in 62ms.
2024-02-15T04:05:51.318874-03:00 isp1 systemd[1]: Started [email protected] - User Manager for UID 1000.
2024-02-15T04:05:51.319776-03:00 isp1 systemd[1]: Started session-658.scope - Session 658 of User finallf.
2024-02-15T04:06:01.414597-03:00 isp1 CRON[105701]: (admin) CMD (sudo /usr/local/hestia/bin/v-update-sys-queue restart)
2024-02-15T04:06:32.473902-03:00 isp1 named[83390]: received control channel command ‘notify reloaded.com.br’
2024-02-15T04:06:32.474095-03:00 isp1 named[83390]: zone reloaded.com.br/IN: sending notifies (serial 2024021508)
Regarding working on a local network, I have each machine in distant physical locations, but I am using wireguard to communicate between them.
This way I have an additional layer of protection for communication between the two servers.
And on the slave?
Please note because the records are synced over rdnc the number of records will not match …
This is the slave /var/log/syslog:
2024-02-15T09:08:01.755541-03:00 isp2 CRON[109974]: (admin) CMD (sudo /usr/local/hestia/bin/v-update-sys-queue restart)
2024-02-15T09:09:00.350213-03:00 isp2 systemd[1]: Starting phpsessionclean.service - Clean php session files…
2024-02-15T09:09:01.324481-03:00 isp2 CRON[110048]: (root) CMD ( [ -x /usr/lib/php/sessionclean ] && if [ ! -d /run/systemd/system ]; then /usr/lib/php/sessionclean; fi)
2024-02-15T09:09:01.369490-03:00 isp2 systemd[1]: phpsessionclean.service: Deactivated successfully.
2024-02-15T09:09:01.369948-03:00 isp2 systemd[1]: Finished phpsessionclean.service - Clean php session files.
2024-02-15T09:09:01.370317-03:00 isp2 systemd[1]: phpsessionclean.service: Consumed 1.214s CPU time.
2024-02-15T09:10:01.408490-03:00 isp2 CRON[110067]: (admin) CMD (sudo /usr/local/hestia/bin/v-update-sys-rrd)
2024-02-15T09:10:01.437766-03:00 isp2 CRON[110068]: (admin) CMD (sudo /usr/local/hestia/bin/v-update-sys-queue backup)
2024-02-15T09:10:01.455862-03:00 isp2 CRON[110070]: (admin) CMD (sudo /usr/local/hestia/bin/v-update-sys-queue restart)
2024-02-15T09:12:01.528468-03:00 isp2 CRON[110332]: (admin) CMD (sudo /usr/local/hestia/bin/v-update-sys-queue restart)
2024-02-15T09:12:49.042846-03:00 isp2 named[84180]: managed-keys-zone: Unable to fetch DNSKEY set ‘.’: timed out
2024-02-15T09:12:49.044144-03:00 isp2 named[84180]: resolver priming query complete: timed out
2024-02-15T09:14:01.112496-03:00 isp2 CRON[110376]: (admin) CMD (sudo /usr/local/hestia/bin/v-update-sys-queue restart)
2024-02-15T09:15:01.701674-03:00 isp2 CRON[110413]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
2024-02-15T09:15:01.736476-03:00 isp2 CRON[110415]: (admin) CMD (sudo /usr/local/hestia/bin/v-update-sys-queue backup)
2024-02-15T09:15:01.739508-03:00 isp2 CRON[110414]: (admin) CMD (sudo /usr/local/hestia/bin/v-update-sys-rrd)
2024-02-15T09:16:01.793840-03:00 isp2 CRON[110780]: (admin) CMD (sudo /usr/local/hestia/bin/v-update-sys-queue restart)
2024-02-15T09:17:01.334028-03:00 isp2 CRON[110814]: (root) CMD (cd / && run-parts --report /etc/cron.hourly)
2024-02-15T09:18:01.390034-03:00 isp2 CRON[110827]: (admin) CMD (sudo /usr/local/hestia/bin/v-update-sys-queue restart)
2024-02-15T09:19:44.770101-03:00 isp2 systemd[1]: Created slice user-1000.slice - User Slice of UID 1000.
2024-02-15T09:19:44.803289-03:00 isp2 systemd[1]: Starting [email protected] - User Runtime Directory /run/user/1000…
2024-02-15T09:19:44.841132-03:00 isp2 systemd[1]: Finished [email protected] - User Runtime Directory /run/user/1000.
2024-02-15T09:19:44.866591-03:00 isp2 systemd[1]: Starting [email protected] - User Manager for UID 1000…
2024-02-15T09:19:45.393070-03:00 isp2 systemd[110874]: Queued start job for default target default.target.
2024-02-15T09:19:45.399415-03:00 isp2 systemd[110874]: Created slice app.slice - User Application Slice.
2024-02-15T09:19:45.399992-03:00 isp2 systemd[110874]: Reached target paths.target - Paths.
2024-02-15T09:19:45.400415-03:00 isp2 systemd[110874]: Reached target timers.target - Timers.
2024-02-15T09:19:45.409960-03:00 isp2 systemd[110874]: Starting dbus.socket - D-Bus User Message Bus Socket…
2024-02-15T09:19:45.410964-03:00 isp2 systemd[110874]: Listening on dirmngr.socket - GnuPG network certificate management daemon.
2024-02-15T09:19:45.411520-03:00 isp2 systemd[110874]: Listening on gpg-agent-browser.socket - GnuPG cryptographic agent and passphrase cache (access for web browsers).
2024-02-15T09:19:45.412102-03:00 isp2 systemd[110874]: Listening on gpg-agent-extra.socket - GnuPG cryptographic agent and passphrase cache (restricted).
2024-02-15T09:19:45.412514-03:00 isp2 systemd[110874]: Listening on gpg-agent-ssh.socket - GnuPG cryptographic agent (ssh-agent emulation).
2024-02-15T09:19:45.413089-03:00 isp2 systemd[110874]: Listening on gpg-agent.socket - GnuPG cryptographic agent and passphrase cache.
2024-02-15T09:19:45.448767-03:00 isp2 systemd[110874]: Listening on dbus.socket - D-Bus User Message Bus Socket.
2024-02-15T09:19:45.449382-03:00 isp2 systemd[110874]: Reached target sockets.target - Sockets.
2024-02-15T09:19:45.449769-03:00 isp2 systemd[110874]: Reached target basic.target - Basic System.
2024-02-15T09:19:45.451462-03:00 isp2 systemd[1]: Started [email protected] - User Manager for UID 1000.
2024-02-15T09:19:45.452037-03:00 isp2 systemd[110874]: Reached target default.target - Main User Target.
2024-02-15T09:19:45.453980-03:00 isp2 systemd[1]: Started session-895.scope - Session 895 of User finallf.
2024-02-15T09:19:45.454387-03:00 isp2 systemd[110874]: Startup finished in 525ms.
2024-02-15T09:20:01.978040-03:00 isp2 CRON[110906]: (admin) CMD (sudo /usr/local/hestia/bin/v-update-sys-rrd)
2024-02-15T09:20:02.019622-03:00 isp2 CRON[110908]: (admin) CMD (sudo /usr/local/hestia/bin/v-update-sys-queue backup)
2024-02-15T09:20:02.029266-03:00 isp2 CRON[110909]: (admin) CMD (sudo /usr/local/hestia/bin/v-update-sys-queue restart)
2024-02-15T09:20:14.020621-03:00 isp2 named[84180]: received control channel command ‘notify reloaded.com.br’
2024-02-15T09:20:14.026657-03:00 isp2 named[84180]: zone reloaded.com.br/IN: sending notifies (serial 2024021508)
Yes, but it cannot be 0.
The Command was executed with the DNS_CLUSTER_SYSTEM option as hestia on the master, and hestia-zone on the slave.
I’m going to change the master to hestia-zone and redo the same test and post it here.
Records remain 0 it is a know issue and it can’t be really fixed … Also it shouldn’t matter as they are synced over rndc instead
If you run
nslookup domain.com slave.domain.com
It should still return the correct ip
Yes, it returns the correct IP, but without the records my ns2 is inoperative and giving a connectivity error:
test run at: https://zonemaster.se:
And as a result, I can’t register the glue with my registrar, as it requires 2 functioning DNS servers.
–
So from what you’re telling me, this is already a known problem, so from what I understand, either I have the DNS synchronized correctly, but without DNSSEC or do I activate DNSSEC and break my NS2?
Explain to me, what does the DNS_CLUSTER_SYSTEM option do, when I change from hestia to hestia-zone, and why can’t I activate DNSSEC with the option in hestia?
Still, would there be any way to activate DNSSEC via the API or even the CLI?
So the conclusion I reached is that DNSSEC still cannot be used with the cluster option turned on, even if it is Master > Slave.
Because when we activate hestia-zone on the Master it does not synchronize the DNS correctly.
Is there a possibility that synchronization works the same when the master is in hestia even though it is in hestia-zone?
Is it a bug, or lack of implementation?
I ask this so I can place the correct order 
DNSSEC requires to use rndc notify to get working without it is not possible…
When I check with: intodns:
DNSEC works with the fact that we sync the DNS data from 1 server to the 2nd server via zone transfer including the keys that require to function it.
With DNS_CLUSTER_SYSTEM in “hestia” mode it acts as 2 different dns severs instead of master slave setup…
So when DNSSEC is turned on, the synchronization method changes?
Ok, but the result has to be the same in the end, regardless of how the synchronization is done, be it just a simple copy, or using keys.
The second server (ns2), whether it is a separate server or a mirror, the data and records must be identical and respond in the same way when we create it manually.
And that’s what’s not happening, when we turn on the “hestia-zone” mode, something is wrong, because the second server stops responding as a dns server.
Can you share /etc/bind/named.conf
It royally doesn’t accept the rndc notify because the ip is not matching…
Master:
// 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”;
zone “reloaded.com.br” {type master; file “/home/admin/conf/dns/reloaded.com.br.db”;};
Slave:
// 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”;
zone “reloaded.com.br” in {type slave; masters { 189.18.149.215; }; file “/home/dns-cluster/conf/dns/reloaded.com.br.db”;};
Looking at the bind file, I think I understand.
As I am synchronizing over a “local network”, that is, I am using Wireguard to create a VPN, and in the bind, the IP is my external IP, it gives an error when DNSSEC is active, would that be it?
Use the public ip to sync over and it should work fine… Maybe we need to look into syncing over local network in the future …