Although it isn't clear exactly what you mean by "with our DNS Servers running in it" (they could be "running" but we don't know what services they actually provide) -- but based on the observed behavior, I suspect you are not using them as DNS resolvers and thus they are not a factor here... or if you are, they're handing off upstream queries to the VPC resolver.
If enableDnsHostnames and enableDnsSupport are enabled in the VPC, the AWS-provided DNS resolver will automatically resolve any RFC-1918 address into this format:
A private (internal) DNS hostname resolves to the private IPv4 address of the instance, and takes the form ip-private-ipv4-address.ec2.internal for the us-east-1 region, and ip-private-ipv4-address.region.compute.internal for other regions (where private.ipv4.address is the reverse lookup IP address).
http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-dns.html
The documentation refers to "the private IPv4 address of the instance," but in fact any private IP address resolves similarly -- it need not be related to an EC2 instance. It doesn't matter where that private IP address is, or whether it "is" anywhere at all, as long as the DNS query originates inside the VPC, uses the AWS resolver, and is for private (RFC-1918) IP address.
$ dig -x 192.168.1.1 # -x tells dig we want a reverse-DNS lookup
;; ANSWER SECTION:
1.1.168.192.in-addr.arpa. 40 IN PTR ip-192-168-1-1.ec2.internal.
$ dig ip-192-168-1-1.ec2.internal
;; ANSWER SECTION:
ip-192-168-1-1.ec2.internal. 19 IN A 192.168.1.1
Note that the VPC where I ran these is actually in the 10.x.x.x space. There is no 192.168.x.x anywhere in my route tables or network, yet this is an RFC-1918 address, so it works.
But why don't you see the "real" hostname?
Reverse DNS ("the name of an address") is not, by necessity of design, correlated to forward DNS ("the address of a name").
If database.example.com resolves to the A record 10.1.2.3, it is not necessarily true that 10.1.1.10 also resolves to the PTR record database.example.com. That requires two different entries, in two different DNS zones (or a DNS server that does this for you).
The forward entry is, of course, database.example.com..
The reverse entry formed from the IPv4 address with the octets reversed, 3.2.1.10.in-addr.arpa., where in-addr.arpa. is the special domain globally reserved for this purpose. The -x option to dig, above, does this rewriting for you so you don't have to say dig 1.1.168.192.in-addr.arpa PTR.
Unless the instances in your VPC are using your own DNS resolvers -- not the VPC-provided resolver -- this is standard, expected behavior. While it would be possible to "correct" it (by deploying your own DNS resolvers with authoritative data for portions of in-addr.arpa then making a change to the DHCP Option Set of the VPC so that the instances use them instead of the internal mechanism), this is ill-advised, since it introduces new points of failure -- specifically, your DNS resolvers -- into the picture, unnecessarily, making all of your EC2 instances dependent on those machines for all their DNS lookups. Of course, if you already have this, it may simply be the case that you need an x.x.in-addr-arpa zone, there, to handle the reverse resolution of the VPC address space.
But this divide between forward and reverse DNS is the explanation of what you see. ping is, deliberately, not showing you the name it used to find the address it is pinging. It's showing you the name it receives when it looks up the pointer record for the responding IP address, in order to identify that IP address.
