Authors

Stéphane Bortzmeyer

Based in Paris (France)

13

Articles

40

Likes on articles

About the author

I work at AFNIC (the registry of .fr domain names), in the R&D department, on, among other things, DNS, security, statistics.

• Reply to Wouter on Creating RIPE Atlas One-off Measurements with Blaeu by Stéphane Bortzmeyer

“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.

• On Fixing Reachability to 1.1.1.1, GLOBALLY! by Marty Strong

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

• On Using RIPE Atlas to Debug Network Connectivity Problems by Stéphane Bortzmeyer

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

• On RIPE Atlas Measurement Tagging by Chris Amin

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 :-(

• On RIPE Atlas Measurement Tagging by Chris Amin

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.)

• On FOSDEM 2018: What Happens in Brussels (Ends Up on the Internet) by Vesna Manojlovic

@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 :-)

• On Measurements as the Key to Transparency by Alexander Azimov

Nice tool, thanks, I recommend it. But a bit rough in both usage (documentation could be improved) and in high-level explanations.

• On Ethics of RIPE Atlas Measurements by Robert Kisteleki

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).

• Reply to Giovane Moura on DNS TTL Violations in the Wild - Measured with RIPE Atlas by Giovane Moura

“Thanks Stéphane for your feedback. I refer to TTL violations as in [1] , 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 [1] 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?

• On DNS TTL Violations in the Wild - Measured with RIPE Atlas by Giovane Moura

Thanks for these very interesting measurements. Really useful. But I disagree with your use of the same term ("TTL violations") for the increase and the decrease of the TTL. A TTL is a *maximum*. A resolver is always free to keep the data for a *shorter* time, for instance because it reboots, or because the cache is full and it has to evict some data. It's only the increase of the TTL which is a protocol violation. Decreasing the TTL, like Amazon does systematically, is bad manners, it transfers costs to someone else, it is selfish, but it is not a protocol violation.

Showing 52 comment(s)