Short Answer
Do the standards governing DNS operation require that all devices have a matching PTR record? No.
Do the standards for certain protocols require PTR records that agree with corresponding A or AAAA records? Yes.
Do some applications not governed by a RFC have the same requirements? Yes.
Can a PTR record point at a CNAME? Yes, but the CNAME target must must be the unique name of the device in question (and not another CNAME). ( RFC 2181§10.2 , RFC1034 §3.6.2 )
Is mandatory PTR record creation a best practice? Commonly believed so, but it has its own problems.
Long Answer
This Q&A is provided with the intent of helping to put to rest a common misunderstanding.
A tragically underquoted section of RFC1796 applies here:
It is a regrettably well spread misconception that publication as an RFC provides some level of recognition. It does not, or at least not any more than the publication in a regular journal. In fact, each RFC has a status, relative to its relation with the Internet standardization process: Informational, Experimental, or Standards Track (Proposed Standard, Draft Standard, Internet Standard), or Historic.
RFC1912 is Informational. RFC1033 is not clearly labeled and has an official designation of UNKNOWN, which means it's so old that it should not be considered a reference for anything. They do not define Standards, nor can they be used to officially augment a standard. They should never be quoted in the context that implies that they are defining a standard.
Think of Informational RFC suggestions as good advice and commonly accepted best practice. The reverse DNS recommendations make sense at a glance: following these guidelines lower your risk of being put into situations where an application fails to work because reverse DNS was necessary and not planned for. You certainly can't expect a DNS admin to know every application/protocol that requires it, and sadly the same tends to be true of the service owners requesting those records.
That said, outside of very good automation, mandatory PTR record creation policies also create pollution.
- It's extremely commonplace for
PTR records to not be kept in sync with their corresponding A/AAAA records as devices are decommissioned, resulting in a creep of bogus PTR data over time. This data only serves to mislead those who attempt to treat that information as credible. Some application owners are eager to jump on it when they're hunting for the cause of a phantom problem. The problem will only continue to get worse as IPv6 adoption becomes more commonplace, particularly for DNS admins responsible for carrier sized IP space.
- Having multiple PTR records for the same IP address is pretty useless, and adhering to the advice of the Informational RFCs will inevitably result in this. See: Why multiple PTR records in DNS is not recommended?
What is worse: absence of a PTR record, or an inaccurate PTR record? If a protocol breaks because its standard requires valid DNS, both are bad, and the latter could actually be worse. Outside of that, everyone has a different opinion on the matter. That's fine: you are free to put together the policies and tools that work best for your team and company. Just make sure that they scale and yield consistent results, and remember that reverse DNS will only be as accurate as the time and discipline your team members have to give it.
But missing PTR records cause sshd to hang!
Also not true. People often confuse the line between absence of a PTR record (NXDOMAIN), and broken reverse DNS.
A reply of NXDOMAIN will only cause a problem if you are communicating with a service that requires forward confirmed reverse DNS (FCrDNS). Mail servers, Kerberos, Oracle scan VIPs, etc.
Broken reverse DNS is when it's impossible for you to get a NXDOMAIN response in a timely fashion. Many applications (most famously sshd) will block on the reverse DNS lookup if there are problems acquiring a response from upstream sources in a timely fashion, causing delays within the application.
Best Answer
This is common if you have a small subnet delegated from your ISP. It's called RFC 2317 delegation or something like that.
Many ISPs will have you create a PTR record, under your domain (i.e. oscar.com which you have control over), and put a CNAME in their reverse zone (i.e. 0.168.192.in-addr.arpa which the ISP has control over).
For example, for an IP address of 221.222.223.15, the reverse record would be 15.223.222.221.in-addr.arpa. A reverse lookup would look for that record from the owner of the IP address (in your case, myhosting.com or their parent ISP).
The ISP would normally have a record like
But in the cname delegation method, they have something like this:
Then you create a record in your zone like this:
Then folks will look up 221.222.223.15 and follow the CNAME from 15.223.222.221.in-addr.arpa to 15.oscar.223.222.221.oscar.com to www.oscar.com.
I've never had this done for a single IP, but I've had several ISPs do something like this for routed subnets.
Check with myhosting.com to see if they have a preference or specification for the record. But I think this is the general story behind the delegation.