- ripe-atlas - mailman.ripe.net

DNS measurement for newer record types - HTTPS & SVCB & more
by Petr Špaček 06 May '26

06 May '26

Hello! Would it be possible to add newer record types to allowed set of "query_type" parameter values for DNS measurements? Specifically I would like to use "HTTPS" and "SVCB" record types, RFC 9460, published in November 2023. On a more generic note: The filter already allows four RR types with weird corner cases - namely NS, DS, ANY, RRSIG. Based on that I think if anything wanted to explode because of RIPE Atlas DNS queries it already did. If you are open to adding more types, I think adding all standardized values from https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-pa… would be very safe and would expand utility for deployment testing of existing protocols. Even better would be to just take integer value. That's what all DNS software does - see RFC 3597 - published in 2003. With integer value we could even use RIPE Atlas for IETF work in the DNS WGs. Thank you for considering the three options above. -- Petr Špaček Internet Systems Consortium

1 0

[Probes used in measurement]
by SIPASSEUTH Adrien 05 May '26

05 May '26

Hello, I want to supervise health from my measurement with https://atlas.ripe.net/docs/apis/rest-api-manual/measurements/status-checks/ But there are all probes result even probes in "NOT parcipating" status. It is possible to removed probes in stats "NOT particpating" from a measurement ? [cid:dc3f3b43-9c0c-4082-a473-f74b19398a2d] I can't find a endpoint which remove this probes from my measruement. Regards, Adrien

2 1

Rollout of software probe anti farming measures
by Francesco Iannuzzelli 30 Apr '26

30 Apr '26

Dear RIPE Atlas users, Some of you may remember earlier discussions about this topic. We’re now ready to enable a feature to address this issue. Supporting each probe requires resources from the system; at the same time having too many probes in the same network and location does not provide much new information (that is, more probes in the same location or network would provide similar measurement results). Therefore we have controls in place to limit the amount of /software/ probes that are connecting from particular networks: 1. Each probe host can connect up to 2 software probes from the same IP address. 2. Each probe host can connect up to 4 software probes from the same IP prefix (as seen in BGP). 3. At most 32 (or 64) probes from the same IPv4 (or IPv6) prefix (as seen in BGP), regardless of the host. Software probes that connect from networks beyond these limits will not be allowed to connect, unless and until other software probes drop out. Note that we may also adjust the particular maximums over time. We realise that in some cases multiple probes belonging to the same user can come seemingly from the same network, violating rule 2 (mostly), yet they arguably still provide enough value for the community. This may be for example because they are in fact geographically widely distributed. In such a case the host can reach out to us via atlas(a)ripe.net with an explanation and we will consider relaxing this limit. While in the past we observed surprising corner cases, the particular limits described above are set partially taking into account the current software deployment. Therefore only a handful of probe hosts should be impacted by this (as I write this, 71 probes from 13 hosts). As I mentioned above, we’re open to adjust the limits if needed. Regards, Francesco Iannuzzelli

2 2

Atlas UI updates for 2026-04-29
by Stephen Suess 29 Apr '26

29 Apr '26

Hello Atlas fans, We have just updated the UI with a new fullscreen view for the Region Meshes use case, as well as some under the hood changes related to the system used to log in to Atlas. In addition, we are deprecating TraceMon (in favour of Khipu) and will be removing it from Atlas after the upcoming RIPE meeting. If there is functionality that you use in TraceMon that is not available to you elsewhere within Atlas, please let us know and we will evaluate. Kind regards, Stephen Atlas UI

1 0

Requesting Credits for research
by Anugya Sharma 25 Apr '26

25 Apr '26

Hello, I am a grad student at UC Davis. I am trying to research starlink satellite users in developing countries and if their traffic is unnecessarily routed through the US. I am measuring traceroute, DNS, ping and have identified Starlink-connected RIPE Atlas probes (AS14593) in Kiribati, the Marshall Islands, Madagascar, and Guam. I would be so thankful for any credits you can provide so that I can get my measurements going. -Anugya Sharma Department of computer science, UC,Davis

4 3

RIPE Atlas: From Core Concepts to Use Cases (upcoming RIPE NCC Open House Event)
by Stephen Suess 24 Apr '26

24 Apr '26

Hi everyone, We would like to invite you to a two-part RIPE NCC Open House event on RIPE Atlas, with a particular focus on the UI. I will be giving demos and talking about numerous tools and visualisations that are available to help you understand and make sense of Atlas data. Session 1 takes place Thursday, 30 April at 13:00 (UTC+2) Session 2 takes place Tuesday, 12 May at 13:00 (UTC+2) Full details and registration: https://www.ripe.net/meetings/open-house/ripe-atlas-from-core-concepts-to-u… We look forward to seeing you there! Kind regards, Stephen Atlas UI

1 0

Atlas UI updates 2026-04-15
by Stephen Suess 15 Apr '26

15 Apr '26

