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).
When it comes to zone updates we use a tcp/ip connection to the master server instead of altering the database directly. We don't need to probe for db changes this way.
Well, that makes sense, but no one in their right mind is probing for changes since NOTIFY was defined many years ago.
The user issues a command and the nameserver replies ok or error and so on. You can only add/del/change data, not list/view it. A change results in that the master updates the local memory of the change only and then the sql server, finally it sends the update to any connected slaves. Slaves are registered with the master through a permanent tcp connection and receive updates whenever somebody alters data in a non zone-transfer/axfr compatible way. We actually don't have support for normal zone transfers at all. The master sends the actual change, not the entire zone or a zone reload request. So both master and slaves updates their local copy instantly.
If a slave gets disconnected from the master, it will reload the whole database from the sql server when reconnected to the master in order to ensure no loss of data since the master doesn't keep track on the status of any of the slaves. This reload takes seconds for a small/medium sized database (10k+). When the data has been loaded and sorted the nameserver replaces it with the existing local copy and deletes it from memory. This ensures no downtime.
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. If you need to serve zones of non-trivial size that would seem to be a good idea.
Serial numbers are simply autocalculated from the current time and its not possible for a user to do anything about it.
I.e. the SOA serial is *changed* by the slave. This too won't fly too well with DNSSEC.
The response latency is the same as with bind but it uses significantly less memory. I havent really done the research to know why. Since we use a tcp connection to the nameserver as way of managing zones, the wrong things you can do is very few.
Regards, Johan Ihrén Autonomica