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 <ahodg...@lists.simkin.ca> Sent: 7/19/19 9:26 AM To: pdns-users <pdns-users@mailman.powerdns.com> Subject: Re: [Pdns-users] Reverse Lookup zone subnetted On Fri, 2019-07-19 at 12:55 +0000, bryantz-p...@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
_______________________________________________ Pdns-users mailing list Pdns-users@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/pdns-users
