All IP Addresses Are Equal? "dot-zero" Addresses Are Less Equal
In theory, all IP addresses are the same, and you can allocate them at random without a problem. 192.168.1.2 is certainly not better or worse than 192.168.1.15, right? But, in practice, certain IP addresses are regarded as "special" by some implementations and do not yield the same user experience.…
The first package is for Gentoo :-) https://www.swordarmor.fr/ebuild-pour-la-suite-de-tests-blaeu-pour-les-sondes-ripe-atlas.html
“Looks useful, thanks for sharing this! Can you briefly comment on what features this tool offers that are not in the official command line client?”
I started its development long before the "official" CLI program existed. After that, it's a matter of choice. Can you now display aggregated results with the "official" client? Last time I tried it, it was weak on that, displaying results probe per probe.
For Orange (AS 3215), it does not seem solved yet. A lot of timeouts: % blaeu-resolve -r 1000 --as 3215 --nameserver 188.8.131.52 --type AAAA --displayvalidation www.bortzmeyer.org Nameserver 184.108.40.206 [ (Authentic Data flag) 2001:4b98:dc0:41:216:3eff:fe27:3d3f 2605:4500:2:245b::42] : 129 occurrences [TIMEOUT(S)] : 84 occurrences [2001:4b98:dc0:41:216:3eff:fe27:3d3f 2605:4500:2:245b::42] : 1 occurrences Test #12196625 done at 2018-04-17T12:38:13Z
The tools presented here have been superseded by Blaeu, available at https://framagit.org/bortzmeyer/blaeu and documented at https://labs.ripe.net/Members/stephane_bortzmeyer/creating-ripe-atlas-one-off-measurements-with-blaeu
It seems a very good and useful feature. But calling it "tags" is a bad idea since it already means something else for RIPE Atlas :-(
The link to "RIPE Atlas API v2 manual" goes to atlas-ui-dev.atlas.ripe.net, which times out. (It is probably an internal site.)
@emileaben Rather than standardizing human-readable output format, why not emitting a standard structured format, separating the network part (traceroute) and the visualisation part (a tool using the structured output format). Such a format already exists, in RFC 5388. I let you do the same in JSON :-)
Nice tool, thanks, I recommend it. But a bit rough in both usage (documentation could be improved) and in high-level explanations.
Another reference which may be useful is the paper "Ethical issues in research using datasets of illicit origin" by Daniel R. Thomas, Sergio Pastrana, Alice Hutchings , Richard Clayton and Alastair R. Beresford https://dl.acm.org/citation.cfm?id=3131389 (PDF in https://www.cl.cam.ac.uk/~drt24/papers/2017-ethical-issues.pdf or on Sci-Hub) It is mostly about leaked datasets (such as the Patreon database) but it talks also about active network measurements (such as the Carna scan).
“Thanks Stéphane for your feedback. I refer to TTL violations as in  , which is when a resolver " overrides the TTL value" . In regardless if is increased or decreases; just different from what the authoritative returns. So in this context , violation is not protocol violation, is the violation or changing the original TTL value provided by the authoritative. thanks, /gio  https://dl.acm.org/citation.cfm?doid=3143361.3143375”
I still disagree with the term: first, a resolver does not always talk with an authoritative name server, it may talk to an upstream resolver a forwarder), and so receive a smaller TTL. Also, all DNS implementations have an upper bound for TTLs (sometimes configurable, as with BIND and Unbound). Is it a "violation" to cap a one-month TTL (seen in the wild) to one week?
Showing 43 comment(s)