Authors

Stéphane Bortzmeyer

Based in Paris (France)

14

Articles

93

Likes on articles

About the author

I work at AFNIC (the registry of .fr domain names), in the computer department, on, among other things, DNS, security, technical watch, standardization.

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

• Reply to OLF on Quad9, a Public DNS Resolver - with Security by Stéphane Bortzmeyer

“With the stubby config above I only receive a FORMERR $ dig @::1 -p 8053 A www.catstuff.com ; <<>> DiG 9.8.3-P1 <<>> @::1 -p 8053 A www.catstuff.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 39788 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;www.catstuff.com. IN A ;; Query time: 115 msec ;; SERVER: ::1#8053(::1) ;; WHEN: Tue Nov 28 07:06:35 2017 ;; MSG SIZE rcvd: 45”

This is apparently because a known ECS bug https://github.com/getdnsapi/getdns/issues/357 already fixed in the code repository.

• Reply to GAURAV KANSAL on Quad9, a Public DNS Resolver - with Security by Stéphane Bortzmeyer

“DNSDB link mentioned is only for account holders. Can we get the information about previous usage of 9.9.9.9 from any other source, which don't need an account ?”

DNSDB is subscription-only. But there are some gratis "passive DNS" databases such as https://passivedns.cn/ or https://www.circl.lu/services/passive-dns/

• On Measuring your Web Server Reachability with TCP Ping by Rene Wilhelm

