Pdns: reverse lookups failed on pdns 3.4.7 and LDAP backend
Hello,
we've been using PowerDNS with LDAP backend for many years in company.
Recently we've updated some of our PowerDNS servers to version 3.4.7 and we've found out there is a problem with reverse DNS lookups while the configuration remains the very same as it was with 3.3.1 version which we'd use till then.
This is what happens:
PowerDNS 3.4.7 behaviour
dig -x 10.0.252.106 @<pdns_server_v3.4.7>
;; QUESTION SECTION:
;106.252.0.10.in-addr.arpa. IN PTR
in PowerDNS server log I can see:
Dec 11 14:53:27 server100 pdns[5630]: Backend reported permanent error which prevented lookup (Got non-SOA record when asking for SOA), aborting
Dec 11 14:53:27 server100 pdns[5630]: Backend error: Got non-SOA record when asking for SOA
PowerDNS 3.3.1 behaviour
dig -x 10.0.252.106 @<pdns_server_v3.3.1>
;; ANSWER SECTION:
106.252.0.10.in-addr.arpa. 86400 IN PTR server106.vm1.company.c.
this is our configuration (same on both PowerDNS servers except for local-address parameter):
module-dir=/usr/lib/pdns
socket-dir=/var/run/pdns-server
setuid=powerdns
setgid=powerdns
local-address=127.0.0.1,10.0.252.100
local-port=53
recursor=127.0.0.1:5353
launch=ldap
ldap-starttls=yes
ldap-host=ldap://10.0.252.116 ldap://10.0.252.117
ldap-basedn=ou=dns,ou=services,dc=company,dc=com
ldap-binddn=cn=dns,ou=systemusers,ou=users,dc=company,dc=com
ldap-secret=XXXX
ldap-method=strict
distributor-threads=1
master=no
slave=no
negquery-cache-ttl=0
query-cache-ttl=60
recursive-cache-ttl=10
query-logging=no
default-ttl=86400
soa-retry-default=30
version-string=anonymous
query-local-address6=
this is related part in LDAP:
dn: dc=server106,dc=vm1.company.com,ou=dns,ou=services,dc=company,dc=com
objectClass: domainRelatedObject
objectClass: dNSDomain2
associatedDomain: server106.vm1.company.com
dc: server106
aRecord: 10.0.252.106
PowerDNS server are all running on Linux (Centos 6).
PowerDNS is installed from RPMs:
Name : pdns Relocations: (not relocatable)
Version : 3.4.7 Vendor: Monshouwer Internet Diensten
Release : 1.el6.MIND Build Date: Tue 03 Nov 2015 04:20:42 PM CET
Install Date: Tue 10 Nov 2015 03:33:27 PM CET Build Host: jenkins.monshouwer.eu
Group : System Environment/Daemons Source RPM: pdns-3.4.7-1.el6.MIND.src.rpm
Size : 7717279 License: GPLv2
Signature : (none)
URL : http://www.powerdns.com/
Summary : PowerDNS is a Versatile Database Driven Nameserver
Description :
Name : pdns-server Relocations: (not relocatable)
Version : 3.3.1 Vendor: Monshouwer Internet Diensten
Release : 2.el5.MIND Build Date: Mon 20 Jan 2014 08:06:05 PM CET
Install Date: Mon 26 May 2014 10:46:02 AM CEST Build Host: repo.monshouwer.eu
Group : System Environment/Daemons Source RPM: pdns-server-3.3.1-2.el5.MIND.src.rpm
Size : 6188654 License: GPL
Signature : (none)
URL : http://www.powerdns.com/
Summary : PowerDNS is a Versatile Database Driven Nameserver
Description :
PowerDNS is a versatile nameserver which supports a large number
of different backends ranging from simple zonefiles to relational
databases and load balancing/failover algorithms.
tbrandysky
All 22 comments
Thank you for your extensive report! Do forward (A) lookups for that name work on both versions, without error?
Habbie
on 4 Jan 2016
yes, A lookups for that name work fine:
$ dig @<<pdns_server_v3.4.7> server106.vm1.company.com
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.4 <<>> @127.0.0.1 server106.vm1.company.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61997
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;server106.vm1.company.com. IN A
;; ANSWER SECTION:
server106.vm1.company.com. 86400 IN A 10.0.252.106
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Jan 4 16:47:21 2016
;; MSG SIZE rcvd: 53
$ dig @<pdns_server_v3.3.1> server106.vm1.company.com
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.4 <<>> @10.0.252.253 server106.vm1.company.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50489
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;server106.vm1.company.com. IN A
;; ANSWER SECTION:
server106.vm1.company.com. 86400 IN A 10.0.252.106
;; Query time: 8 msec
;; SERVER: 10.0.252.253#53(10.0.252.253)
;; WHEN: Mon Jan 4 16:48:54 2016
;; MSG SIZE rcvd: 53
I can confirm this difference between 3.3.1 and 3.4.7.
Habbie
on 7 Jan 2016
It looks like 3ab53ceca5c64a0b97fb85236f84e0ae8e610206 is exposing this bug in ldapbackend.
Habbie
on 7 Jan 2016
how can this be fixed please ?
tbrandysky
on 26 Jan 2016
Hello,
we are currently working on reviving the LDAP backend into fully supported status for 4.0.0. In that process, we will fix this bug and will backport the fix to 3.4. I hope to this within one or two weeks.
Habbie
on 26 Jan 2016
great news. thank you very much guys !
tbrandysky
on 26 Jan 2016
Rough fix for this in https://github.com/Habbie/pdns/tree/ldap-autoptr, if you can test it on your 3.4.8, please do and report back!
Habbie
on 21 Feb 2016
I'm afraid I have no easy way to test it in our environment. We've upgraded to 3.4.8 which apparently doesn't solve the problem without patch. Let me know whether testing in our environment is important to you I'd need to prepare some testing pool for that as normally we only install officially release RPM on our production servers. Thank you.
tbrandysky
on 22 Feb 2016
@tbrandysky testing in your environment saves me time which means the fix will end up on 3.4.x sooner, that is all. Either way I cannot promise a due date :)
Habbie
on 22 Feb 2016
I was trying to compile your version from GIT but I didn't succeeded on RHEL 6 so I'll have to wait for final release in which the patch will be included.
tbrandysky
on 22 Feb 2016
Ok, thanks for trying! Will update here when I have more news.
Habbie
on 22 Feb 2016
confirming here on FreeBSD 10.2, too. I would like to test your patch, any chance to get a diff against the vanilla 3.4.8 sources?
daudo
on 23 Feb 2016
any updates on this? I just tried to apply https://github.com/Habbie/pdns/commit/ae97c3b7d0197c5f48b1d22d200915a23928e54c to a vanilla 3.4.9 codebase, but that did not change anything.
Is there anything else I'm missing?
daudo
on 16 Jun 2016
I know you're discussing 3.4.x, but I've done a pull of PDNS master, and manually applied the changes here https://github.com/Habbie/pdns/commit/ae97c3b7d0197c5f48b1d22d200915a23928e54c
It works fine here.
Please be aware, that if you have a malformed SOA record, forward lookups do not work (i.e. mail address is in xxx.domain.tld notation, should be [email protected] as per PDNS specs)
lkarlslund
on 30 Jun 2016
Just installed PowerDNS Authoritative Server 4.0.1 and the issue is still there. Also tried to change SOA entries to be sure it is according to specs.
Am I missing something or this still wasn't fixed ?
tbrandysky
on 22 Aug 2016
We are facing the very same problem here with 4.0.1.
Is there some schedule to fix this officially?
Rosch
on 12 Oct 2016
Same for 4.0.3. But I can confirm that manually applying Habbie@ae97c3b solves the issue.
raptwa
on 18 Jan 2017
What is the reason the fix is not part of official PDNS builds please ? This bug is really annoying and is bothering us and other users of PowerDNS for more than year.
tbrandysky
on 18 Jan 2017
any updates on this please ?
tbrandysky
on 8 Aug 2017
It should be fixed in 4.1.0-RC2, can you please test?
Habbie
on 9 Nov 2017
It works in 4.1. I also needed to create a global arpa entry (associatedDomain=arpa) in LDAP containing SOARecord. It didn't work without it.
tbrandysky
on 1 Dec 2017
Related issues
schlitzered
路
6Comments
HLFH
路
4Comments
wiesl
路
8Comments
azurit
路
3Comments
jonpaulh
路
6Comments
Most helpful comment
What is the reason the fix is not part of official PDNS builds please ? This bug is really annoying and is bothering us and other users of PowerDNS for more than year.