On 26/07/2019 17:35, Nataraj wrote:
If you administer the secondary slave servers, there is no reason not to
use a very large number, 30 days or more for the SOA expiration. Only
reason to use a lower number would be if you don't have control over the
slave servers and don't want to have old zone files that you can't update.
Another alternative, which many people did for years in the early days
when zone transfers were unreliable, is to use a script which replicates
the entire DNS configuration to the secondaries and then run all the
servers as primary masters. If the script is written cleanly, you can
then edit the zone on any server and rsync it to the other servers.
Main thing is to prevent multiple people applying updates simultaneously.
Nataraj
PowerDNS supports MySQL backends for the zone files, so one way that
they can work is in Native mode, as an alternative to Master / Slave, in
which the replication and information resilience is handled by the
backend (e.g. a MySQL cluster), and the servers just read the zone from
the database, with no need to perform zone transfers at all. The expire
timer in the SOA record then becomes pretty defunct, although if you
export your zones to non-PowerDNS servers, e.g. bind, then they take effect.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
