[pjsg]

traceroute is a useful tool for (amongst other things) determining where a system is physically. It doesn't always give you enough information.

Traceroute to news.ycombinator.com:

  3   96.108.68.141 (po-200-xar01.maynard.ma.boston.comcast.net)  12.105ms  11.724ms  11.931ms 

  4   96.108.68.141 (po-200-xar01.maynard.ma.boston.comcast.net)  13.011ms  10.727ms  19.861ms 

  5   162.151.52.34 (be-501-ar01.needham.ma.boston.comcast.net)  13.988ms  14.721ms  12.921ms 

  6   162.151.52.34 (be-501-ar01.needham.ma.boston.comcast.net)  14.999ms  16.688ms  12.997ms 

  7   4.69.146.65 (ae0.11.bar1.SanDiego1.net.lumen.tech)  76.044ms  79.624ms  78.017ms 

  8   4.69.146.65 (ae0.11.bar1.SanDiego1.net.lumen.tech)  83.962ms  108.675ms  78.987ms 

  9   \*  \*  \*

I can conclude that the server is probably on the west coast -- maybe San Diego.

I recall using this during a sales pitch by some IP Geolocation company that were very proud of their technology. The example that they used, they claimed was in Morristown, NJ. A quick traceroute (from Massachusetts) revealed that the IP was somewhere in the UK as the last hop was close to Heathrow Airport. We did not purchase their solution!

[sneak]

This fails in a lot of different ways, not the least of which is anycast. The most common way is probably dns-based geographic steering.

Can you tell me where 8.8.8.8 is?

[toast0]

8.8.8.8 is in many places. It's hard to get a list of exactly where[1], but the more places you can traceroute from, the more places you can add to your list. For 8.8.8.8 in particular, if you've got probes in major PoPs, you can probably get response times of 1 ms or less and be pretty sure that Google has a presence there. Of course, if you get a longer response time, they may have a presence there but your network may not have their local advertisement and your query routes elsewhere; or maybe the response from Google is being routed through another location. Traceroute might help debug a longer route to Google, but it'll be hard to debug the return.

For dns steering to unicast ips, you can get a reasonable idea of where the ips you can see are, although you'll need to make dns requests from different locations to see more of the available dns answers.

[1] Unless you're an insider, or maybe Google publishes a list somewhere. Their peeringdb listing of locations is probably a good start, though.

[mrngm]

  $ dig @8.8.8.8 +nsid news.ycombinator.com.
  ; NSID: 67 70 64 6e 73 2d 61 6d 73 ("gpdns-ams")
  news.ycombinator.com. 1 IN A 209.216.230.207

Repeating the same query returned:

  ; NSID: 67 70 64 6e 73 2d 67 72 71 ("gpdns-grq")

A few other resolvers implement this as well, e.g. 1.1.1.1 and 9.9.9.9:

  1.1.1.1: ; NSID: 35 32 31 6d 32 37 34 ("521m274")
  9.9.9.9: ; NSID: 72 65 73 31 32 31 2e 61 6d 73 2e 72 72 64 6e 73 2e 70 63 68 2e 6e 65 74 ("res121.ams.rrdns.pch.net")

with, as you can see, various degrees of human-readable information on the actual replying resolver.

(more DNS resolver introspection tricks can be found with DNSDiag https://dnsdiag.org/ )

[westurner]

DNSSEC:

  delv @8.8.8.8 +dnssec news.ycombinator.com
  delv @8.8.8.8 +dnssec AAAA news.ycombinator.com

[kingforaday]

I know your question is rhetorical, but for those that might find this information useful...

https://ipinfo.io/8.8.8.8