Based in Amsterdam, NL
Likes on articles
About the author
Based in Amsterdam, NL
I'm a system architect/research coordinator at the RIPE NCC, where I work in the science group. I'm a chemist by training, but have been working since 1998 on Internet related things, as a sysadmin, security consultant, web developer and researcher. I am interested in technology changes (like IPv6 deployment), Internet measurement, data analysis, data visualisation, sustainability and security. I'd like to bring research and operations closer together, ie. do research that is operationally relevant. When I'm not working I like to make music (electric guitar, bass and drums), do sports (swimming, (inline) skating, bouldering, soccer), and try to be a good parent.
Links & Social
The roll-out of a signed root-zone at K-root on 24 March 2010 was uneventful. But we saw the number of resolvers doing priming queries increase slightly since 18 March 2010 and wanted to find out why.
In Part 1 and Part 2 of this article we showed various statistics on IPv6 measurements of web clients and caching resolvers. In this part we explain how the measurements were done.
In Part 1 of this article we showed some statistics on IPv6 at end-users and at caching DNS resolvers. In this part will dig deeper into the data we collected and show details on mobile device use of IPv6, country- and city-level IPv6 deployment numbers, and AS-level statistics.
It is important to keep an eye on how the IPv6 Internet develops. We wrote a script to measure the IPv4 capability, IPv6 capability and IPv4/IPv6 preference of end-users visiting our site. What is unique about this script is that it allows us also to measure the caching DNS resolver that the end-us…
In this article we take a look at DNS priming queries arriving during the deployment of a DNSSEC signed zone at the DNS root servers. We are specifically looking for potential problems as a result of this deployment.
Last month we covered the 2015 leap second ahead of the insertion of a leap second at the very end of 2016. As stated previously, leap seconds can trigger poorly-tested code paths; leap second handling always unearths bugs and issues. This one was no exception!
In this article, we give one example of the possible communities that are now easier to build around RIPE Atlas probes. With the tagging of similar probes, existing communities can use additional tools for creating and analysing RIPE Atlas measurements, such as "IXP Country Jedi", to create their o…
We look into why dynamic addresses change and find ISPs that renumber periodically, most commonly every 24 hours or a multiple of 24 hours. We also find that outages influence address changes.
This article is intended to make RIPE Atlas users aware of ethical issues that could arise when using RIPE Atlas. We do not intend to propose any new formal processes or procedures to address the relevant ethical issues, but we do want to encourage members of the RIPE Atlas community to consider th…
We used a number of RIPE NCC tools and data sets to take a quick look at the recent DDoS attack on Dyn’s infrastructure. We wanted to see if this could be found in the data produced by the RIPE Atlas community.
Pinpointing Delay and Forwarding Anomalies Using RIPE Atlas Built-in Measurements - Or How I Learned to Stop Worrying and Love the Built-Ins
Detecting network disruptions is a recurring problem. Clearly locating performance degradation is an important step in debugging and subsequently fixing connectivity issues.
In 2013 and 2014 we looked into measuring Interdomain Routing in Africa using the RIPE Atlas infrastructure. This resulted in a paper published at the PAM (Passive and Active Measurement) 2015 conference. Here we present some highlights of this research.