This is used for delegation. You would need to have your web host create a CNAME record that looks very much like a traditional PTR record (i.e. 200.200.200.200.in-addr.arpa.), but points to a PTR record in Google (i.e. the name you specify in the first input). The PTR resource record at Google would then point to an A record at Google as well (i.e. the name you specify in the second input). Then when someone tries to resolve your IP address to a PTR record, through redirection it resolves to the appropriate A record hosted by Google as expected.
PTR (pointer) records map the IP address of a host to the canonical
(true) domain name for a host (address-to-name mapping). Known as
reverse DNS lookup, the IP address is written in reverse and appended
with the Address and Routing Parameter Area (arpa) top-level domain.
PTR records are used as a security device and anti-spam measure; mail
and other types of servers can do reverse DNS lookups to verify the
identities of hosts.
Usually, you will not manage PTR through Google Domains, because they
need to be set by the owner of your IP address block (generally your
ISP). Different IP block owners have different procedures for you to
request these records. Please contact your provider for more
information.
Google Domains supports PTR records that reside in the DNS zone
corresponding to the your domain, for the purposes of having your ISP
create CNAME records that delegate to us the responsibility for
reverse lookups of those specific addresses.
If your provider delegates a PTR record to you, your provider will
create a CNAME record that points to a PTR record that you manage
through Google Domains. For example, suppose your server's A record
looks like this: www A 1h 111.222.33.4
To delegate the PTR record to you, your provider must set the
following CNAME. Note that the order of the 4 numbers comprising the
IP address have been reversed:
4.33.222.111.in-addr.arpa. CNAME 1h ptr_www.example.com.
In Google Domains, you would set the following PTR record: ptr_www
PTR 1h www.example.com.
Once these records are set, requests to reverse-lookup the IP address
111.222.33.4 will first go to your provider's record for 4.33.222.111.in-addr.arpa., which redirects to your record for ptr_www.example.com., which tells the requester that 111.222.33.4
corresponds to www.example.com.
As a similar example for IPv6 addresses, if your server's AAAA record
looks like this: www AAAA 1h 202:db80:1:2:3:4:567:89ab
then its fully-specified IPv6 address is
0202:db80:0001:0002:0003:0004:0567:89ab. To obtain the CNAME record
that your provider must set, reverse this address (digit-wise,
ignoring the colons), putting dots between every digit and appending
.ip6.arpa. (including the trailing dot):
b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.8.b.d.2.0.2.0.ip6.arpa.
CNAME 1h ptr_www.example.com.
Best Answer
Yes, this is a very prevalent practice.
Well, one big reason is that if you're using any type of HA and/or automated infrastructure in Google Cloud, you'll likely be needing to create, modify, and delete DNS records programmatically as your infrastructure changes. If you use Google's DNS, this is much easier to do than to sort out how to create DNS records programmatically with the interface provided by Jimbob's DNS Emporium.
Second reason is that perhaps you trust Google (or AWS, or Azure) to provide a more highly-performing, reliable DNS service than your registrar, which is likely a belief that is founded in reality.
If you're running a small, relatively static DNS infrastructure that is unlikely to be subject to DDoS or similar, there is likely no technical benefit of any one particular DNS provider - in this case, it just comes down to personal preference.
Another point I always consider when putting together infrastructure is to avoid putting all of your eggs in one basket. Sometimes this is unavoidable, but if you have the option, don't have your domain registrar also host your DNS. Doing this does slightly increase management overhead, but it's worth it in terms of hedging against temporary loss of access to your registrar account, for instance.