I modified a bit my tools (following Vesna Manojlovic's excellent talk at RIPE NCC Educa yesterday https://www.ripe.net/support/training/ripe-ncc-educa) to implement the options required for "TCP ping". See https://labs.ripe.net/Members/stephane_bortzmeyer/using-ripe-atlas-to-debug-network-connectivity-problems for a description of these tools/. Here is an example: % atlas-traceroute -f -r 3 --protocol TCP --size=0 --port=43 --first_hop=64 --max_hops=64 $(dig +short +nodnssec AAAA whois.ripe.net) Measurement #9721999 Traceroute 2001:67c:2e8:22::c100:687 uses 3 probes 3 probes reported Test #9721999 done at 2017-10-06T14:34:57Z From: 2601:646:8d00:6951:fa1a:67ff:fe4d:6a0c 7922 COMCAST-7922 - Comcast Cable Communications, LLC, US Source address: 2601:646:8d00:6951:fa1a:67ff:fe4d:6a0c Probe ID: 12908 64 2001:67c:2e8:22::c100:687 3333 RIPE-NCC-AS Reseaux IP Europeens Network Coordination Centre (RIPE NCC), NL [160.926, 161.434, 163.041] From: fd00:8494:8c40:8c12:16cc:20ff:fe48:cf02 None None Source address: Probe ID: 27041 Error: connect failed: Network is unreachable [Note added manually: probably fascist firewall. Outgoing whois is often blocked.] From: 2003:6:21f8:7957:a62b:b0ff:fedf:fd2c 3320 DTAG Internet service provider operations, DE Source address: 2003:c3:e3e5:a57:a62b:b0ff:fedf:fd2c Probe ID: 28991 64 2001:67c:2e8:22::c100:687 3333 RIPE-NCC-AS Reseaux IP Europeens Network Coordination Centre (RIPE NCC), NL [35.646, 35.717, 36.512] TODO: aggregate results to show median and average, as in "ordinary ping" tests: % atlas-reach -r 3 -g 9721999 $(dig +short +nodnssec AAAA whois.nic.fr | tail -1) 2 probes reported Test #9722014 done at 2017-10-06T14:40:01Z Tests: 6 successful tests (100.0 %), 0 errors (0.0 %), 0 timeouts (0.0 %), average RTT: 111 ms

• On A Virtual Canary-in-the-Coalmine for the DNSSEC Root Key Rollover by Roland van Rijswijk-Deij

Strange problem with a Knot resolver: only orange (open padlock) dots. The resolver validates, I'm pretty sure of it: % dig A labs.ripe.net ; <<>> DiG 9.9.5-9+deb8u11-Debian <<>> A labs.ripe.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56289 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 8, ADDITIONAL: 9 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;labs.ripe.net. IN A ;; ANSWER SECTION: labs.ripe.net. 600 IN A 193.0.6.153 labs.ripe.net. 600 IN RRSIG A 8 3 600 ( 20170726090003 20170626080003 31785 ripe.net. jMr0wyDGah/o4e4yV5slTEwqlk6KK11NkWDaiagnIdJp vDO4z9U+MoGWHkdR2rX94kt+eLWgy+U48ygPwY0vyChn xnjcEZ+4DZ8ZfzsSQ+BHodKksujfiCdTeiw6HsrcwtEq AuvdJ19EF9v8c0lVjil46HUhfltgPT7/p+B2Ct0= ) ;; AUTHORITY SECTION: ripe.net. 2131 IN NS a3.verisigndns.com. ripe.net. 2131 IN NS sns-pb.isc.org. ripe.net. 2131 IN NS a1.verisigndns.com. ripe.net. 2131 IN NS manus.authdns.ripe.net. ripe.net. 2131 IN NS sec3.apnic.net. ripe.net. 2131 IN NS tinnie.arin.net. ripe.net. 2131 IN NS a2.verisigndns.com. ripe.net. 2131 IN RRSIG NS 8 2 3600 ( 20170726090003 20170626080003 31785 ripe.net. UlsAmef8O5ls8BHV4Is81uw5q4iWWN82SEgk5DVvT5t7 yN03+/Cl6B8XxcfhymW+/5ndBl2R673GKfamb3Xm2nVd g8JT27ScD6kpYLWTqqITb1+/4PXXyTcYhRVrrfBmjgFG NyyKreTi1mrfV5KConADv2PKk1ixuU8hMxdFnhk= ) ;; ADDITIONAL SECTION: sec3.apnic.net. 171330 IN A 202.12.28.140 sec3.apnic.net. 171330 IN AAAA 2001:dc0:1:0:4777::140 manus.authdns.ripe.net. 171330 IN A 193.0.9.7 manus.authdns.ripe.net. 171330 IN AAAA 2001:67c:e0::7 tinnie.arin.net. 171330 IN A 199.212.0.53 tinnie.arin.net. 171330 IN AAAA 2001:500:13::c7d4:35 manus.authdns.ripe.net. 2131 IN RRSIG A 8 4 3600 ( 20170726090003 20170626080003 31785 ripe.net. PUJXvQ3gFUNXBMgf4Rs5OuuAhLhlOVYMrL1vDKkeZRmY awgwQOJKkRiASVERXIWiyabTxTW+ziORa28QKsDhjRgv OLhPyBO6XJ4ol4bY1Yiecc78vi8lGBYq7Onnn6YYgHdm kAYzGp16ggAd6EitKsz+ymzkDF+HS1Jen7ZcNkI= ) manus.authdns.ripe.net. 2131 IN RRSIG AAAA 8 4 3600 ( 20170726090003 20170626080003 31785 ripe.net. lkXqjQBWK1WkEJUnD7SvzCKd8vpRKzBxWap69Ia4WiHS F8D99749X9NklhDtthD3R7c1umOwoAi7R6OIwjUnVFH8 Q+PBahvmJCefnj/RAEYw4H7HQyvPkSjGhlQ27/vN2ApL p8IzQ+Ym6G1cuxSAVG9NKq6WrgXON3I17JKE0mY= ) ;; Query time: 457 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Jun 27 20:56:19 CEST 2017 ;; MSG SIZE rcvd: 1035

• On A Virtual Canary-in-the-Coalmine for the DNSSEC Root Key Rollover by Roland van Rijswijk-Deij

It's with BIND that I get the most green dots: even GOST works fully: https://framapic.org/7UIoLRIEQelV/ci1qZP1I94FA.png The only missing stuff is the Bernstein crypto.

Showing 57 comment(s)