A bit unrelated... but I find it interesting that the same person who programmed this (csvoss on github) is also the developer of two other projects trending on HN right now.
Any reason why all CloudFlare connections bounce through TeliaSonera in Switzerland? It seems grossly inefficient to cross the Atlantic twice just to get from Massachusetts to California.
Also, MIT -> Facebook : MA, MI, Singapore, Ireland, CA?
Maxmind data is also often just wrong, updated or not. As a hosting provider with a number of IP ranges, we have to deal with submitting corrections to them, Google, ip2location, etc. all the time. Not sure why none of them seem to use very accurate methods to discern IP location.
Since you're doing a traceroute anyhow, you'd be better off analyzing the transit hops, and specifically the city codes used in the reverse DNS entries.
Slick. It also points out how inaccurate GeoIP is depending on which data source was used for that IP (eg. where the ISP is registered vs. where the endpoint may physically be).
If you're interested in using the http://ipinfo.io API for this, so you don't have to worry about keeping your database up to date and you get additional details, let me know. I'd be happy to hook you up with a free unlimited plan specifically for this site.
1.1.1.0/24 [0] is described as "Research prefix for APNIC Labs", but it is part of AS15169 [1] which is "Google Inc."
Also part of that AS are 1.0.0.0/24 [2] and 1.2.3.0/24 "APNIC Debogon Project" [3]. Wikipedia has some information about Bogon filtering [4] and there have been some publications about the Debogon Project [5].
The now assigned addresses used to be unassigned "bogon" addresses, which are now assigned. I'm not sure why it's part of the Google AS, though. Maybe only because they get to see a lot of traffic?
I've always described this as a visual, rather than text-based, traceroute. The site might benefit from keyword searching if visual traceroute was included.
Would it also be possible to add the times to each step? It would be interesting to compare the time vs reported distance. I suspect the times for some hops will be impossibly fast due to bad geo-ip lookups.
Results are not very accurate. For example, we are hosted in AWS us-west-1 (San Francisco), but because Amazon owns the IP it is routing to their HQ in Seattle Washington.
It does say on the site "Uses GeoLite data from MaxMind, March 2014."
So not only is the Maxmind data well over a year out of date it's [citation needed] likely to be the free dataset which is only a subset of the Maxmind purchasable data
All I can think of is stuff like DNS cache poisoning from forcing lookups, which shouldn't be a threat these days (and there are infinite other ways to force the server to do DNS lookups). The purpose of scripts.mit.edu involves students and faculty running old versions of WordPress and writing custom PHP to learn the language, so the threat model very much assumes that malicious people have compromised at least one unprivileged account at any given time. Hostname lookups are a drop in the bucket compared to that.
Python oneliner: https://news.ycombinator.com/item?id=10114969
Retroactive data structures: https://news.ycombinator.com/item?id=10119065
Coincidence? Or is this just a slow hour on HN and good time to get submissions on front page?