Suitability of LDAP as DNS backend - PowerDNS LDAP backend moving to unmaintained status
Hi,
We've been using for several months PowerDNS Authoritative Server v9.22 with LDAP backend (simple mode), using OpenLDAP (v2.4.22) for hosting our organization's domains (and reverse zones) and it has been working fine (low query times, reliable etc.) so we enjoy having all our organization's data stored/maintained in the same DIT in LDAP.
However, as PowerDNS Authoritative Server is preparing for the next version (3.0), it seems that the LDAP backend will be unmaintained (see: http://mailman.powerdns.com/pipermail/pdns-users/2011-March/007547.html) as the LDAP backend developer is no more working on it (see: http://www.mail-archive.com/pdns-users@mailman.powerdns.com/msg03625.html).
It has been alleged (see ref. above) that "We don't think that LDAP is a particularly good or interesting place to store DNS data. It will for example have big problems with PowerDNSSEC because of lack of ordering." Moreover, PowerDNS LDAP backend (although current open bugs are very few and of relatively low severity) lacks features (e.g. Notify, which we implement using custom script, cron and notify-dns-slaves, see: http://mailman.powerdns.com/pipermail/pdns-users/2010-October/007109.html) and is not being evolved any more.
Additionally, LDAP/database backend projects for BIND9 (SDB and DLZ) do not seem very well maintained either. In any case we prefer PowerDNS approach where backend implementation is cleaner and direct.
So, my questions:
* From the above and your experience, do you consider LDAP should not be preferred as DNS backend? * Should LDAP be avoided as a DNS/DNSSEC backend? * Would any companies / developer(s) from the OpenLDAP world - perhaps already using or interested in using DNS with LDAP backend - would be willing to devote some time to fix a couple of small bugs and keep the very well-designed and developed PowerDNS LDAP backend in shape? We could even start some community donation effort (to support this development), but I don't know if there is sufficient usage/interest in the LDAP backend that would generate enough funds.
In essence, should we drop LDAP as a DNS Record datastore, due to the lack of a properly maintained backend and/or unsuitability for (e.g. DNSSEC) evolution, or you think there IS interest for the maintenance / evolution of the LDAP backend by the OpenLDAP developers/community (even by becoming more openldap-oriented rather than being cross-platform)?
Best Regards, Nick
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@eurobjects.com wrote:
Hi,
We've been using for several months PowerDNS Authoritative Server v9.22 with LDAP backend (simple mode), using OpenLDAP (v2.4.22) for hosting our organization's domains (and reverse zones) and it has been working fine (low query times, reliable etc.) so we enjoy having all our organization's data stored/maintained in the same DIT in LDAP.
However, as PowerDNS Authoritative Server is preparing for the next version (3.0), it seems that the LDAP backend will be unmaintained (see:
http://mailman.powerdns.com/pipermail/pdns-users/2011-March/007547.html)
as the LDAP backend developer is no more working on it (see:
http://www.mail-archive.com/pdns-users@mailman.powerdns.com/msg03625.html).
It has been alleged (see ref. above) that "We don't think that LDAP is a
particularly good or interesting place to store DNS data. It will for example have big problems with PowerDNSSEC because of lack of ordering."
Moreover, PowerDNS LDAP backend (although current open bugs are very few
and of relatively low severity) lacks features (e.g. Notify, which we implement using custom script, cron and notify-dns-slaves, see:
http://mailman.powerdns.com/pipermail/pdns-users/2010-October/007109.html)
and is not being evolved any more.
Additionally, LDAP/database backend projects for BIND9 (SDB and DLZ) do not seem very well maintained either. In any case we prefer PowerDNS approach where backend implementation is cleaner and direct.
So, my questions:
* From the above and your experience, do you consider LDAP should not be preferred as DNS backend? * Should LDAP be avoided as a DNS/DNSSEC backend? * Would any companies / developer(s) from the OpenLDAP world - perhaps already using or interested in using DNS with LDAP backend - would be willing to devote some time to fix a couple of small bugs and keep the very well-designed and developed PowerDNS LDAP backend in shape? We could even start some community donation effort (to support this development), but I don't know if there is sufficient usage/interest in the LDAP backend that would generate enough funds.In essence, should we drop LDAP as a DNS Record datastore, due to the lack of a properly maintained backend and/or unsuitability for (e.g. DNSSEC) evolution, or you think there IS interest for the maintenance / evolution of the LDAP backend by the OpenLDAP developers/community (even
by becoming more openldap-oriented rather than being cross-platform)?
Best Regards, Nick
On 28/4/2011 3:13 μμ, Torsten Schlabach (Tascel eG) wrote:
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.)
Thank you and Ben for your feedback. I agree to the above, that's why we decided to use it in the first place!
What does PowerDNS to what BIND doesn't do for you?
Frankly, I don't like BIND having a very large share of the market! Additionally, I have come to like PowerDNS and its LDAP backend; it has an easy setup and it is fast; it also has a nice "family"-like community. Moreover, as we have recently invested a lot of effort to setup the current backbone (including an internal Web application for DNS record management) and BIND uses a different LDAP schema, we would not be willing to start a new migration process... Unfortunately, we didn't expect that PowerDNS LDAP-backend would remain without a developer and we have no resources (funds or people) to engage in PowerDNS ldap-backend development.
So, I am posting here partly to attract attention of LDAP administrators/organizations using LDAP as DNS store in their DNS Server Software, esp. PowerDNS and developers who might be interested therein.
Nick
Nick Milas wrote:
On 28/4/2011 3:13 μμ, Torsten Schlabach (Tascel eG) wrote:
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.)
Thank you and Ben for your feedback. I agree to the above, that's why we decided to use it in the first place!
What does PowerDNS to what BIND doesn't do for you?
Frankly, I don't like BIND having a very large share of the market! Additionally, I have come to like PowerDNS and its LDAP backend; it has an easy setup and it is fast; it also has a nice "family"-like community. Moreover, as we have recently invested a lot of effort to setup the current backbone (including an internal Web application for DNS record management) and BIND uses a different LDAP schema, we would not be willing to start a new migration process... Unfortunately, we didn't expect that PowerDNS LDAP-backend would remain without a developer and we have no resources (funds or people) to engage in PowerDNS ldap-backend development.
So, I am posting here partly to attract attention of LDAP administrators/organizations using LDAP as DNS store in their DNS Server Software, esp. PowerDNS and developers who might be interested therein.
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.
On 29/4/2011 1:19 πμ, Howard Chu 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.
For informational purposes, those who want to know PowerDNS and are using BIND8/9, could read this: http://laurent.bachelier.name/2009/03/switching-from-bind-to-powerdns-in-a-f...
If you want to try PowerDNS with LDAP backend, there is a script bundled in PowerDNS called zone2ldap which works very nice (read: http://www.linuxnetworks.de/doc/index.php/PowerDNS_LDAP_Backend/Migration). Use *simple style* (tree style is practically incompatible with IPv6 and doesn't allow subdomain/subzone delegation) as explained here: http://www.linuxnetworks.de/doc/index.php/PowerDNS_LDAP_Backend/Example.
Migration from standard BIND9 (text files) to PowerDNS LDAP, even for testing, is much faster and easier than one might thought.
I can help with implementation details from my experience for anyone interested, but, unfortunately, I am not a developer to be able to engage in development. So, developers (or funding...) wanted! :-)
Regards, Nick
----- Original Message -----
On 28/4/2011 3:13 μμ, Torsten Schlabach (Tascel eG) wrote: Moreover, as we have recently invested a lot of effort to setup the current backbone (including an internal Web application for DNS record management) and BIND uses a different LDAP schema
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
On 28/4/2011 3:13 μμ, Torsten Schlabach (Tascel eG) wrote:
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.
I just wanted to add that according many testimonies, like: https://lists.isc.org/mailman/htdig/bind-users/2011-February/082814.html, BIND9 with LDAP over DLZ has a very low performance, making it unsuitable for production systems, which is not the case with PowerDNS.
So, it seems, PowerDNS with LDAP backend is the only truly viable solution in production, and PowerDNS is in risk of dropping maintenance of this backend!
Best regards, Nick
----- Original Message -----
On 28/4/2011 3:13 μμ, Torsten Schlabach (Tascel eG) wrote:
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.
I just wanted to add that according many testimonies, like: https://lists.isc.org/mailman/htdig/bind-users/2011-February/082814.html, BIND9 with LDAP over DLZ has a very low performance, making it unsuitable for production systems,
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 3/5/2011 9:28 πμ, Buchan Milne wrote:
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.
Thanks Buchan,
This architecture makes sense! This should be practically the only architecture to implement when using BIND with SDB or DLZ, and it makes it worthwhile (with some added complexity).
Still, PowerDNS works very well with the LDAP backend even when serving clients directly, it has an easy setup, great security record, and it can simplify the DNS infrastructure considerably (by using only LDAP replication), so I still urge any interested parties (developers, companies through funding), to engage in its maintenance!
Nick
On Tue, 3 May 2011 08:28:02 +0200 (SAST), Buchan Milne bgmilne@staff.telkomsa.net wrote:
I just wanted to add that according many testimonies, like:
https://lists.isc.org/mailman/htdig/bind-users/2011-February/082814.html,
BIND9 with LDAP over DLZ has a very low performance, making it unsuitable for production systems,
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
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 3/5/2011 12:57 μμ, Torsten Schlabach (Tascel eG) wrote:
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.
IPv6 in PowerDNS works fine (we are actively using it in our networks: PowerDNS binds to IPv4/IPv6 addresses alike, and it replies to IPv6 queries) but I don't have performance data. I don't know about BIND9 with DLZ or SDB.
PowerDNS Authoritative Server v3.0 (now RC2) will also include DNSSEC (but not for the LDAP backend, unfortunately. See: http://powerdnssec.org/
BIND10 is still 3 years away.
Nick
On Tuesday, 3 May 2011 11:57:36 Torsten Schlabach (Tascel eG) wrote:
On Tue, 3 May 2011 08:28:02 +0200 (SAST), Buchan Milne
bgmilne@staff.telkomsa.net wrote:
I just wanted to add that according many testimonies, like:
https://lists.isc.org/mailman/htdig/bind-users/2011-February/082814.html,
BIND9 with LDAP over DLZ has a very low performance, making it unsuitable for production systems,
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
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.
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 ....
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?
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.
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.
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.
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.
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
On 3/5/2011 12:57 μμ, Torsten Schlabach (Tascel eG) wrote:
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.
To provide an update on this, PowerDNS development leader (Bert Hubert) has just now posted this message re. LDAP backend in PowerDNS:
"We've had one request from a company what the cost would be, we made an estimate of around 3500 euros to fix up the LDAP backend bugs and support it for the coming years.
This is probably beyond the 'have some people donate' amount, but for a company that depends on LDAP, it should be quite doable."
Nick
I just wanted to add that according many testimonies, like: https://lists.isc.org/mailman/htdig/bind-users/2011-February/082814.html, BIND9 with LDAP over DLZ has a very low performance, making it unsuitable for production systems, which is not the case with PowerDNS.
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
On 4/5/2011 8:24 πμ, Jorgen Lundman wrote:
All DNS records are instantly updated, including DynDNS service. No restarts ever required. We are very happy with this setup.
Thanks for this post. It is important to exchange experience with such technologies.
We are using the same setup (at a smaller scale, because we are just a Research Center and serve our own needs), but with PowerDNS/LDAP backend.
I would find it interesting if you could also provide info on: 1. How do you administer your DNS zones/RRs ? 2. Which OS are you using on your servers? 3. Which ldap / BIND9 packages are you using? (Or you compile from source?) 4. Do you use DNSSEC with this setup?
By the way, I find it a bit strange that you are having problems with syncrepl. We haven't got such problems (when we configure consumers to regularly attempt to reconnect to the provider in case they lose connection).
Best Regards, Nick
I would find it interesting if you could also provide info on:
- How do you administer your DNS zones/RRs ?
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)
- Which OS are you using on your servers?
Solaris 10u9, on Supermicro x64 servers (3012s).
- Which ldap / BIND9 packages are you using? (Or you compile from source?)
Compiled from source. On the schedule to be upgraded too, but
db-4.2.52 openldap-2.3.41 bind-9.5.2
- Do you use DNSSEC with this setup?
Not yet.
By the way, I find it a bit strange that you are having problems with syncrepl. We haven't got such problems (when we configure consumers to regularly attempt to reconnect to the provider in case they lose connection).
Definitely a problem with bulk deletions, affecting all of LDAP, not just DNS specific. Without deletions, we rarely have troubles.
On 5/5/2011 4:09 πμ, Jorgen Lundman wrote:
Sure, not sure how much you want to know, might get boring.
(Sorry for my delayed reply.) Thanks for all the info. Quite interesting!
...
Compiled from source. On the schedule to be upgraded too, but
db-4.2.52 openldap-2.3.41 bind-9.5.2
You should upgrade. Expect much better openldap behavior with 2.4.22 - 2.4.25 versions (which I am now using, after occasional problems with 2.3.43).
Nick
On 4/5/2011 8:24 πμ, Jorgen Lundman wrote:
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.
Here: http://old.nabble.com/Some-DNS-performance-tests-with-various-PDNS-backends-...
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
Nick Milas wrote:
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 might be able to help here. We use:
include /usr/local/etc/openldap/schema/dlz.schema
named.conf has:
dlz "ldap zone" { database "ldap 20 v3 simple {cn=admin,dc=company,dc=com} {ldappasswd} {127.0.0.1} ldap:///DNSZoneName=$zone$,ou=dns,dc=company,dc=com???objectclass=DNSZone ldap:///DNSHostName=$record$,DNSZoneName=$zone$,ou=dns,dc=company,dc=com?DNSTTL,DNSTy pe,DNSPreference,DNSData,DNSIPAddr,DNSPrimaryNS,DNSAdminEmail,DNSSerial,DNSRefre sh,DNSRetry,DNSExpire,DNSMinimum?sub?objectclass=DNSAbstractRecord {} ldap:///DNSZoneName=$zone$,ou=dns,dc=company,dc=com?DNSTTL,DNSType,DNSHostName,DNSPre ference,DNSData,DNSIPAddr,DNSPrimaryNS,DNSAdminEmail,DNSSerial,DNSRefresh,DNSRet ry,DNSExpire,DNSMinimum?sub?objectclass=DNSAbstractRecord ldap:///DNSZoneName=$zone$,ou=dns,dc=company,dc=com??sub?(&(objectclass=DNSXFR)(DNSIPAddr=$client$))"; };
Might be broken up by my email client.. 127.0.0.1 is IP of slapd, we run on localhost for speed and redundancy.
20 is num threads to LDAP, and we start bind with "/usr/local/sbin/named -n 10"
A typical DNS record would look like:
# jorgen.jp, dns, company.com dn: DNSZoneName=jorgen.jp,ou=dns,dc=company,dc=com objectClass: DNSZone DNSZoneName: jorgen.jp
# @, jorgen.jp, dns, company.com dn: DNSHostName=@,DNSZoneName=jorgen.jp,ou=dns,dc=company,dc=com objectClass: DNSHost DNSHostName: @
# SOA, @, jorgen.jp, dns, company.com dn: DNSRecord=SOA,DNSHostName=@,DNSZoneName=jorgen.jp,ou=dns,dc=company,dc=com objectClass: DNSSOARecord DNSHostName: @ DNSRecord: SOA DNSType: soa DNSSerial: 2007071201 DNSRefresh: 28800 DNSRetry: 7200 DNSExpire: 604800 DNSMinimum: 86400 DNSAdminEmail: hostmaster.new-style.company.com. DNSPrimaryNS: dns02.new-style.company.com. DNSTTL: 86400
# MX0, @, jorgen.jp, dns, company.com dn: DNSRecord=MX0,DNSHostName=@,DNSZoneName=jorgen.jp,ou=dns,dc=company,dc=com objectClass: DNSMXRecord DNSRecord: MX0 DNSHostName: @ DNSType: MX DNSData: mx.new-style.company.com. DNSPreference: 10 DNSTTL: 86400
# TXT0, @, jorgen.jp, dns, company.com dn: DNSRecord=TXT0,DNSHostName=@,DNSZoneName=jorgen.jp,ou=dns,dc=company,dc=com objectClass: DNSTEXTRecord DNSRecord: TXT0 DNSHostName: @ DNSType: TXT DNSData: "v=spf1 +ip4:1.2.3.4/24 ~all" DNSTTL: 86400
# www.jorgen.jp, jorgen.jp, dns, company.com dn: DNSHostName=www.jorgen.jp,DNSZoneName=jorgen.jp,ou=dns,dc=company,dc=com objectClass: DNSHost DNSHostName: www.jorgen.jp
# A1, www.jorgen.jp, jorgen.jp, dns, company.com dn: DNSRecord=A1,DNSHostName=www.jorgen.jp,DNSZoneName=jorgen.jp,ou=dns,dc=company,dc=com objectClass: DNSARecord DNSRecord: A1 DNSHostName: www.jorgen.jp DNSType: A DNSIPAddr: 4.3.2.1 DNSTTL: 600
On 12/5/2011 10:58 πμ, Jorgen Lundman wrote:
I might be able to help here. We use:
include /usr/local/etc/openldap/schema/dlz.schema
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
Thanks Jorgen, but in fact I would like to know the bind dlz configuration when using the *dNSzone* schema and not the dlz one.
Ah, then I can not help. We converted from DLZ-HPTBDB to DLZ-LDAP/dlz.schema, by writing own perl converter.
Lund
Nick Milas wrote:
On 4/5/2011 8:24 πμ, Jorgen Lundman wrote:
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.
Here: http://old.nabble.com/Some-DNS-performance-tests-with-various-PDNS-backends-...
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.)
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.
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 2011.04.28 05.31, Nick Milas wrote:
It has been alleged (see ref. above) that "We don't think that LDAP is a particularly good or interesting place to store DNS data.
this doesn't make much sense to me. from the perspective of traditional [e.g. non dnssec], it's simply another place in which data can be stored. from a dnssec perspective, you could perhaps argue there is additional complexity since rrsets and zones now need to be signed, but really, this is still fundamentally no different than singing the data stored via some other means. the data must be parsed, processed, and written, in some way. just as there are already mechanisms in place for doing this with traditional text files, the very same could be done for data stored in ldap. whatever needs to be done must as some point be done for the first time. the existence of "natural" methods like writing to a text file certainly don't preclude other methods from having value simply because they've not yet been given a formal implementation.
additionally, there is software like phreebird [a dnssec proxy], which allow you to retain all of your dns data in its traditional form, and still provide signed zones. lastly, iirc, the notion of a dns related overlay and/or backend has come up here on occasion. not only would this obviously be a natural fit for openldap, the concepts involved in dnssec could be integrated quite nicely.
Additionally, LDAP/database backend projects for BIND9 (SDB and DLZ) do not seem very well maintained either. In any case we prefer PowerDNS approach where backend implementation is cleaner and direct.
with respect to bind, if i were you, i'd keep up to date on the development of bind 10. while it's not my place to speak for the developers, i think you're likely to find quite a bit of attention given to abstraction between the server and its backend ;)
-ben
openldap-technical@openldap.org
-
btb＠bitrate.net -
Buchan Milne -
Howard Chu -
Jorgen Lundman -
Nick Milas -
Torsten Schlabach (Tascel eG)