Thanks for your email, (I have included the ML in this reply)

We run Solaris with bind+DLZ+ldap on the DNS servers, and are looking at
better performance. Which means evaluating bind-dyndb-ldap. I did some
minor tweaks to compile bind-dyndb on Solaris.

Since we already have large systems running in production, with
provisioning, and support tools, it is unlikely we would change the schema.
It would probably be less work for me to fork bind-dyndb and massage it
into handling DLZ schema directly.

But before that, we are just evaluating bind-dyndb to decide if it fits
with our systems.

I loaded the 300k zones we have in DLZ-LDAP, into bind-dyndb schema (Just
SOA records with a single ARecord).

The first issue is that to start named takes about 50 mins. This is a bit
of an issue as there is no resolving while it is starting. This seems to be
the same delay each time I start it. slapd is running on localhost, and is
otherwise idle. It is just a large syncrepl for 300k records, always
starting from epoch...

Is it supposed to be able to use the "dump-file" on exit for faster loads?
Perhaps I broke something while porting it to Solaris. I see it create
directories for each zone, only to create an empty "keys" directory. In
addition to that, having 300k entries in one directory might need hashing.
ZFS is ok with it, but it tends to slow down.

However, once it is loaded, it is much faster than DLZ+LDAP. Previous
system would see about 300qps. (All zones, plus
/usr/share/dict/words+".com" with dnsperf)

bind-dyndb gave the same benchmarking test 18796qps.

Now, interestingly, I can also define a DLZ+LDAP line in named.conf after
the bind-dyndb. This has the effect that while bind-dyndb is taking 50 mins
to start up, it will resolve names using DLZ+LDAP. Sure, at the worse qps
of course, but it is at least resolving.

However, that has a side-effect that, once bind-dyndb is loaded, it will
also query DLZ+LDAP on negative entries. Thus decreasing the performance to
3884qps.  Wonder if there is a way to have bind-dyndb ignore DLZ+LDAP /once
it has loaded/.

That is our current situation.



ps. There are some minor faults in the example.ldif, like
""'s idnsName is "". And is missing NSRecord.

Petr Spacek wrote:
> On 25.3.2015 04:45, Jorgen Lundman wrote:
>> Hey Petr,
>> Your name came up on the DLZ list a while back and I was interested in
>> bind-dyndb-ldap. We run DLZ-LDAP here, and after this weeks DDOS
>> firefighting we are looking at increasing our qps.
>> At the moment, each BIND-DLZ-LDAP server can do about 200qps, which is
>> pretty low. But for authoritative it has been sufficient until now. I have
>> fixed DLZ-LDAP, enabling MULTITHREADED (it is off by default for some
>> reason) but still, it has to query the DB each time. The thing refuses to
>> use more than 130MB of cache, each server has 32GB so that is a bit
>> annoying. :)
>> Biggest issue with bind-dyndb-ldap is the schema difference to DLZ's
>> schema.  Most items can probably be handled with straight keyword rename,
>> but one of the larger differences is that bind-dyndb-ldap handles multiple
>> "ARecord" for one entry, whereas DLZ uses that odd "A1,DNSHostName=foo" and
>> "A2,DNSHostName=foo" to do multiples.
>> Do you know if anyone has already looked at DLZ to bind-dyndb-ldap
>> migration? I suppose as a test case (to see what qps I can get), I can
>> convert the DLZ LDAP into zone files, then back to bind-dyndb-ldap schema
>> using your supplied scripts.
>> If you have time, drop me a line.
> Hello!
> As far as I know there is no DLZ->bind-dyndb-ldap convertor.
> I would say that an easiest way is to do AXFR from DLZ-backed zone, save it to
> a file and feed the zone file into
> IMHO it is not worth to develop special DLZ->bind-dyndb-ldap convertor because
> we can always use zone file format as intermediate step.
> LDAP schema used by bind-dyndb-ldap is described on:
> If you have any further questions please contact
> mailing list so everyone including search engines can see it :-)
> Thank you for understanding and have a nice day!

Jorgen Lundman       | <>
Unix Administrator   | +81 (0)3 -5456-2687 ext 1017 (work)
Shibuya-ku, Tokyo    | +81 (0)90-5578-8500          (cell)
Japan                | +81 (0)3 -3375-1767          (home)

Manage your subscription for the Freeipa-users mailing list:
Go to for more info on the project

Reply via email to