On 7/26/19 6:52 AM, Giles Coochey wrote:
>
> On 26/07/2019 14:45, Leroy Tennison wrote:
>> This brings up one of the caveats for (at least ISC) DNS, if the
>> master goes down the slaves will take over for a time but eventually
>> will stop serving for the domains of the master if it remains down
>> too long. If my (sometimes faulty) memory serves me well it is in
>> the three day range (but configurable) which is ample time unless the
>> problem occurs early in a holiday weekend and and the
>> notification/escalation process isn't what it should be (Murphey's
>> Law)...
>
> The value you refer to is the SOA record _expire_ value for a zone, I
> believe is should be set to between 14 and 28 days.
>
> https://en.wikipedia.org/wiki/SOA_record
>
>
> _______________________________________________
> CentOS mailing list
> CentOS@xxxxxxxxxx
> https://lists.centos.org/mailman/listinfo/centos
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
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
