[Pdns-users] Reverse Lookup zone subnetted

[bryantz-pdns at zktech.com]

Alan

Where we are getting into issues is that customers we host e-mail servers for are having issues as some email service providers appear to be forcing their reverse lookups directly against our powerdns servers.  I don't know why they are doing this, but we get complaints that because we only host the fake reverse lookup to handle the forward from our upstream data center. These servers think there is no reverse lookup. 

Did we make a mistake with using powerdns where it does not support recursive queries. We thought this would be great for security and performance, but now it looks like it is biting us as we can't pass the query to our upstream to get passed back. 

Or maybe we should modify how we are running things. 

I  want to reiterate other than this issue everything else shows we are getting far better performance out of our powerDNS servers over our old bind servers. So I really need to get the best solution for this. 

Any thoughts are appreciated. 

(Alan apologizes for the other direct e-mail reply. I am still getting used to way this mailing list works.)

Thanks

----------------------------------------
From: Alan Hodgson <ahodgson at lists.simkin.ca>
Sent: 7/19/19 9:26 AM
To: pdns-users <pdns-users at mailman.powerdns.com>
Subject: Re: [Pdns-users] Reverse Lookup zone subnetted
On Fri, 2019-07-19 at 12:55 +0000, bryantz-pdns at zktech.com wrote:

If we do the following dig against our dns server we get a failure... 

 dig -x 65.183.176.179 @ns1.granddial.net
; <<>> DiG 9.9.4-rpz2.13269.14-P2 <<>> -x 65.183.176.179 @ns1.granddial.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 30112
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1680
;; QUESTION SECTION:
;179.176.183.65.in-addr.arpa.   IN      PTR
;; Query time: 24 msec
;; SERVER: 216.109.195.252#53(216.109.195.252)
;; WHEN: Fri Jul 19 08:49:21 EDT 2019
;; MSG SIZE  rcvd: 56

Your server isn't supposed to serve the standard PTR. The PTR zone is actually still served by your provider. What they serve is a CNAME that points to the fake name on your server and they delegate a small fake zone to you to manage it. All you need to make sure is that dig @ns1.granddial.net ptr 179.160/27.176.183.65.in-addr.arpa returns the correct PTR.

It looks like it's mostly setup right from here, except that you're currently returning multiple PTR records, which is unlikely to work as expected (yes I know it's technically allowed).

dig @ns1.granddial.net ptr 179.160/27.176.183.65.in-addr.arpa 
; <<>> DiG 9.12.3-P4 <<>> @ns1.granddial.net ptr 179.160/27.176.183.65.in-addr.arpa
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12892
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1680
;; QUESTION SECTION:
;179.160/27.176.183.65.in-addr.arpa. IN PTR
;; ANSWER SECTION:
179.160/27.176.183.65.in-addr.arpa. 120 IN PTR  mail.granddial.net.
179.160/27.176.183.65.in-addr.arpa. 120 IN PTR  mail.granddial.com.
;; Query time: 64 msec
;; SERVER: 216.109.195.252#53(216.109.195.252)
;; WHEN: Fri Jul 19 06:17:23 PDT 2019
;; MSG SIZE  rcvd: 127


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.powerdns.com/pipermail/pdns-users/attachments/20190719/a72797b3/attachment-0001.html>