They are used somewhat more broadly as a reputational signal -- a PTR record and a A/AAAA that mutually agree imply that the domain and IP are probably controlled by the same entity. That's mostly useful for email, where the domain is critical.
If the PTR exists but the value doesn't point back to the same IP, that suggests the IP owner is trying to pretend to be associated with some domain (i.e. to trick a sysadmin looking at logs), which is a pretty negative signal for any type of traffic, and I've seen web application firewalls complain about it.
Not having a PTR at all should be pretty neutral outside of email.
@sysop408 On the public internet, yes, but there is a lot of usefulness in internal networks having DNS and DHCP working together to get DHCP leases with co- termed A, AAAA, and PTR records. (Windows Server, Infoblox, Your Home Router). in-addr.arpa is the rabbit hole you (don’t) want to fall down, but I Am Not An IANA Lawyer
@flyingsaceur where I was running into an issue with PTR records was in that I had the same IP address set as the PTR record for more than one virtual host.
I had always been in the habit of setting a PTR record for everything, but recently I started seeing email get rejected from Gmail if the first result it got when it looked up a PTR didn't match the hostname of the sending server in the mail envelope.
I went through and removed all PTR records for anything that's on a shared IP and isn't functioning as a mail server. Just wondering if there could be some unintended consequences for those hosts not having a PTR.
@sysop408@flyingsaceur The better solution would be to always return only primary server name. Think is as hosts file format. First name after address is primary name, PTR points to primary name only. Aliases are other names pointing to the same hosts, but without matching PTR record. It should match not only for mail servers, but with only them it makes visible failures.
@sysop408 PS there is an unintended consequence: a lot of stuff does blocking reverse lookups on incoming connections so be on the lookout for weird lockups on the order of 1-60 seconds
@adrake in this case it was caused by a different domain being returned for the IP address. It's a shared server with multiple services on the same machine. There were a few hosts that had the same IP address as the mail server's IP. Most of the time the PTR record returned the correct hostname, but on some infrequent cases one of the alias domains was first to respond.
Add comment