Since the openldap update 2.3.30-r2, le LDAP URL are no more recognized in the named.conf. Reproducible: Always Steps to Reproduce: 1. compile BIND with DLZ and LDAP 2. add dlz "ldap zone" { database "ldap 2 v3 simple {} {} {10.1.2.253} ldap:///dlzZoneName=%zone%,ou=dns,o=bind-dlz???objectclass=dlzZone ldap:///dlzHostName=%record%,dlzZoneName=%zone%,ou=dns,o=bind-dlz?dlzTTL,dlzType,dlzPreference,dlzData,dlzIPAddr?sub?(&(objectclass=dlzAbstractRecord)(!(dlzType=soa))) ldap:///dlzHostName=@,dlzZoneName=%zone%,ou=dns,o=bind-dlz?dlzTTL,dlzType,dlzData,dlzPrimaryNS,dlzAdminEmail,dlzSerial,dlzRefresh,dlzRetry,dlzExpire,dlzMinimum?sub?(&(objectclass=dlzAbstractRecord)(dlzType=soa)) ldap:///dlzZoneName=%zone%,ou=dns,o=bind-dlz?dlzTTL,dlzType,dlzHostName,dlzPreference,dlzData,dlzIPAddr,dlzPrimaryNS,dlzAdminEmail,dlzSerial,dlzRefresh,dlzRetry,dlzExpire,dlzMinimum?sub?(&(objectclass=dlzAbstractRecord)(!(dlzType=soa))) ldap:///dlzZoneName=%zone%,ou=dns,o=bind-dlz???(&(objectclass=dlzXFR)(dlzIPAddr=%client%)) "; }; to /etc/bind/named.conf 3. start named Actual Results: the log says :"failed to parse ldap URL" Expected Results: eb 15 16:51:35 sc1 process `named' is using obsolete setsockopt SO_BSDCOMPAT Feb 15 16:51:35 sc1 named[2220]: Loading 'ldap zone' using driver ldap Feb 15 16:51:35 sc1 named[2220]: command channel listening on 127.0.0.1#953 Feb 15 16:51:35 sc1 named[2220]: zone 127.in-addr.arpa/IN: loaded serial 2002081601 Feb 15 16:51:35 sc1 named[2220]: zone localhost/IN: loaded serial 2002081601 Feb 15 16:51:35 sc1 named[2220]: running
not a bind's problem, imho.
Hello, I have opened an issue to the openldap team; here is there and my answer: ----BEGIN------------------------------------------- Tanks for your answer. I tested by removing the %xxxx% from the URL and the tests are passed; but there is an error saying that there is no %xxx% token. I already open a case to the BIND team, but they reply this is not a bind problem. However, I will transmit this information to the BIND/DLZ team. -----Message d'origine----- De : Pierangelo Masarati [mailto:ando@sys-net.it] Envoyé : vendredi 23 février 2007 12:56 À : Cyril COUPEL; openldap-its@openldap.org Objet : Re: (ITS#4849) LDAP URL not recognized with bind9 Please keep replies on the Issue Tracking System (ITS) list, otherwise you'll defeat its purpose of tracking issues. Cyril COUPEL wrote: > I agree with this information. > The fact is the ldapURL is not used as it, the key %zone% (or > %client%) is replaced with the ns domain (the client name). > > It was working well since I upgrade to 2.3.30-r2. > I tried to downgrade to a previous version of openldap and it was > working again, so it is a openldap problem. I see the fact that earlier versions of OpenLDAP were not compliant with standard track documents as a good reason to improve it by making it compliant, rather than a reason to keep it broken. The client is broken since it appears to parse the URL __before__ replacing portions of it that are marked using a character that is invalid in URLs. Either that client implements and uses its own broken URL parsing routines (at the risk of parsing broken URLs incorrectly, since they contain invalid characters), or it does URL parsing __after__ string replacement (i.e. after their string has been turned into a valid URL). I don't see why OpenLDAP should break (or, in this case, remain broken) to maintain compatibility with a poorly implemented client. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati@sys-net.it ------------------------------------------ ----END-------------------------------------------
upstream has a (temporary) patch for it: http://article.gmane.org/gmane.network.dns.bind9.dlz/1614 please test (and apply) it
that workaround can break existing bind+dlz installations, so i think we should wait for correct solution @ upstream.
*** Bug 182576 has been marked as a duplicate of this bug. ***
*** Bug 188989 has been marked as a duplicate of this bug. ***
(In reply to comment #6) > *** Bug 188989 has been marked as a duplicate of this bug. *** > This bug since February is present. Even the patch(Markus Ullmann) is, and correction in a package till now is not present. In what has put? With that patch it's working perfectly.
