[dns-wg] Analysis of NSD

----- Original Message ----- 
From: "Jim Reid" <jim at rfc1035.com>


> I would also encourage operators to share their experiences of
> different name server implementations here: performance, protocol
> compliance, features, management & support issues, SLAs with hosting
> providers, etc, etc. Capturing and documenting this anecdotal
> information would be very useful.
>

Hello
We are running our own implementation of a domain name server for our 
hosting company. Its unfortunately not publicy available and I have no 
additional information, but I thought the implementations might be 
interesting anyway. We have been running this software for 2 years now.
    The nameserver is using SQL as a direct back-end but all servers loads 
data into memory for optimisation reasons during startup. They sort the data 
into a tree-like structure but doesn't calculate all possible queries or 
answers. This reduces the amount of ram needed. Besides not all records 
return static data. We have a few special features so it could easily eat a 
million gb of ram if we did do it. Some of these are autogeneration of 
forward/reverse dns based on wildcard/regexp records (so that 100 billion 
ipv6 addresses doesn't make 200 billion records in dns but only 2) and 
different replies depending on the country origin of the source ip of the 
querying nameserver/client. The answer depends on another external database 
in other words.  We also dropped all RRs which no customer have ever asked 
for (we add it on demand though).
    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.  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.
Serial numbers are simply autocalculated from the current time and its not 
possible for a user to do anything about it.
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.
We do have a different policy with regards to valid characters (iso-xx, 
utf8, idn). The nameserver accepts anything and it's up to the customer to 
decide what they want. Browsers like msie and internet daemons using 
different encodings will be able to use the same host name when the customer 
have the ability to add all possible encoded versions of it (hope I'm not 
starting an argument here.).

Cheers,

Joergen Hovland ENK