Hello Atlas friends, We have just released an update to the Atlas frontend. The most notable new feature is the Region Meshes use case, which is a new RIPE Atlas tool that visualises intra-region routing paths, showing where traffic stays local, where it leaves, and how IXPs are being used. You can read about it here: https://labs.ripe.net/author/stephen_suess_1/introducing-region-meshes-visu… And you can link directly to the tool here: https://atlas.ripe.net/use-cases/region-meshes/ Additionally, you can see the full list of what has changed or been fixed in the release notes: https://atlas.ripe.net/docs/releases/website_index/2026-04-15 As always, we welcome your feedback and would love to know what you think. Kind regards, Stephen Atlas UI

1 0

Atlas ping measurement with include_probe_id
by Yi Zhou 07 Apr '26

07 Apr '26

Hi All, I’m having issues with how the payload of a ping measurement is constructed. In a recent experiment, I found that not all probes correctly embed the probe ID into the payload. For example, the following payload is a correct example. [4, 255, 0, 1, 0, 25, 253, 117, 26, 85, 207, 174, 0, 0, 0, 0, 192, 94, 125, 241, 173, 37, 232, 44, 82, 73, 80, 69, 32, 65, 116, 108, 97, 115, 32, 112, 114, 111, 98, 101, 32, 49, 48, 50, 50, 49, 0, 0, 0, 0, 0, 0] Includes “[82, 73, 80, 69, 32, 65, 116, 108, 97, 115, 32, 112, 114, 111, 98, 101, 32]” as the ASCII of “RIPE Atlas probe ”, and “[32, 49, 48, 50, 50, 49]” as probe ID “10221” However, in a randomized sample of 50 probes, 34 of them do not have the probe ID following “RIPE Atlas probe" [82, 0, 0, 1, 113, 214, 8, 0, 0, 0, 0, 0, 129, 197, 72, 49, 0, 0, 0, 0, 0, 0, 0, 0, 171, 144, 68, 164, 87, 28, 143, 103, 0, 0, 0, 0, 82, 73, 80, 69, 32, 65, 116, 108, 97, 115, 32, 112, 114, 111, 98, 101] While considering the chance that older firmware versions do not recognize the configuration option, I disabled the ‘include_probe_id’ option. None of the payloads in this experiment includes the “RIPE Atlas probe” part. Does anyone have experience with this issue? I do notice that there are about 8 bytes shared between packets from the same probe and the same measurement, but it seems more like a randomized identifier. Thanks, Yi

1 0

Request for RIPE Atlas credits - CS student at ETH Zürich
by Nikolas Kühnlein 30 Mar '26

30 Mar '26

Hi all, My name is Nikolas Kühnlein and I am a computer science student at ETH Zürich, currently taking a course on computer networks. As part of my studies I have been exploring traceroute analysis and IP geolocation using latency triangulation — specifically trying to verify the physical location of intermediate hops using RTT measurements from distributed vantage points, rather than relying on WHOIS or commercial geolocation databases. I recently discovered RIPE IPmap and was impressed by how accurately it placed a Google border router in Zürich (contradicting a WHOIS record pointing to Mountain View, CA). I would like to run my own ping measurements from European probes to a small set of hop IPs from my traceroutes, to understand the triangulation method hands-on. As a new user I have no credits, and I am looking for a small donation to get started — a few million credits would be more than enough for what I have in mind. My RIPE Atlas account is registered under: nikshop(a)takuu.de I am happy to share my findings with the community. Thank you in advance for any help. Best regards, Nikolas Kühnlein ETH Zürich

5 5

CfP: Workshop on Negative results in Network measurements (NetNet)
by Alexandrina Ioana Livadariu 26 Mar '26

26 Mar '26

Hello all, We are organizing a workshop on Negative results in Network measurements (NetNet) this year. The workshop is part of ACM SIGCOMM’26 and will take place in Denver, Colorado, USA. The workshop invites submissions that report and reflect negative results in network measurement studies. The main goal is to foster a constructive discussion on lessons learned from studies in which methods, datasets or experimental designs did not yield the expected results. Submissions should focus on fundamental issues related to measurement approaches, methodology, and underlying assumptions, rather than on non-fundamental issues such as implementation bugs or misconfigurations. Focusing on the critical parts of the experiment, the workshop aims to strengthen rigor, promote transparency and improve methodology practices in network measurement research. We are planning to open the workshop for short papers (two and six pages) focusing on one problem where the authors dealt with negative results. Submissions must be original, unpublished work, and not under consideration at another conference or journal. Important dates: Submission deadline: May 1, 2026 (AoE) Acceptance deadline: June 5, 2026 Camera ready: June 20, 2026 Workshop date: August 17, 2026 (co-located with ACM SIGCOMM’26) Submission: https://netneg26.hotcrp.com/ Full Call for Papers: https://conferences.sigcomm.org/sigcomm/2026/netneg/ We look forward to your submissions and participation! Best regards, Ioana Livadariu & Mattijs Jonker

1 0