Anyone has experience with DLZ drivers?

[Graeme Fowler]

Hi

On Mon, 2007-07-16 at 09:19 +0200, Adam Tkac wrote:
> I did some investigations around DLZ drivers (mostly on 
> http://bind-dlz.sourceforge.net/). Looks like this is good solution when 
> server has many zones and is queried only sometimes (or only for 
> specific set of RRs) but bad idea when server has to reply to all his 
> RRs and is under heavy load. Did anyone has experience with this? Is it 
> really better than standard zone loading? Or only one of the 
> "theoretical" performance increase.

Yes, I have some (although I've not used it in the last 15 months or
so). I built an authoritative name server solution for a large UK based
domain registration company using DLZ, and the DLZ part worked
flawlessly.

We went from a startup time of over 18 hours for each nameserver (on
pretty fast hardware) to a startup time less than ten seconds. We used a
MySQL backend (the only reason for this was that we had a number of
experienced MySQL administrators) where each client-facing nameserver
had its' own copy of a replicated master database; BIND never
experienced memory problems, which it used to do with the old
"monolithic" config file whereby the few clients we had using the system
for recursion would cause the named process to chew up to 2 or 3GB of
RAM (I forget which) at which point the kernel would kill the process,
and we'd be back into 18-hour startup land.

With hindsight, stopping recursion would have helped with that, but we
were young and naive at the time :)

As I recall, the cluster (it was load balanced) was serving somewhere in
the region of 3-500 queries/second when I departed the company, and the
frontend servers had almost no load.

Of course, with a setup like this you have to take several issues into
account:

1. Replication must be robust (yes, I know, MySQL...)
2. The DB server the DLZ zones load from must never lock - DB dumps must
be taken elsewhere. We used an intermediary slave server off the master
for this.
3. The master server must never, ever, drop the database (this is *much*
easier to do than deleting zillions of zone files!).
4. Databases must be consistent on all client-facing servers.
5. Using MySQL's query cache reduces the load on the DB servers
dramatically, especially if the zone data is relatively static.

Much of this advice is the same as it is for servers using a per-zone
config with "normal" zone files, but the semantics are different.

Obviously, good DB design is important too - you're not dealing with
zone files, so optimising the DB or the lookups you need to do helps
with performance. It moves at this point from being a "classical"
nameserver being managed by system admins with DNS experience to a
well-optimised database run by a DB administrator with an application on
top of it run by others (where both roles might be carried out by the
same person/people, but still).

Graeme