[Pdns-users] Reverse Lookup zone subnetted

[bryantz-pdns at zktech.com]

Brian and Alan

Thank you for your responses. 

Prior to pulling the record. I ran a test by adding a zone

zone 
179.176.183.65.in-addr.arpa

record 

179.176.183.65.in-addr.arpa
	 CNAME	 179.160/27.176.183.65.in-addr.arpa

When I dig against our powerdns server I get the expected PTR records. 

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: NOERROR, id: 37836
;; 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.176.183.65.in-addr.arpa.   IN      PTR
;; ANSWER SECTION:
179.176.183.65.in-addr.arpa. 120 IN     CNAME   179.160/27.176.183.65.in-addr.arpa.
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: 14 msec
;; SERVER: 216.109.195.252#53(216.109.195.252)
;; WHEN: Fri Jul 19 11:34:01 EDT 2019
;; MSG SIZE  rcvd: 113

I did the same for the other 11 email servers having issues, and their ip addresses. 
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. 

For now I am leaving in the zones until I can get to the bottom of the issue with these parties.

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. 

I will update the list as I get more feed back on this issue from the providers involved. 

Thank you for all your insights and input on best practices. 

Sincerely 

Bryant

Bryant Zimmerman 
 
Sr. Systems Architect
Grand Dial Communications, A ZK Tech Inc. Company
616-299-5607 (mobile) 
616-855-1030 Ext. 2003 (office)

----------------------------------------
From: Brian Candler <b.candler at pobox.com>
Sent: 7/19/19 11:05 AM
To: bryantz-pdns at zktech.com, pdns-users <pdns-users at mailman.powerdns.com>
Subject: Re: [Pdns-users] Reverse Lookup zone subnetted
On 19/07/2019 16:00, Brian Candler wrote:
On 19/07/2019 15:52, bryantz-pdns at zktech.com wrote:
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.
Can you provide your evidence for that assertion?  Do you have packet captures?

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.

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.

That is, the sequence is:

1. Remote server accepts an inbound connection from 65.183.176.179

2. They do a reverse lookup on this IP address, and get the name "mail.granddial.com" (say)

3. They do a forward lookup on this name, and get IP address 65.183.176.179

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.

5. If the forward and reverse don't match, paranoid servers will drop the connection, or mark your mail as spam.

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.

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.

HTH,

Brian.

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