'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
Have you tried hitting an alternative DNS resolver than Google's? You might find Google are tailoring results for VM which other providers aren't willing to do.
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
I get the same addresses from 208.67.220.220 as I do from 8.8.8.8 - addresses belonging to my ISP. If I'm using OpenDNS's recursor to look Google up, that would put the query (from Google's perspective) firmly outside of my ISP network, so why am I getting addresses pointing to my ISP in that case?
Try it with a DNS server you control, which does not support client-subnet, located on the other side of the world. If Virgin is MITMing your DNS traffic, the results will be the same as you have seen with OpenDNS. If the results are different, you're probably OK.
You are hitting Virgin's GGC (Google Global Cache) servers, which return a different IP than the Google or GGC servers where your IPv6 tunnel is located. Google is messing with your DNS, not Virgin Media (and they are doing it to improve your performance).
I did not know about GGC, and that seems cool (and similar to the Netflix approach of putting content servers inside ISP networks). However, this does not explain why I get an address pointing to my ISP network when I query via OpenDNS, which is definitely outside of my ISP network and is an intermediate recursor (so, from the perspective of the nameservers for google.com, the query is not coming from a Virgin Media address range).
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.
OpenDNS uses edns-client-subnet, which passes the DNS client IP subnet (/24) with the recursion request. Google still knows you are on Virgin Media from behind OpenDNS.
Now THAT, is amazing - and perfectly explains what's going on. I operate several nameservers of my own for various domains, some owned by me, some not, and I'd not heard of that. I am happy with your answer, thanks!
I would suggest running your tests against a non-geobalanced and/or non-cdn enabled hostname (you can use the same resolvers, it doesn't matter here).
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.
Google has a POP (point-of-presence) at most ISPs, even small ones.
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).
As others have mentioned this seems entirely expected based on how Google uses DNS for load balancing and serving your query from a datacenter as close to you as possible.
17 comments
[ 2.7 ms ] story [ 57.9 ms ] thread'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
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
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.
http://www.afasterinternet.com/howitworks.htm
Does this happen to other sites?
I know here various ISPs have local caching setup for Google / Facebook / etc.
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.
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).
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.