Re: [dns-wg] Analysis of NSD

[Jørgen Hovland <]

----- Original Message ----- 
From: "Johan Ihrén" johani@localhost


> 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