Hi Nick, hi all! My 2 cents on this: I think there are two quite independent questions here, which are: 1. Is LDAP a good database to store DNS information in? I mean, conceptually. 2. How is the support for LDAP as a backend database in various DNS server implementations? Talking about question #1: What are the alternatives available? - files ? - relational databases? IMO the good old zone files are not really up to the task unless you are editing them manually in vi. Whenever you are looking for some kind of automation, you need to write way more complex scripts than you want to. And you always risk that any manual edits of the zone files break your parser or anything. So zone files are really not an option if you ask me. Wether you use LDAP or relational databases for some people is a question of taste or what you are used to. If you have never worked with LDAP but you are very confident with MySQL, then you may for sure prefer a relational database as backend storage. But this is a bit of the good old "if the only tool you have is a hammer, ..." kind of thing. LDAP is different from relational databases in a number of aspects. To name a few: - LDAP is query optimized while relational databases are optimized for OLTP. In other words, LDAP's perforamance on updates may be a lot worse than that of a relational database. But it's query performance should be a lot better. I do admit though that given today's processing power available, in many cases it will be hard to measure the difference here. - LDAP stores tree like structures, not tables. LDAP is really nice if you want to have one tree with different branches which different people, groups, organizations have access to. LDAP ACLs are very fine graine. Many SQL databases (especially the "cheaper" ones; cheaper in the sense of resources, not money) have nothing at all or very black / white ACL schemas available. - LDAP has been designed for replication, which is a major plus in many setups. Yes, you can replicate relational databases as well, but this is a quite complex process. See also the last remark. - If one understands how LDAP schemas work, one can very easily attrach attributed needed by DNS to exsting LDAP objects describing your systems. So IMO LDAP *is* the best suited backend storage for DNS database data that I know of. (I am always open to new ideas I may not yet have heared or though of.) Talking about question #2: I never used PowerDNS, we always went with BIND. Fortunately the DLZ parts made it into the code and the version which has them built in made it into the standard Linux distros in the meanwhile. AFAIK there are no plans to drop LDAP backend support from BIND. So maybe you should just consider to switch there. What does PowerDNS to what BIND doesn't do for you? Regards, Torsten On Thu, 28 Apr 2011 12:31:02 +0300, Nick Milas <nick(a)eurobjects.com&gt; wrote: http://www.mail-archive.com/pdns-users@mailman.powerdns.com/msg03625.html). http://mailman.powerdns.com/pipermail/pdns-users/2010-October/007109.html)

Nick Milas wrote: IMO, due to the hierarchical nature of the zone data, LDAP is the *most* appropriate data store for DNS data, it beats SQL on many counts. I've spent some time with the BIND code but hadn't even heard of PowerDNS. Unfortunately, at the moment, while I believe this is interesting and worthwhile, I don't have the time to spend on it. But if anyone else in the community wants to contribute, I'd be open to hosting any relevant work on the OpenLDAP code repos. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

----- Original Message ----- The difference in schema is trivial: 1)Different structural objectclass (domainRelatedObject vs dnsZone) 2)Different attribute for the zone/domain the record belongs to (associatedDomain vs relativeDomainName). All the attributes that actually hold DNS values are the same (bar case). Regards, Buchan

----- Original Message ----- No, making it unsuitable for directly serving DNS clients. The recommended architecture with bind sdb_ldap for use with a high query load is that a named running sdb_ldap be set up as a "hidden" master, with the slaves running traditional file-backed zones to serve DNS clients. Regards, Buchan

On Tue, 3 May 2011 08:28:02 +0200 (SAST), Buchan Milne <bgmilne(a)staff.telkomsa.net&gt; wrote: https://lists.isc.org/mailman/htdig/bind-users/2011-February/082814.html, recommended Honestly, I am not sure how much sense this extra layer makes. I mean, yes, it solves to the problem but to me this is as logical as writing a script which converts the LDAP database content into zone files and run that script via cron. What I like about BIND with DLZ and LDAP is: I edit something and it's there. How often would one recommend the slaves to initiate a zone transfer from the master in Buchan's recommended scenario? Daily? Hourly? If PowerDNS really is so much faster and so much more lightweight (i.e. I have to install only what I need; something which always concerned be a bit when it comes to BIND) then it may indeed be worthwhile to look at. Just me personally our our organization, I cannot promise any real time budget for that right now. Also - while asking myself how much this is becoming off-topic on an OpenLDAP list, but the guys at ISC are also undertaking some serious efforts about BIND 10, which I understand will be a full re-write; see http://www.isc.org/bind10 and http://bind10.isc.org/wiki One question which I guess *does* belong here is what the plans for BIND 10 with regards to LDAP storage are. Maybe some active contribution may be even useful. I think they are also heavily preparing for the long awaited future called IPv6. I am not sure how well BIND 9 with DLZ and / or PowerDNS perform for IPv6 right now, especially thinking about the schema. Regards, Torsten

