<div style="font-family: arial; font-size: 12px;"><div style=" white-space: normal;">Alan</div><div style=" white-space: normal;"><br></div><div style=" white-space: normal;">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. </div><div style=" white-space: normal;"><br></div><div style=" white-space: normal;">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. </div><div style=" white-space: normal;"><br></div><div style=" white-space: normal;">Or maybe we should modify how we are running things. </div><div style=" white-space: normal;"><br></div><div style=" white-space: normal;">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. </div><div style=" white-space: normal;"><br></div><div style=" white-space: normal;">Any thoughts are appreciated. </div><div style=" white-space: normal;"><br></div><div style=" white-space: normal;">(Alan apologizes for the other direct e-mail reply. I am still getting used to way this mailing list works.)</div><div style=" white-space: normal;"><br></div><div style=" white-space: normal;">Thanks</div><div><br></div><div contenteditable="false"></div><div><br></div><hr id="previousmessagehr"><div><span><strong>From</strong>: Alan Hodgson <ahodgson@lists.simkin.ca><br><strong>Sent</strong>: 7/19/19 9:26 AM<br><strong>To</strong>: pdns-users <pdns-users@mailman.powerdns.com><br><strong>Subject</strong>: Re: [Pdns-users] Reverse Lookup zone subnetted</span></div><div>On Fri, 2019-07-19 at 12:55 +0000, bryantz-pdns@zktech.com wrote:</div><blockquote style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex;" type="cite"><div style="font-family: arial; font-size: 12px;"><div><br></div><div>If we do the following dig against our dns server we get a failure... </div><div><br></div><div> dig -x 65.183.176.179 @ns1.granddial.net<br>; <<>> DiG 9.9.4-rpz2.13269.14-P2 <<>> -x 65.183.176.179 @ns1.granddial.net<br>;; global options: +cmd<br>;; Got answer:<br>;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 30112<br>;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1<br>;; WARNING: recursion requested but not available<br>;; OPT PSEUDOSECTION:<br>; EDNS: version: 0, flags:; udp: 1680<br>;; QUESTION SECTION:<br>;179.176.183.65.in-addr.arpa.   IN      PTR<br>;; Query time: 24 msec<br>;; SERVER: 216.109.195.252#53(216.109.195.252)<br>;; WHEN: Fri Jul 19 08:49:21 EDT 2019<br>;; MSG SIZE  rcvd: 56<br><br></div></div></blockquote><div><br></div><div><br></div><div>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 <span style="font-family: monospace;">dig @ns1.granddial.net ptr 179.160/27.176.183.65.in-addr.arpa returns the correct PTR.</span></div><div><span style="font-family: monospace;"><br></span></div><div><span style="font-family: monospace;">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).</span></div><div><span style="font-family: monospace;"><br></span></div><blockquote style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex;" type="cite"><div><span style="font-family:monospace;"><span style="color:#000000;background-color:#ffffff;">dig @ns1.granddial.net ptr 179.160/27.176.183.65.in-addr.arpa </span></span></div><div>; <<>> DiG 9.12.3-P4 <<>> @ns1.granddial.net ptr 179.160/27.176.183.65.in-addr.arpa</div><div>; (1 server found)</div><div>;; global options: +cmd</div><div>;; Got answer:</div><div>;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12892</div><div>;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1</div><div>;; WARNING: recursion requested but not available</div><div>;; OPT PSEUDOSECTION:</div><div>; EDNS: version: 0, flags:; udp: 1680</div><div>;; QUESTION SECTION:</div><div>;179.160/27.176.183.65.in-addr.arpa. IN PTR</div><div>;; ANSWER SECTION:</div><div>179.160/27.176.183.65.in-addr.arpa. 120 IN PTR  mail.granddial.net.</div><div>179.160/27.176.183.65.in-addr.arpa. 120 IN PTR  mail.granddial.com.</div><div>;; Query time: 64 msec</div><div>;; SERVER: 216.109.195.252#53(216.109.195.252)</div><div>;; WHEN: Fri Jul 19 06:17:23 PDT 2019</div><div>;; MSG SIZE  rcvd: 127</div></blockquote><div><br></div></div>