Reverse dns not propagated

or are they stoerd in separate zones?

Separate zones, one per old C network (last byte in the octet).

What stops me from adding a PTR record saying that resolves to say gmail.com?

Nothing. But as this is not used exceptt for nice pings or some email validity checks, you achieved nothing. people will still go to gmail when they type in gmail.com. All people now see is gmail.com in a traceroute, nothing else.

The one real use for this is smtp - the HELO string given in SMTP should match the PTR record name given. Basically the server must say it is who the ptr record says it is. Note that it can still accept emails for other domains.

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.