Most probably s1 will produce errors when DNS is trying to sync to s2. The good scenario would be the DNS in s1 to sync all domains, except that client.com one. The bad scenario would be the DNS in s1 to fail to update any domain.
Isn’t it possible to remove the master zone of client.com on s1? But then you won’t have any slave DNS for client.com domain, unless you make s1 DNS slave to s2.
What I did was to suspend client.com on s1 and have the DNS point to s2 with two different ns names.
The solution would be to make s2 slave of s1 and move all services to s2. That’s how hestia has been designed to operate.
I am going to make the system fail in a different server and I will let you know what happens. Maybe it is safe to just delete the domain. It could be helpful in cases where you want to have DNS + Email in one machine and Web in a different one
For slave DNS I’m using this approach: I have two separate small VPS, that are only acting as Slave DNS and nothing else. All other Hestia Servers (actual web/mail servers) point to those two Slave DNS servers. The SOA record is on the server that is hosting the site or email. When I need to set authoritative Name Servers on the registrar I set:
Web/Email Server name/IP
Slave DNS1 name/IP
Slave NDS2 name/IP
I tried setting only SlaveDNS1 and SlaveDNS2 to the registrar (so I wouldn’t need to make changes to the registrars when moving domains between different hosting servers), but that wasn’t the perfect solution, because the SOA record was on the Web/Email server and that lead to complains from DNS checkers like https://intodns.com/
The approach of having SlaveDNS act as primary (and only NS servers) and the web/mail server be in Slave DNS mode, would not work out at all in the case of wildcard LE Certificate and automatic creation of records like DKIM, etc. So I guess the primary NS needs to be on the hosting server, to avoid future trouble.