a lot of people are curious as to how ldapdns stacks up to other DNS servers. ldapdns djbdns bind msdns ----------------------------------------------------------------------- threaded yes no[11] no probably scalable yes no no[6] no[8] live update yes[1] yes[3] yes[7] yes[9] bind zone file yes[2] no[4] yes yes[2] ldap support yes no no yes client diff. yes yes no yes recursive no yes[5] yes yes size (in lines) 6k 11k 233k ?[10] unixish? yes yes[12] yes no windows? no no yes yes [1] ldapdns supports live update by-way of it's LDAP server security is enforced by the LDAP server [2] MS-DNS and ldapdns can both import BIND zone files. [3] djbdns does not keep queries in memory; all requests go to the disk [4] there are third party tools to support imports [5] djbdns uses a tool called dnscache to provide recursive-resolver capabilities. i highly recommend it's use. [6] bind is about as un-scalable as you can get. it's bloated and sluggish, it is NOT multithreaded, and must keep all records in memory. [7] bind supports live updates through the NS-UPDATE protocol which tries to attach modification requests into the DNS protocol stream. there are no security considerations whatsoever when using NS-UPDATE [8] i discount MSDNS scalability simply because it isn't tunable, and responsiveness does not seem to increase linearly as ram and cpus increase. [9] MSDNS also supports NS-UPDATE, but it is less favored that Microsoft's internal update that relies on Active Directory. [10] my guess? huge. [11] djbdns would never benefit from a threaded core. the response loop is tighter than a single task-switch in many cases. preforking can improve response times on multiprocessor machines- but nowhere else. [12] unixish on djbdns means many things. i suspect djbdns will be the last djb software written for unixish systems. take this how you like. [*] size in LOC (lines of code) is difficult to understand. said plainly, the less code there is, the easier it is to determine where problems are. LDAPDNS is huge (imho) as a nameserver (non-proxying, non-caching), and yet I cannot imagine that even 10% of BIND is "only" the content serving part. security comparisons are difficult to come by. MSDNS is highly integrated into Active Directory, so you could say that any and all Active Directory bugs are also bugs to MSDNS. Likewise, LDAPDNS is at the mercy of your LDAP directory. BIND is historically bad -- and the only other nameserver that truly controls its surroundings is DJBDNS. It shouldn't suprise you that DJBDNS has a better security record than BIND, but with proper premaintainence, it should be possible to set up BIND in a secure environment. interestingly enough, MS-DNS, the only really-commercial product that I listed is NOT the one with the security guarantee. presently only djbdns comes with a security guarantee. LDAPDNS should be adaquite: it does not cache, nor allow editing of the directory. It runs in a chrooted jail, with minimal permissions. it cannot be poisioned by any conventional means, and even if the LDAPDNS machine is comprimised, this does not mean that false DNS data can be generated (a short explaination on that: someone would have to replace the ldapdns server with a fake one with fake data. running a read-only filesystem is a good way to guarantee this doesn't happen -- ldapdns does not require write-access anywhere) Addendum: Many people check their LDAPDNS performance by timing something like this: $ time for D in `seq 1 1000`; do host -a domain.com ip.ldapdns; done >/dev/null And then wonder how could ldapdns _possibly_ be faster than BIND or DJBDNS! The simple answer is that for such a small load, it never will be. BIND and DJBDNS can take advantage of having their records stored in memory, and querying an external source will never be faster than that... ... unless your domain structure is so large and your requests are so diverse that you cannot store your records in memory. However, _updating_ the data that LDAPDNS is _much_ faster than BIND or DJBDNS. Plus you get to take advantage of the replication in your LDAP server which is likely to be much more efficient than BIND or DJBDNS. Additional addendum: Run properly, it should be impossible for anything short of a DOS to stop LDAPDNS, and the threading core of LDAPDNS makes that rather difficult. I have tried to provide instructions as-to what properly really means, but the fact is that a would-be attacker has a much better chance against your directory than they do against my nameserver. LDAPDNS is an extremely simple piece of equipment -- it doesn't need to write anything, it doesn't store anything the user says. It's content only, chrooted, unprivelged process. The user doesn't have any control over any buffer (the response buffer code is almost identical to what djbdns uses) so LDAPDNS is about as low-risk as you can get. If you do not believe me, that's fine. Look at the code, and tell me what you do believe. I'll make every effort to fix every bug as quickly as possible -- I'll accept patches too. I'll never charge for updates (ISC), and I'll often add features just because they were requested. I strongly believe that LDAPDNS is the best kind of free software because the author is sticking out the proverbial neck here.