Re: [atlas] Reverse traceroute
Hank, On 16/04/2024 19.44, Hank Nussbacher wrote: https://pulse.internetsociety.org/blog/reverse-traceroutes-help-troubleshoot-improve-visibility-of-internets-health "Measure at least one reverse path from 39,544 Autonomous System (AS) destinations, which host 92.6% of Internet users. As a comparison, RIPE Atlas vantage points can measure from 4,344 AS destinations, representing 67.1% of the Internet user base." This particular metric feels highly-contrived... as if to highlight one specific property that their system excels at. Number of ASN doesn't mean that much really... a single vantage point at Comcast would account for 30 million customers and probably twice that many users, but not actually tell you much about the network for the vast majority of those users. It seems like the effort is targeted at operators and not end users, with the selling point is to provide a win-win situation, where operators gain useful metrics and the researchers learn about the network. This would encourage operators to run their code, and the researchers could more easily coax them to run their tool, getting these impressive numbers. (I haven't read the paper of course, because apparently the ACM is not open access and honestly I don't feel like spending $15 for access.) My understanding is that RIPE Atlas is mostly targeted at end users, not operators, so probably a bit harder to get probes placed, as it has no direct benefit for operators... and in fact could reveal details about their network and the quality of their service that they would not care to share. This is not *completely* true, as there are the RIPE Atlas Anchors, which I think are intended to run as infrastructure nodes, but mostly. Has anyone tried this and indeed found better visibility via their system? I have not. It looks less flexible than Atlas, but also nice and simple! Thanks for pointing it out. Cheers, -- Shane OpenPGP_0x3732979CF967B306.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] Using Atlas for Monitoring of Anycast DNS
Klaus and other RIPE Atlas folks, One thing that I noticed is that it is almost impossible to have enough Atlas credits to do operational monitoring of an anycast DNS setup. This is because in order to have enough credits to get timely checks you need to have many times as many probes as sites to check. This is not to say that RIPE Atlas is not a helpful and useful tool, but I think it can only be an additional source of information for your main monitoring setup. Cheers, -- Shane On 17/01/2020 17.41, Klaus Darilion wrote: Looks like a nice tool. Thanks for the hint. Klaus Am 16.01.2020 um 16:45 schrieb Stephane Bortzmeyer: On Thu, Jan 16, 2020 at 04:33:47PM +0100, Klaus Darilion wrote a message of 48 lines which said: - analyze the probe locations (ie. country, continent) Instead of analyzing it afterwards, why not directly asking probes on the place you're interested in? I often use NSID to watch anycast servers, indeed: % blaeu-resolve --requested 100 --area West --nameserver $(dig +short +nodnssec d.nic.fr A) --type SOA --nsid --displayrtt fr Nameserver 194.0.9.1 [NSID: b'dns.th2.nic.fr' nsmaster.nic.fr. hostmaster.nic.fr. 2225269298 3600 1800 360 5400] : 34 occurrences Average RTT 146 ms [NSID: b'dns.fra.nic.fr' nsmaster.nic.fr. hostmaster.nic.fr. 2225269298 3600 1800 360 5400] : 3 occurrences Average RTT 100 ms [NSID: b'dns.nyc.nic.fr' nsmaster.nic.fr. hostmaster.nic.fr. 2225269298 3600 1800 360 5400] : 35 occurrences Average RTT 56 ms [NSID: b'dns.ix1.nic.fr' nsmaster.nic.fr. hostmaster.nic.fr. 2225269298 3600 1800 360 5400] : 4 occurrences Average RTT 116 ms [TIMEOUT] : 2 occurrences Average RTT 0 ms [NSID: b'dns.mrs.nic.fr' nsmaster.nic.fr. hostmaster.nic.fr. 2225269298 3600 1800 360 5400] : 10 occurrences Average RTT 156 ms [NSID: b'dns.ams.nic.fr' nsmaster.nic.fr. hostmaster.nic.fr. 2225269298 3600 1800 360 5400] : 8 occurrences Average RTT 101 ms [NSID: b'dns.lon.nic.fr' nsmaster.nic.fr. hostmaster.nic.fr. 2225269298 3600 1800 360 5400] : 2 occurrences Average RTT 154 ms [nsmaster.nic.fr. hostmaster.nic.fr. 2225269297 3600 1800 360 5400] : 1 occurrences Average RTT 24 ms Test #23843409 done at 2020-01-16T15:43:10Z Note the wonders of BGP: only a minority of probes use the instance in New York City (the fastest one) :-( Note also that the last result comes from a transparent proxy, redirecting to a cache.
Re: [atlas] SSL Certificates for ripe anchors
Robert, On 03/09/2019 09.57, Robert Kisteleki wrote: Still no one has answered why ripe is using self signed certs for anchor when they can use let's encrypt for free... TL;DR if the community prefers it we use LE (+TLSA). This comes with the expense of some one-time and ongoing operational work. Considering that anchors don't host any sensitive information, using self-signed certs (+TLSA) was so far considered good enough. Sorry for asking this question so late in this thread, but what exactly are the certificates used for? The value of a certificate from a certificate authority is that you outsource the work of establishing a trust relationship. If you're connecting bits of networking infrastructure together, presumably one's provisioning tools can configure each component with exactly the secrets and trust needed, so self-signed certificates should be fine (or better, since the system is simpler and there is no dependency on external infrastructure). If the use case under discussion is to help RIPE anchor operators (or others) to see some status page on the anchor itself via a browser, then using a "real" certificate might make sense. Otherwise, I don't see the point. Cheers, -- Shane
Re: [atlas] Making a bunch of tests/measurements to a single destination is 'tedious'
Chris, On 24/01/2019 06.39, Christopher Morrow wrote: howdy! So, if I have a dns server somewhere and I want to make a bunch of measurements: "how does NYC see my dns?" (pick N probes near NYC) "How does DEN see my dns?" (pick N probes near DEN) "How does LHR see my dns?" (pick N probes near LHR) "how does " ...you get the idea... I'm trying to characterize my service from a 'user' perspective by large Metropolis, well within N km of that metropolis anyway :) but across ~70 or so metros, in v4 and v6 and with authoritative and non-authoritative queries with each test running for 4 days so i can see some daily cycles in traffic patterns/etc. The number of measurements is large in total, breaking up by 3-4 metropolis chunks is super tedious :( Can I request an API key (or some other thing) which can make that sort of request happen for all my measurements in one go? The thing I'm probing is very able to handle a few extra thousand queries per second.. and I'd only be hurting myself i get my estimate wrong :) I was part of a team on a hackathon a while back which needed to compute distances between points on the globe, including Atlas probes: https://github.com/shane-kerr/ripe-atlas-anycast-work I see that the openflights project has since moved to GitHub, and so you can get the IATA airport data here: https://github.com/jpatokal/openflights/blob/master/data/airports.dat I guess I should update the README.md... The repository is basically a last-point-in-time snapshot of the hackathon work, so it a bit rough. 😬 Anyway, this code is probably the closest to what you want: https://github.com/shane-kerr/ripe-atlas-anycast-work/blob/master/add-dist.py Turning the great_circle_dist() function into a filter across the set of all probes (meta-probes.json, which you can download in advance) should get you something like what you want. Note that this was all done 4 years ago according to GitHub, so maybe Atlas provides better tools for this nowadays. 😊 Cheers, -- Shane
Re: [atlas] dig +trace equivalency
All, Stephane Bortzmeyer: > On Sat, Nov 25, 2017 at 02:12:06PM +0900, > dikshie wrote > a message of 11 lines which said: > >> I use to use +trace option in dig command. >> Is there any same function equivalency in Atlas's DNS measurement tool? > > dig +trace is not very reliable, and does not work with all > resolvers. And, no, I don't think there is an equivalent for the Atlas > probes. It would require some resolver-like logic in the probe. It is in principle possible to simulate resolver-like logic without updating the probe. In fact, I worked on a team to do just that at a RIPE Atlas Hackathon a couple years ago. You can see the results on GitHub here: https://github.com/shane-kerr/ripe-atlas-shrugd This was just a hack, but the technique should be usable to do something similar to "dig +trace". Cheers, -- Shane
