I think we're talking micro-optimization here but... > it's a bit different: Your approach requires distributing > all the zones (not just the bind config) across all servers, > while others just distribute the config. And how is this is a problem?rsync only squirts the parts of the files that have changed, which for us is almost always a few lines in:
named.inc db.example.com...but if it didn't, we're not talking a few hundred K even for hundreds of zones.
> Also, the fact you don't increment serial number makes > your design much harder to detect and fix errors, while > DNS zone transfer mechanism takes care about that automatically.We're not using the bind replication mechanism, so what does incrementing the serial number give us that the timestamp on the file?
I'd be curious as to specific examples of problems detected by the bind replication mechanism.
> You're wrong, the 3) is here done automatically, those scripts > do not care about this. You are trying to make assumption those > scripts care about more than yours, which is not true.Perhaps I've miss-read the docs, It seems to me that the bind zone replication mechanism ***REQUIRES*** you (or your control panel) to update the serial number in the "master" zone file. If you don't increment the serial number, you don't get replication. The replication is triggered by a change in serial number.
Something or somebody in your environment is incrementing these serial numbers or your setup wouldn't work.
We're (sigh) not using a control panel. Avoiding the step of parsing out and incrementing the serial# in the SOA record in our zone files is a mild plus for us.
As a new data point I will concede that **IF** there is not a new zone requiring a transfer of named.inc, bind replicating the zone changes allows the slave server to take the time to only reload the changed zone.
With a few thousand zones or a lot of traffic, I guess avoiding reloading the entire server could be a plus.
######### Matus UHLAR - fantomas wrote:
On 12.10.07 14:50, Dan MacNeil wrote:I think the difference between the two approaches is that we: 0) generate named.inc & zone files 1) scp named.conf & zone files 2) rndc reload the satellite servers and many other people have a script: 0) generate named.inc & zone files 1) scp/rsync named.conf 2) rndc reload the satellite servers 3) use the bind replication mechanismYou're wrong, the 3) is here done automatically, those scripts do not care about this. You are trying to make assumption those scripts care about more than yours, which is not true.I claim our approach is slightly simpler as we don't have to increment the serial# (perhaps done by SysCP) in the zone files and we have one less step. :->it's a bit different: Your approach requires distributing all the zones (not just the bind config) across all servers, while others just distribute theconfig.Also, the fact you don't increment serisl number makes your design much harder to detect and fix errors, while DNS zone transfer mechanism takes care about that automatically.