Re: [dns-wg] Analysis of NSD

[Johan Ihrén <]

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