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
15.223.222.221.in-addr.arpa IN PTR net223ip15.myhosting.com
But in the cname delegation method, they have something like this:
15.223.222.221.in-addr.arpa IN CNAME 15.oscar.223.222.221.oscar.com
Then you create a record in your zone like this:
15.oscar.223.222.221.oscar.com IN PTR www.oscar.com
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.
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.
Best Answer
I think there's slightly more complexity than mdpc suggests. The letter is true: only the person to whom the relevant chunk of PTR space has been delegated can manage the PTR records in that space.
In the second paragraph they have made the assumption that the current delegate is the person who is responsible for the PA IP address space. That is usually a safe assumption, because the general structure of PTR records is such that they were delegated in chunks corresponding to the
/24
IP address block they were in. But as mdpc points out, RFC 2317 introduced a mechanism for delegating subsections of those basic chunks. I have worked with organisations who have used that mechanism to get control of the PTRs for their sub-/24
netblocks. But it requires a highly clueful ISP, and a friendly and compliant one to boot; it is not, in my experience, commonly used.You can walk the DNS tree yourself to see to whom your PTR space has been delegated, it is likely to be your current ISP, and not likely to be your current DNS provider, unless those happen to be the same person. You can then contact them to request either direct insertion of PTR records, or the delegation of your subsection to you or your representative.