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
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 at centos.org > https://lists.centos.org/mailman/listinfo/centosIf 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
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. > > NatarajPowerDNS 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.