[Pdns-users] PDNS ldapbackend issue with PTR queries in strict mode

Luciano Giacchetta luciano at giacchetta.com.ar
Thu Aug 22 20:07:10 UTC 2013


Tom,

I'm facing with same issue. Did you find how fix it?

slapd                           2.4.28-1.1ubuntu4.3
pdns-server                     3.0-1.1ubuntu1
pdns-backend-ldap               3.0-1.1ubuntu1


Luciano.


----- Original Message -----
From: "Tom Bamford" <tom at aims.ac.za>
To: pdns-users at mailman.powerdns.com
Sent: Thursday, September 27, 2012 12:15:06 PM
Subject: [Pdns-users] PDNS ldapbackend issue with PTR queries in strict mode


Hi all 

I have deployed PDNS with the ldapbackend configured in strict mode using OpenLDAP slapd. I am unable to get pdns to return PTR records and despite reading the ldapbackend source and running both daemons with extreme verbosity, cannot seem to figure out why pdns is failing to find the associatedDomain/aRecord entries I have. 

My host entries look like this: 

dn: dc=kingfisher,ou=aims,ou=computers,dc=aims,dc=ac,dc=za 
aRecord: 192.168.42.2 
dhcpHWAddress: ethernet 00:07:E9:06:98:F8 
dhcpStatements: fixed-address 192.168.42.2 
objectClass: dNSDomain2 
objectClass: dhcpHost 
objectClass: domainRelatedObject 
associatedDomain: firewall.aims.ac.za 
associatedDomain: kingfisher-lan.aims.ac.za 
associatedDomain: proxy.aims.ac.za 
associatedDomain: wpad.aims.ac.za 
dc: kingfisher 
cn: kingfisher 


I have an entry containing an SOA record for my reverse zone which looks like this: 

dn: dc=168.192.in-addr.arpa,ou=dns,dc=aims,dc=ac,dc=za 
dc: 168.192.in-addr.arpa 
sOARecord: ns1.aims.ac.za hostmaster at aims.ac.za 0 1200 300 86400 60 
associatedDomain: 168.192.in-addr.arpa 
objectClass: dNSDomain2 
objectClass: domainRelatedObject 
nSRecord: thismachine.aims.ac.za . 


My PDNS config looks like this: 

launch=ldap 
ldap-host=ldapi:/// 
ldap-method=strict 
ldap-basedn=dc=aims,dc=ac,dc=za 
ldap-filter-lookup=(&(:target:)(objectClass=dnsDomain2)) 
ldap-filter-axfr=(&(:target:)(objectClass=dnsDomain2)) 


Performing a reverse lookup such as: dig @localhost -x 192.168.42.2 
Produces a failure like this: 

; <<>> DiG 9.8.1-P1 <<>> @melrose-lan -x 192.168.42.2 
; (1 server found) 
;; global options: +cmd 
;; Got answer: 
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 861 
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 
;; WARNING: recursion requested but not available 

;; QUESTION SECTION: 
;2.42.168.192.in-addr.arpa. IN PTR 

;; Query time: 3 msec 
;; SERVER: 192.168.42.15#53(192.168.42.15) 
;; WHEN: Thu Sep 27 17:08:04 2012 
;; MSG SIZE rcvd: 43 


Running slapd in debug mode reveals the following queries being made, in this order (apologies for the verbosity): 

