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.

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related lists.debian.org Links debian-announce debian-apache debian-arm-changes debian-beowulf debian-boot debian-cd debian-cd-vendors debian-changes debian-changes-digest debian-isp debian-kde debian-laptop debian-mirrors-announce debian-news debian-security debian-security-announce debian-testing debian-user debian-user-digest Request more information about Pantek

> 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(at)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.


-- 
To UNSUBSCRIBE, email to debian-isp-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org