0

I have PowerDNS Authoritative & Recursor running on a server in my environment. When I use this node as my a DNS Server, it responds to A record queries without any issues. However, when I attempt to perform a reverse lookup it fails. Any idea why?

Here is a screenshot of some DNS Lookups exhibiting the behavior.

Here is a screenshot depicting the A record configuration for Mars in the Forward Lookup Zone.

Here is a screenshot depicting an automatically created PTR record for Mars in the Reverse Lookup Zone.

Here is the pdns.conf file.

Here is the recursor.conf file.

EDIT: I should mention that Pi-Hole sits in front & relays requests to PowerDNS. However, if I instruct dig to perform lookups directly against PowerDNS the results are the same:

Forward:

$> dig mars.sol.milkyway @192.168.1.110

; <<>> DiG 9.10.6 <<>> mars.sol.milkyway @192.168.1.110
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19842
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;mars.sol.milkyway.     IN  A

;; ANSWER SECTION:
mars.sol.milkyway.  2812    IN  A   192.168.30.10

;; Query time: 3 msec
;; SERVER: 192.168.1.110#53(192.168.1.110)
;; WHEN: Sun Oct 06 18:35:50 PDT 2019
;; MSG SIZE  rcvd: 62

Reverse:

$> dig -x 192.168.30.10 @192.168.1.110

; <<>> DiG 9.10.6 <<>> -x 192.168.30.10 @192.168.1.110
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 32029
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;10.30.168.192.in-addr.arpa.    IN  PTR

;; AUTHORITY SECTION:
168.192.in-addr.arpa.   1687    IN  SOA localhost. root. 1 604800 86400 2419200 604800

;; Query time: 4 msec
;; SERVER: 192.168.1.110#53(192.168.1.110)
;; WHEN: Sun Oct 06 18:31:53 PDT 2019
;; MSG SIZE  rcvd: 104
TJ Zimmerman
  • 241
  • 5
  • 17
  • 1
    Is that a complete reverse zone (only PTR)? Does it have some NS records defining an authoritative server(s)? (I.e. zone should have SOA, some NS and some PTRs, not just sole PTRs.). Also it seems PowerDNS expects to have a link from 168.192.in-addr.arpa to 30.168.192.in-addr.arpa, does your server have 168.192.in-addr.arpa and the link (30 NS your.dns.server.name)? – Nikita Kipriyanov Oct 07 '19 at 05:33
  • Hi, thanks for your response. The reverse zone only contains PTR records. However, despite this I have actually solved the issue by adding each reverse zone to the `forward-zones` directive in `/etc/powerdns/recursor.con`. Non-intuitive based off the name of the directive, but it works not regardless. – TJ Zimmerman Oct 07 '19 at 18:06

1 Answers1

1

Turns out it's necessary to add a forward-zones entry for every reverse lookup zone in the /etc/powerdns/recursor.conf file.

For example, instead of

forward-zones=sol.milkyway=127.0.0.1:54

My configuration now looks like this:

forward-zones=sol.milkyway=127.0.0.1:54, 1.168.192.in-addr.arpa=127.0.0.1:54, 10.168.192.in-addr.arpa=127.0.0.1:54, 20.168.192.in-addr.arpa=127.0.0.1:54, 30.168.192.in-addr.arpa=127.0.0.1:54, 40.168.192.in-addr.arpa=127.0.0.1:54, 50.168.192.in-addr.arpa=127.0.0.1:54, 60.168.192.in-addr.arpa=127.0.0.1:54, 70.168.192.in-addr.arpa=127.0.0.1:54

EDIT: Actually, as it turns out it's not necessary to specify each individual reverse lookup zone. You can instead just include the root. For example:

forward-zones=sol.milkyway=127.0.0.1:54, 168.192.in-addr.arpa=127.0.0.1:54

EDIT2: Ah, I understand the language now. forward-zones means "Forward THESE Zones" Not "Forward Lookup Zones" How confusing

TJ Zimmerman
  • 241
  • 5
  • 17