50646bd4 connection_get(18) 
=> ldap_bv2dn(dc=aims,dc=ac,dc=za,0) 
<= ldap_bv2dn(dc=aims,dc=ac,dc=za)=0 
=> ldap_dn2bv(272) 
<= ldap_dn2bv(dc=aims,dc=ac,dc=za)=0 
=> ldap_dn2bv(272) 
<= ldap_dn2bv(dc=aims,dc=ac,dc=za)=0 
50646bd4 SRCH "dc=aims,dc=ac,dc=za" 2 350646bd4 0 0 0 
50646bd4 filter: (&(aRecord=192.168.42.2)(objectClass=dNSDomain2)) 
50646bd4 attrs:50646bd4 associatedDomain50646bd4 dNSTTL50646bd4 modifyTimestamp50646bd4 
50646bd4 bdb_idl_fetch_key: [01872a84] 
50646bd4 bdb_idl_fetch_key: [b49d1940] 
50646bd4 bdb_idl_fetch_key: [fc094c20] 
50646bd4 bdb_idl_fetch_key: [1eb06af0] 
50646bd4 send_ldap_result: err=0 matched="" text="" 
50646bd4 connection_get(26) 
50646bd4 send_ldap_result: err=0 matched="" text="" 
50646bd4 connection_get(18) 
=> ldap_bv2dn(dc=aims,dc=ac,dc=za,0) 
<= ldap_bv2dn(dc=aims,dc=ac,dc=za)=0 
=> ldap_dn2bv(272) 
<= ldap_dn2bv(dc=aims,dc=ac,dc=za)=0 
=> ldap_dn2bv(272) 
<= ldap_dn2bv(dc=aims,dc=ac,dc=za)=0 
50646bd4 SRCH "dc=aims,dc=ac,dc=za" 2 350646bd4 0 0 0 
50646bd4 filter: (&(&(associatedDomain=42.168.192.in-addr.arpa)(sOARecord=*))(objectClass=dNSDomain2)) 
50646bd4 attrs:50646bd4 SOARecord50646bd4 dNSTTL50646bd4 modifyTimestamp50646bd4 
50646bd4 bdb_idl_fetch_key: [01872a84] 
50646bd4 bdb_idl_fetch_key: [b49d1940] 
50646bd4 connection_get(27) 
50646bd4 bdb_idl_fetch_key: [152cb869] 
50646bd4 send_ldap_result: err=0 matched="" text="" 
50646bd4 send_ldap_result: err=0 matched="" text="" 
50646bd4 connection_get(18) 
=> ldap_bv2dn(dc=aims,dc=ac,dc=za,0) 
<= ldap_bv2dn(dc=aims,dc=ac,dc=za)=0 
=> ldap_dn2bv(272) 
<= ldap_dn2bv(dc=aims,dc=ac,dc=za)=0 
=> ldap_dn2bv(272) 
<= ldap_dn2bv(dc=aims,dc=ac,dc=za)=0 
50646bd4 SRCH "dc=aims,dc=ac,dc=za" 2 350646bd4 0 0 0 
50646bd4 filter: (&(&(associatedDomain=168.192.in-addr.arpa)(sOARecord=*))(objectClass=dNSDomain2)) 
50646bd4 attrs:50646bd4 SOARecord50646bd4 dNSTTL50646bd4 modifyTimestamp50646bd4 
50646bd4 bdb_idl_fetch_key: [01872a84] 
50646bd4 bdb_idl_fetch_key: [b49d1940] 
50646bd4 bdb_idl_fetch_key: [e3d386be] 
50646bd4 bdb_idl_fetch_key: [1eb06af0] 
50646bd4 send_ldap_result: err=0 matched="" text="" 
50646bd4 connection_get(18) 
=> ldap_bv2dn(dc=aims,dc=ac,dc=za,0) 
<= ldap_bv2dn(dc=aims,dc=ac,dc=za)=0 
=> ldap_dn2bv(272) 
<= ldap_dn2bv(dc=aims,dc=ac,dc=za)=0 
=> ldap_dn2bv(272) 
<= ldap_dn2bv(dc=aims,dc=ac,dc=za)=0 
50646bd4 SRCH "dc=aims,dc=ac,dc=za" 2 350646bd4 0 0 0 
50646bd4 filter: (&(&(associatedDomain=192.in-addr.arpa)(sOARecord=*))(objectClass=dNSDomain2)) 
50646bd4 attrs:50646bd4 SOARecord50646bd4 dNSTTL50646bd4 modifyTimestamp50646bd4 
50646bd4 bdb_idl_fetch_key: [01872a84] 
50646bd4 bdb_idl_fetch_key: [b49d1940] 
50646bd4 bdb_idl_fetch_key: [4cbdcab0] 
50646bd4 send_ldap_result: err=0 matched="" text="" 
50646bd4 connection_get(18) 
=> ldap_bv2dn(dc=aims,dc=ac,dc=za,0) 
<= ldap_bv2dn(dc=aims,dc=ac,dc=za)=0 
=> ldap_dn2bv(272) 
<= ldap_dn2bv(dc=aims,dc=ac,dc=za)=0 
=> ldap_dn2bv(272) 
<= ldap_dn2bv(dc=aims,dc=ac,dc=za)=0 
50646bd4 SRCH "dc=aims,dc=ac,dc=za" 2 350646bd4 0 0 0 
50646bd4 filter: (&(&(associatedDomain=in-addr.arpa)(sOARecord=*))(objectClass=dNSDomain2)) 
50646bd4 attrs:50646bd4 SOARecord50646bd4 dNSTTL50646bd4 modifyTimestamp50646bd4 
50646bd4 bdb_idl_fetch_key: [01872a84] 
50646bd4 bdb_idl_fetch_key: [b49d1940] 
50646bd4 bdb_idl_fetch_key: [8268109f] 
50646bd4 send_ldap_result: err=0 matched="" text="" 
50646bd4 connection_get(18) 
=> ldap_bv2dn(dc=aims,dc=ac,dc=za,0) 
<= ldap_bv2dn(dc=aims,dc=ac,dc=za)=0 
=> ldap_dn2bv(272) 
<= ldap_dn2bv(dc=aims,dc=ac,dc=za)=0 
=> ldap_dn2bv(272) 
<= ldap_dn2bv(dc=aims,dc=ac,dc=za)=0 
50646bd4 SRCH "dc=aims,dc=ac,dc=za" 2 350646bd4 0 0 0 
50646bd4 filter: (&(&(associatedDomain=arpa)(sOARecord=*))(objectClass=dNSDomain2)) 
50646bd4 attrs:50646bd4 SOARecord50646bd4 dNSTTL50646bd4 modifyTimestamp50646bd4 
50646bd4 bdb_idl_fetch_key: [01872a84] 
50646bd4 bdb_idl_fetch_key: [b49d1940] 
50646bd4 bdb_idl_fetch_key: [1de355a4] 
50646bd4 send_ldap_result: err=0 matched="" text="" 
50646bd4 connection_get(18) 
=> ldap_bv2dn(dc=aims,dc=ac,dc=za,0) 
<= ldap_bv2dn(dc=aims,dc=ac,dc=za)=0 
=> ldap_dn2bv(272) 
<= ldap_dn2bv(dc=aims,dc=ac,dc=za)=0 
=> ldap_dn2bv(272) 
<= ldap_dn2bv(dc=aims,dc=ac,dc=za)=0 
50646bd4 SRCH "dc=aims,dc=ac,dc=za" 2 350646bd4 0 0 0 
50646bd4 filter: (&(&(associatedDomain=)(sOARecord=*))(objectClass=dNSDomain2)) 
50646bd4 attrs:50646bd4 SOARecord50646bd4 dNSTTL50646bd4 modifyTimestamp50646bd4 
50646bd4 bdb_idl_fetch_key: [01872a84] 
50646bd4 bdb_idl_fetch_key: [b49d1940] 
50646bd4 bdb_idl_fetch_key: [898e58f3] 
50646bd4 send_ldap_result: err=0 matched="" text="" 


I am quite stuck in trying to figure this one out. Due to the repeated queries it looks like pdns isn't finding the SOA record but when I perform the same ldapsearch manually the entries are indeed returned. Can anyone offer me some clues? 

Many thanks 
Tom Bamford 

-- 
System Administrator 
African Institute for Mathematical Sciences 
Cape Town, South Africa 
Tel: +27 (0)21 787 9328 
Fax: +27 (0)21 787 9321 
Jabber: tom at aims.ac.za 
Web: www.aims.ac.za 



_______________________________________________
Pdns-users mailing list
Pdns-users at mailman.powerdns.com
http://mailman.powerdns.com/mailman/listinfo/pdns-users




More information about the Pdns-users mailing list