I confirmed it here, and it is exactly as we said.
I changed all the IPs and only kept the configuration with public IPs, it worked like a charm, I even activated DNSSEC on my Registrar.
Now, it would really be a great addition to include support so that we can communicate between servers on a local network.
With this we can use any VPN between the servers, thus having an additional layer of security between the communication between the servers.
I use this a lot with wireguard, I have several servers (vps) spread across the internet, communicating with each other, as if they were connected to the same switch
I believe it shouldn’t be just that, but from what I saw, if we change the line in the Slave’s /etc/bind/named.conf file: zone “host.tld” in {type slave; masters { Master_Public_IP; }; file “/home/dns-cluster/conf/dns/reloaded.com.br.db”;};
For: zone “host.tld” in {type slave; masters { Master_Local_IP; }; file “/home/dns-cluster/conf/dns/reloaded.com.br.db”;};
I think it should work.
You need me to open a request to add this feature, how can I proceed?
But it doesn’t need to be detected, we can use an additional field, in the same way we do with ips that can use the API.
A field, “Master’s local IP” that is filled in manually.
Remembering that network transfer works over the local network, and works normally.
It only stops working when we enable the “hestia-zone” option to use DNSSEC.
I tested it here and if the master has the option set to “hestia”, it works over the local network.
I just discovered this thread by filtering the bugs on github for “DNS CLUSTER”.
I have a similar setup (only using nebula mesh instead of wireguard) and it works fine.
refresh IP adresses at master and slave in Hestia UI so that VPN/local IP is available
whitelist the master VPN/local IP for API use on the slave
edit all the named.conf.options with the VPN/local IPs
add the remote slave wit the VPN/local IP address (not with its hostname), e.g.: v-add-remote-dns-host 192.168.1.1 8083 'slaveapiid:slaveapisecret' '' 'api' 'dnsapi'
That is it. Works flawless. No extra manual field required.
If you’re using systemd you could add a hestia.service.d and bind.service.d directory to /etc/systemd/system with a conf file containing
(or something like that, I am not working with wireguard) just to ensure that the VPN IP is up before hestia and bind start.
I have a question belonging more or less to this thread:
Do I have to change DNS_CLUSTER_SYSTEM='hestia' to DNS_CLUSTER_SYSTEM='hestia-zone'on the slave only or on both master and slave? The documentation does not mention a change on the master but in the screenshots above also the masters environment has been changed.
I have another issue concerning DNS Cluster filed as a bug on github.
Have a great day,
Magnus.
P.S. Nebula Mesh is significantly faster than wireguard
