Internet Network Shutdowns in Russia
• 8 min read
There have been several calls for Russian Internet networks to be shut down in one way or another and announcements that Russia is going to make such cuts. In this article, Stéphane Bortzmeyer explores the issue from a technical point of view.
"CloudFlare, Google and Quad9 all offer DoH" As far as I know, only Cloudflare does it. Google Public DNS has an experimental DNS-over-HTTPS (proprietary, not DoH) service and Quad9 seems to have "only" DoT (see https://quad9.net/faq/#Does_Quad9_support_DNS_over_TLS )
Saying that automatic contracts ("smart contracts" is the marketing BS) cannot be changed ("these contracts are unmodifiable") is not strictly true. To quote an old saying "every problem in computer science can be solved with one more indirection". So, you can have a pointer to the current version of the code of the smart contract, and changing the code by adding a new version of the pointer. Of course, this adds complexities and security risks but it shows that there are ways to modify automatic contracts, for instance to follow a change in policies. The description of the "51 % attack" is very sketchy ("quickly spawning a large quantity of client nodes that participate in the consensus making"). In a real blockchain, techniques like proof-of-work and proof-of-stake prevent this trivial Sybil attack. But there is a subtler reason why the "51 % attack" is overhyped: it is easily detectable (the Bitcoin Core code, for instance, logs it). So, honest miners will see it. It will not be easy to recover from the attack (the honest miners will have to fork) but it cannot be stealthy.
The link "real-time streaming capabilities" goes to a 404. I suspect the correct target is https://labs.ripe.net/Members/colin_petrie/updates-to-the-ripe-ncc-routing-information-service
I love "curl | sudo bash" in an article about security :-) Seriously, it seems the article has a confusion between DoH, as currently being standardized at IETF (and deployed by Cloudflare on 1.1.1.1) and the Google service which, unlike DoH, does not use the DNS wire format, but JSON, as shown in your example.
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 1.1.1.1 --type AAAA --displayvalidation www.bortzmeyer.org Nameserver 1.1.1.1 [ (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.)
Showing 57 comment(s)