----- Original Message ----- From: "Johan Ihrén" <johani@autonomica.se>
Hi Jørgen,
On Oct 28, 2004, at 04:47, Jørgen Hovland wrote:
and different replies depending on the country origin of the source ip of the querying nameserver/client.
Oops.
What's the justification for that? And what about maintaining DNS coherency? Any ideas on how to make this work with DNSSEC (I realize you're not doing DNSSEC today, but this would seem to be fundamentally incompatible with any DNSSEC use whatsoever).
Hi Johan Load balancy. A bit similar to what Akamai is doing. Regarding dnsssec we aren't quite there yet and don't have a solution to it.
What happens to updates (to the master) that occur *during* the reload? My guess is that they get added to "the tail" of the reload to ensure that no change is left out during the reload. But in that case it seems to me that you already have the zone sorted in "transaction order" and the only thing needed to steer around the complete reloads would be some sort of version stamp that is shared between slave and master. Doesn't really have to be the SOA serial, you can use whatever you want.
The slave connects and registers with the master first, locks sql in read-only mode, clears unprocessed zone change messages from the master (there is about 0.001% chance of any zone change messages at this stage anyway) and then reloads from sql. Changes sent by the master during this stage will be held in a queue and not processed before reload is finished. This should guarantee that the local zone data is equal to the master. If the slave should die during the lock a certain timeout would unlock it. We do a complete reload since it only takes 3 seconds. This is where it becomes interesting. I am quite confident that comparing SOA/zone changes would actually take longer time. At least for us using SQL since a SQL query will take prox 20ms before a reply is given. Lets say 10% of the domains were altered. This is a pretty high number though. You have to get the new SOA's from SQL. Lets just say that this has already been done. Now, 10% altered zones out of 30 millions equals to 1000 minutes in latency only to deal with sql zone retrieve calls, not the processing of the data. I am quite sure a raw dump would require less time and less cpu resources by the sql server and perhaps even on the slave depending on the size of each zone. If you only have a few large zones then of course the result would not be the same. However if you have frequent updates on these few large zones you would probably have to reload everything anyway. You could always try reducing the amount of sql calls by grouping them together, but that might look "ugly". Nameservers doesn't usually lose connectivity anyway, but of course they do time to time. There is also a solution doing transaction logging when a slave gets disconnected. We skipped this because it is easier to add and delete new slaves without having to configure the master without. A transaction log could also get very high if the slave was down for a large amount of time and the implications generally about knowing if a slave actually performed the change or not made us skip this. Joergen Hovland ENK