My DNS queries are being intercepted and altered in-flight
paste.debian.net
paste.debian.net
EDIT: And from the GGC documentation, it does not seem as if the ISPs are required to serve content from the in-ISP nodes to customers outside the ISP, which is what this would look like.
There was a whole time, when pinging google.com would return xxx.static.my-isp.tld as rDNS.
# dig @2001:4860:4860::8888 +short A google.com. | head -n1
85.234.204.236
# dig @8.8.8.8 +short A google.com. | head -n1
74.125.136.102
The first IP, if you whois it, belongs to my ISP, the 2nd IP belongs to Google.
These POP servers are one to several Dell servers located in your ISPs network, who then redirect traffic to other Google servers. These servers usually also have some caching (ie popular YouTube videos are cached there).
Google most likely has a cache cluster within VM's core and their DNS send you there when you're resolving from VM's network (ipv4 case). When attempting to resolve over ipv6, you're not using VM's ip space but that of your tunnel provider. In this case, google's geo dns are likely to send you to another cluster closer to that provider.
Does this happen to other sites?
I know here various ISPs have local caching setup for Google / Facebook / etc.
If you want to see some details of how it works have a look at https://www.youtube.com/watch?v=DWpBNm6lBU4 .
Disclaimer: I work for Google. I speak for myself etc. blah.
I get the same results on a BT Infinity connection, querying 208.67.222.222 or 8.8.8.8 return a 31.55.167.180 address or similar and querying my local router which uses BT's DNS returns a Google IP 74.125.230.238
'dig @8.8.8.8 +short A google.com' gives addresses in the 213.104.143.84-123 range. (actually appears in the 67-123 range)
This isn't indicative of VM fiddling with DNS, just that there's some Google servers in VM's infrastructure. It's a common. In fact the addresses google spits out for google.com varies on your location, ISP etc. This is to redirect you to their closest endpoints, content delivery networks work in a similar way.
Why does your IPV6 based query show differently? It's because of where your IPV6 tunnel is located.
Looking from elsewhere in the uk I get 74.125.230.128-137,142