[Pdns-users] PDNS ldapbackend issue with PTR queries in strict mode
Tom Bamford
tom at aims.ac.za
Thu Sep 27 15:15:06 UTC 2012
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.powerdns.com/pipermail/pdns-users/attachments/20120927/f3e71346/attachment.html>
More information about the Pdns-users
mailing list