<div style="font-family: arial; font-size: 12px;"><div>Brian and Alan</div><div><br></div><div>Thank you for your responses. </div><div><br></div><div>Prior to pulling the record. I ran a test by adding a zone</div><div><br></div><div>zone </div><div><span style=" white-space: normal;">179.176.183.65.in-addr.arpa</span></div><div><br></div><div><span style=" white-space: normal;">record </span></div><table style=" white-space: normal;"><tbody><tr><td><div style=" white-space: nowrap;">179.176.183.65.in-addr.arpa</div></td><td>CNAME</td><td><div style=" white-space: nowrap;">179.160/27.176.183.65.in-addr.arpa</div></td></tr></tbody></table><div><br></div><div>When I dig against our powerdns server I get the expected PTR records. </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: NOERROR, id: 37836<br>;; flags: qr aa rd; QUERY: 1, ANSWER: 2, 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>;; ANSWER SECTION:<br>179.176.183.65.in-addr.arpa. 120 IN CNAME 179.160/27.176.183.65.in-addr.arpa.<br>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.<br>;; Query time: 14 msec<br>;; SERVER: 216.109.195.252#53(216.109.195.252)<br>;; WHEN: Fri Jul 19 11:34:01 EDT 2019<br>;; MSG SIZE rcvd: 113<br><br></div><div><br></div><div>I did the same for the other 11 email servers having issues, and their ip addresses. </div><div>I ran tests with emails to the three servers that were having issues, and all three stopped bouncing the emails with the reverse DNS lookups. </div><div><br></div><div>For now I am leaving in the zones until I can get to the bottom of the issue with these parties.</div><div><br></div><div>I am pulling the second ptr records as you recommend, and only hosts with A records for the PTR if that is best practice it is easy to follow. </div><div><br></div><div>I will update the list as I get more feed back on this issue from the providers involved. </div><div><br></div><div>Thank you for all your insights and input on best practices. </div><div><br></div><div>Sincerely </div><div><br></div><div>Bryant</div><div><br></div><div contenteditable="false"><div><strong>Bryant Zimmerman </strong></div><div> </div><div><strong>Sr. Systems Architect</strong></div><div><strong>Grand Dial Communications</strong>, <em>A ZK Tech Inc. Company</em></div><div><strong>616-299-5607</strong>
<em>(mobile)</em> </div><div><strong>616-855-1030</strong>
<em>Ext.</em>
<strong>2003</strong>
<em>(office)</em></div></div><div><br></div><hr id="previousmessagehr"><div><span><strong>From</strong>: Brian Candler <b.candler@pobox.com><br><strong>Sent</strong>: 7/19/19 11:05 AM<br><strong>To</strong>: bryantz-pdns@zktech.com, pdns-users <pdns-users@mailman.powerdns.com><br><strong>Subject</strong>: Re: [Pdns-users] Reverse Lookup zone subnetted</span></div><div class="moz-cite-prefix">On 19/07/2019 16:00, Brian Candler wrote:</div><blockquote cite="mid:4473b2df-f6f0-01bf-cc33-aeb1106cbdb4@pobox.com" type="cite">On 19/07/2019 15:52, <a class="moz-txt-link-abbreviated" href="mailto:bryantz-pdns@zktech.com" target="_blank">bryantz-pdns@zktech.com</a> wrote:<br><blockquote style="color: #000000;" type="cite">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.</blockquote><br>Can you provide your evidence for that assertion? Do you have packet captures?<br><br>I can't see any way they could know about your nameservers, unless they followed the in-addr.arpa delegation which ended up with your CNAME.</blockquote><p>However, the fact that you have two PTR records could certainly be confusing them. And I *would* expect them to do a forward lookup after the reverse lookup, so you'll see that arriving at your nameservers.</p><p>That is, the sequence is:</p><p>1. Remote server accepts an inbound connection from 65.183.176.179</p><p>2. They do a reverse lookup on this IP address, and get the name "mail.granddial.com" (say)</p><p>3. They do a forward lookup on this name, and get IP address 65.183.176.179</p><p>4. They check that this matches the original IP address. This is what prevents you from forging your PTR records; otherwise, you could just put in a PTR record pointing at "whitehouse.gov" for example.</p><p>5. If the forward and reverse don't match, paranoid servers will drop the connection, or mark your mail as spam.</p><p>You have a much better chance of this working if you have a *single* PTR record for that IP address. Pick whichever name you consider to be the "main" name of the mail server, and use that.</p><p>You are astill llowed to have many different forward records pointing to IP address 65.183.176.179; there's no problem with that. You just want the reverse record to point to a single name, and that name also to point to 65.183.176.179.</p><p>HTH,</p><p>Brian.</p></div>