On 2025/07/07 16:56, Ethan Katz-Bassett wrote:
Ray,
Thanks, it's a nice service to the community to try to clean this up.
I was about to reply that it looked like the default location, but you've been able to confirm that in the meantime.
I noticed two papers recently that did this sort of cleaning. Pointing them out in case it's helpful: 1. https://hal.science/hal-04215113v2/file/geolocation-reproducibility- paper.pdf <https://hal.science/hal-04215113v2/file/geolocation- reproducibility-paper.pdf> In Section 4.3, this paper identifies RIPE Atlas probes that (based on the claimed location) led to pings violating the speed of light, in order to prune the ones they use to be more trustworthy. They flagged 9 anchors and 96 normal probes.
I've been looking at both latency, and the hostname.bind responses that come from the DNS root servers. In many cases I'm seeing speed-of-light violations, and can then trace down the likely location using the well known hostname.bind responses (I run F-root). I've seen a few with just speed-of-light violations, but where the routing is not too odd, such as a probe in Tirana with an alleged 4.1ms DNS response latency all the way to Amsterdam. I've been detecting these using my DNS Root System Visualiser and then eyeballing for outliers within the catchment of each F-root node that have far lower latency than closer probes.
2. This paper looked specifically at the question of RIPE Atlas geolocations: https://arxiv.org/abs/2409.19109 <https://arxiv.org/abs/2409.19109> They shared results on violating probes here (the paper also has a link for the measurements), and it looks like it was updated as recently as last week https://github.com/kizhikevich/violating_ripe_probes <https:// github.com/kizhikevich/violating_ripe_probes>
Oh, lovely! Looking at their latest file, I see two there so far that already got fixed in the last hour because I raised disputes on them :)
I'll also forward your thread to some of the authors of both papers, in case they have more to add.
thanks! Ray