I am aware that apex records (records at the zone "root") can have PTR records, but frequently I see that zone root records do not have a matching PTR, or they are pointing to a different place than the associated host record.
Example:
dig umich.edu @8.8.8.8; dig -x 141.211.243.251
(truncated for brevity)
;; ANSWER SECTION:
umich.edu. 709 IN A 141.211.243.251
(truncated for brevity)
;; ANSWER SECTION:
251.243.211.141.in-addr.arpa. 1800 IN PTR www.umich.edu.
(truncated for brevity)
Reasons not to have a PTR:
- A reason not to put in a PTR is if you are not authoritative for the address zones anyway. E.g. I am making an A record point to a cloud provider, and I cannot use a CNAME because it is a zone root.
- Another reason I could understand is if you are using anycast for your DNS services, and may not get the same answer (geographic) place-to-place. Google.com seems to do this.
But is there a reason one should "never" or "always" do this aside from an exception like the above? I would think there should always be a correct PTR by default.
I see Michael's point as I think he's referring to the domains in the namespace for handling reverse mapping:
in-addr.arpa
andip6.arpa
. That said, I understand what you're getting at.The reverse DNS (rDNS) lookup of a domain doesn't have to match the forward lookup. I have a domain on shared hosting. I get the same IP address from a forward lookup of my domain name and
www
. An RDNS lookup of this IP address returns the shared server:23.168.192.in-addr.arpa. 14400 IN PTR foo.bar.example.com.
Since you're looking for best practices, take a look at the IETF's draft Considerations for the use of DNS Reverse Mapping. It's worth reading the whole document. Here's a particularly important point:
And this:
I hope this helps.