Can an Incorrect Reverse DNS Entry Confuse Asterisk?

I know the title is super non-technical, but here’s the techincal:

Asterisk 11 (FreePBX Distro) is on public IP in a datacenter.

We had an install at public IP where SIP would not register, or remain registered. The phones would register after restarting modem and router, and then when Asterisk sends the qualify message back, it wouldn’t reach the router and then declares them as UNREACHABLE.

In doing more research and when running tcpdump -i eth0 -s0 -t udp and port 5060 and host I find the packets looking more or less like this. But there were hundreds of OPTIONS messages being sent from the PBX to the customer IP. > > > > > > > > > > > > > >

Except when I run an nslookup for (reverse dns or PTR lookup of public IP, I find that is pointing to ip In other words, whoever had contacted the ISP previously who controlled this IP they had created a PTR record pointing to an IP that isn’t this IP address, and not even at this ISP.

The reason I ask the question in the title above:

We contacted the ISP to change the static IP address to something completely different. We did nothing to change the router or Asterisk SIP PBX. After changing the ACL settings for each extension to the new IP address all extensions register without an issue and work properly. Now when I monitor SIP between Asterisk and this location, I do not see a flood of OPTIONS messages being sent.

So does Asterisk do anything at all to try to send OPTIONS, NOTIFY, and SUBSCRIBE messages to the rDNS or PTR record as opposed to the IP address where it came from?