Based in Paris (France)
Articles
Likes on articles
I work at AFNIC (the registry of .fr domain names), in the computer department, on, among other things, DNS, security, technical watch, standardization.
Website: https://www.bortzmeyer.org/
• 6 min read
Each RIPE Atlas probe has at least one DNS resolver, indicated by a DHCP reply on the local network of the probe. Irrespective of the IP address of the resolver, this server may have IPv4 and IPv6 connectivity or only IPv4 connectivity. What is the percentage among RIPE Atlas probes?
• 4 min read
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.…
• 4 min read
To check the connectivity of an IPv6 device with RIPE Atlas, one typically asks N probes to ping the target and deduces the reachability of the target from the percentage of failures. But RIPE Atlas probes, like many IPv6 devices, often believe they are IPv6-connected while they are not.
• 12 min read
A DNS anycast name server has several physical instances, all behind the same IP address. Which one is used by a RIPE Atlas probe depends on the location of the probe in the BGP space. RIPE Atlas can query the physical identity of the probe and therefore help to determine which instances have the l…
"you generally identify DoT service endpoints by their IP name" Did you mean IP address?
Unless I'm wrong, the bias for RIPE Atlas probes is measured by the number of probes in the AS. Isn't there also a bias when asking N probes for a measurement, without specifying area/country/AS? Are we guaranteed that the set of probes we obtain respects the general population of probes? Or is there an extra bias here?
"highly dependent on submarine cables for their connectivity" For islands, it is expected, no?
“Very nice write up, I like the detail of two way trip time. I'd also recommend looking in to ITU Y.1564, this works end to end at the application layer which may be more accurate. An ICMP ping may be processed by the processor on each layer three node (adding increased latency to what would be seen by other protocols such as http).”
« An ICMP ping may be processed by the processor on each layer three node (adding increased latency » Hmmm, certainly not. If you *direct* an ICMP echo request to a router, yes, the processing by the target (the router) will typically be slow, but, if you direct it to a remote machine, for all the routers on the path, it will just be an ordinary packet, forwarded like any other.
The README of sping has no usage instructions https://github.com/benjojo/sping/issues/4 https://github.com/benjojo/sping/issues/5 so, since it is not obvious, here is a summary: 0) Check that you have a clean path between the two machines (UDP port 6924 must pass) 1) On the responder (server / slave / pick the name you want), run sping without arguments 2) On the initiator (client / master / pick the name you want), run sping with -peers (I tried with IP addresses, may be it also works with names), for instance './sping -peers 192.0.2.11'. The result are displayed in the Web interface (by default, 'http://[::]:9523/metrics') under 'splitping_latency'. If you prefer see them in the console, add -debug.showstats to sping.
"issues such as spam and copyright clearly cross the technical picket fence they have set" No, it is not at all clear to me and it requires explanations. How is copyright a technical issue? Also, it has nothing to do with the subject, which was protecting users (not Disney or Elsevier) from abuse.
Regarding Geoff Huston's comment, and after discussion with Florian Maury, and with his authorization, I translate here his analysis : "The attack [NXNSattack] is quite different, and it has a significant impact. It was not detected at the time of iDNS. Moreover, the article [about NXNSattack] is well written, mentions the related work and explains the differences. To summarize, this is an new and serious contribution."
Alexandre Pion noticed a small bug: for the median too, we should exclude the null results.
One may assume that, if some people delayed the changes, other people rushed in to adapt the networks to the increased load? Both behaviour may explain why the change rate is more or less the same?
“Thanks, Stéphane! At some point I may add extra examples to the documentation. Is it okay if I include something based on your example?”
You're welcome to use this example as you see fit. A better version is available at https://www.bortzmeyer.org/files/ris-live.py
Showing 59 comment(s)