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