Philip Homburg

At NLnet Labs, we worked on creating an API and prototype implementation for 'connectbyname', library function that takes as input a (DNS) name and returns a TLS connection. The idea is to work towards a standard API for such a function, that can internally use asynchronous DNS lookups, implement Happy Eyeballs, support DANE, SVCB/HTTPS, encrypted client hello, etc. I will present the various prototype implementation we created.

During this work we found that supporting the many new DNS connection types (DNS over TLS, DNS over HTTPS, DNS over QUIC) from within a library is creating a nu mber of problems. To deal with this problem, we created a new EDNS(0) option called Proxy Control option, that allows stub resolvers to send requirements to a local proxy. I will present this option and how it can help to keep DNS stub resolvers simple.

The most common setup is where a recursive DNS resolver does the DNSSEC validation. The nice thing about this approach in that existing applications do not require modifications.

However, an application cannot easily tell if the resolver is doing DNSSEC validation, and the path between the application and the resolver is unprotected.

The solution to this, is for applications to do local DNSSEC validation. This can be done using the getdns library. The getdns library provides other advantages as well, such as a modern interface to DNS resolution, support for event libraries (such as libevent).

In this presentation I will describe getdns and show two examples of how it can be used in practice.

I wrote inet (the TCP/IP stack on MINIX) for two reasons: I like to come up with my own designs for everything and, most of all, I had to impress Andy Tanenbaum enough to become a Ph.D. student. Inet had to fit in with MINIX. In particular, it had to live with minimal changes to the MINIX code base. At the same time, there were quite a few areas where I felt sockets and the BSD TCP/IP implementation were wrong.

In hindsight, there is a lot that I did not know and got wrong. I this talk, I will look at how inet follows the structure of MINIX, what works, and what went wrong.

Minix-vmd is a fork of MINIX 1.6 developed by Kees Bot and Philip Homburg. The goal of Minix-vmd was to go where MINIX could not go. MINIX was to remain simple enough for students to understand. Features such as virtual memory, job control, virtual filesystems, etc. where out of scope. Minix-vmd was created to see what MINIX would look like with those features.

In this talk I will go over the history of Minix-vmd, highlighting features that sometimes made it into MINIX2, in some cases to be dropped again from MINIX3. Features that never made into any other MINIX version. Features that might be too radical.

I will also briefly touch upon the importance of eating your own dog food. Taking an experimental system into production elevates it beyond that of a toy system. Minix-vmd has been in various forms for production use for over two decades. For me personally, Minix-vmd is my main internet router for the last 15 years, handles my e-mail, usenet, backups, DNS for my domain, and ntp.

RIPE Atlas is a global network of probes that measure Internet connectivity and reachability. More then 9000 hardware probes are hosted by the community of volunteers. Supported measurements are ping, traceroute6, DNS, NTP, and TLS. All the probes perform constant measurements towards root name servers, and the users are able to start their own measurements from up to 500 probes at the time, to the target of their own choice. All the results of performed measurements are publicly available as open data.

RIPE Atlas is a global network of probes that measure Internet connectivity and reachability. More then 9000 hardware probes are hosted by the community of volunteers. Supported measurements are ping, traceroute6, DNS, NTP, and TLS. All the probes perform constant measurements towards root name servers, and the users are able to start their own measurements from up to 500 probes at the time, to the target of their own choice. All the results of performed measurements are publicly available as open data.

In addition to the web interface & the API calls for starting your own measurements, and for downloading results, there is now CLI toolset. This open-source toolset is the newest addition to the large collection of tools written by RIPE NCC developers & the community of volunteers, individually or during two hackathon runs.

My goals with this presentation are: to encourage FOSDEM participants to contribute to the free & open source code related to RIPE Atlas & port the toolset to Linux/BSD distributions; to use the existing data, start their own measurements, and to share results by writing papers & giving presentations.