On Tuesday, 3 May 2011 11:57:36 Torsten Schlabach (Tascel eG) wrote: Not really. You can still point *some* clients at your hidden master. All our internal DNS (forward/reverse for all our internal addresses) is on BIND sdb_ldap, queried directly by our internal servers .... Whenever the serial is changed, as a notify can be sent to the slaves (there is a slapi plugin for this, but it should probably be replaced with an overlay). The same way "normal" BIND slave propagation takes place. It is so much faster than BIND sdb_ldap, because BIND sdb_ldap has *no* caching on the BIND side, whereas normal file-based zones are cached in memory. IPv6 is a non-issue, AFAIK both bind sdb_ldap and PowerDNS have had aAAArecord support for years before there was anything interesting to consumers on IPv6. Regards, BUchan

I too, read that before we rolled out our DNS cluster, but when we came to trying it ourselves, we got completely different results, or perhaps, acceptable results. Sure LDAP+DLZ was not quite as fast as BDB+DLZ, but the latter had so many troubles it was not worth it. We migrated from BDB+DLZ to LDAP+DLZ. We now have one ldap-master, and 6 ldap+bind9+DLZ servers. (3+3 in two data centers). We have had very few troubles with this setup. (troubles are related to syncrepl). Authoritative only, no recursion. No servers in front. Since the BIND+DLZ servers use slapd on localhost, they continue to function if isolated (network troubles etc). All DNS records are instantly updated, including DynDNS service. No restarts ever required. We are very happy with this setup. Currently, it is hosting 150183 domains (not counting sub domains, or records). A random host lookup responds in: 25ms, 1ms, 1ms. Which is acceptable to us. Lund -- Jorgen Lundman | <lundman(a)lundman.net&gt; 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)

Sure, not sure how much you want to know, might get boring. We wrote a Provisioning Engine, in perl, which empties a "provisioning table" in a MySQL database, of commands to perform. Once performed updates the records status. For example: +email, -email, *email (add, delete and modify email) With the case of DNS, the provisioning commands of +-domain, +-*dns modify those. For example: +domain|domain=example.com +dns|domain=example.com|type=A|lhs=www|rhs=192.168.1.1 This way anything (Navi-apache servers, or internal staff tools, etc) can just issue setup commands as needed, and the PROV.pl will execute them when able, usually within a second. They are run in sequence of course. To create an actual new domain with email, you would see something like "+domain, +email, quota, +virus, +spam, enable, welcome". (quota sets disk quota, enable enables smtpauth/pop/imap and welcome sends welcome email) Solaris 10u9, on Supermicro x64 servers (3012s). Compiled from source. On the schedule to be upgraded too, but db-4.2.52 openldap-2.3.41 bind-9.5.2 Not yet. Definitely a problem with bulk deletions, affecting all of LDAP, not just DNS specific. Without deletions, we rarely have troubles. -- Jorgen Lundman | <lundman(a)lundman.net&gt; 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)

On 4/5/2011 8:24 πμ, Jorgen Lundman wrote: Here: http://old.nabble.com/Some-DNS-performance-tests-with-various-PDNS-backen... you can find some new performance tests for BIND9 (SDB) and PowerDNS DNS Servers with LDAP backend (and other backends). Results: ======== (Using BIND9 9.3.6 (13615 qps) as reference) --------------------------------------------- BIND9 9.3.6 : 13615 qps - BIND9 9.7.3 : 12731 qps ===> -6.5% BIND9 9.7.3 / SDB-LDAP : 370 qps ===> -97.3% PDNS 2.9.22 / BIND : 17683 qps ===> +29.9% PDNS 2.9.22 / MYSQL : 16879 qps ===> +24.0% PDNS 2.9.22 / LDAP : 17339 qps ===> +27.4% --------------------------------------------- These results show how important PowerDNS LDAP backend can be, and might provide motivation to organizations to support the project. (3500 EUR have been requested by the PowerDNS project leaders to support the LDAP backend for the next years.) NOTE: I haven't been able to test with BIND9/DLZ. If someone can provide DLZ zone configuration settings (in named.conf) for use with the (sdb) dNSzone schema, or a migration script of ldap entries from dnszone to dlz ldap schema please do! ------------- I have tried to post a more extended version of this email, but my message is not reaching the list, so I am trying with this short version. Check the link at the top for test details. ------------- Nick

On 12/5/2011 10:58 πμ, Jorgen Lundman wrote: Thanks Jorgen, but in fact I would like to know the bind dlz configuration when using the *dNSzone* schema and not the dlz one. I haven't been able to find any script to generate dlz-compatibe ldif from zone (text) data either, nor any converter script of entries from sdb to dlz schema. Converting between dnsdomain2 (pdns) and dnszone (bind-sdb) schema is not complex. However dlz schema is significantly different from both. Nick

Nick Milas wrote: Well, these results just confirm that the BIND9 SDB-LDAP sucks. We knew that already; their LDAP schema treats LDAP as a flat DB and doesn't leverage any of the power of LDAP or hierarchical databases at all. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/