[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: two bind9 masters



> 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.

On 16.10.07 10:50, Dan MacNeil wrote:
> And how is this is a problem?

Basically it's different.

> > 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?

It will give you (or admins on other side of the net) a possibility to
detect that one of your hosts has older zone (comparing SOAs). Now, all
they will return the same SOA and if one of them returns different RRs,
nobody except you will be able to find out where the problem lies.

> > 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.

Read your original mail again. You mentioned one step more to do (reload
zones using *XFR) when using DNS transfers comparing to your way of doins
things. I am only telling you that it's not true, because it's something
that will be done automatically, so your scripts have nothing to do with
that.

You made an assumption that scripts will be more complicated because of DNS
transfers. That is not true.

> 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.

With bind replication, no rsync has to be done when config is not needed,
servers will only transfer changed zones and only reload those. This is much
more efficient than calling rsync every time something has changed.

And when you rsync zones, how do you tell which zones to reload? Either you
call 'rndc reload' or HUP the server, which will cause named to reload all
zones (yes, it will detect those unchanged), or you call "rndc reload" for
each changed zone. Both are not needed when using DNS zone transfers.

-- 
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Linux - It's now safe to turn on your computer.
Linux - Teraz mozete pocitac bez obav zapnut.



Reply to: