The NLnet Labs Newsletter – Spring 2022

Spring in Amsterdam
Photo by Catalina Fedorova / Unsplash

Welcome to our first newsletter, providing you with an update on what we've been doing over the last few months and what's coming up from your favourite open-source development crew below sea level. πŸ‘·β€β™€οΈ

In this edition: both our software development and Internet Governance activities get reinforced with new staff, the DNS projects gain fancy new features, our BGP software ventures beyond routing security, and together with our friends we talk sustainable open-source with a man in space… πŸ‘¨β€πŸš€

Team Update

Let's start off with some exciting news. We are proud to have expanded our team with three awesome new colleagues, bringing the total crew to sixteen!

Maarten Aertsen has started as our Senior Internet Technologist. Together with Internet Hall of Fame legend Jaap Akkerhuis he will strengthen our Internet Governance presence.

Maarten has soldered together an Arduino-powered keyboard πŸ‘¨β€πŸ­ and recently finished building a LEGO Millennium Falcon. He likes to juggle with four balls πŸ€Ήβ€β™‚οΈ and one day hopes to perform with flaming chainsaws. πŸ‘¨β€πŸš’

In recent months we also welcomed Philip Homburg to the team, who previously worked on the measurement code and other firmware that runs on RIPE Atlas probes.

Philip used to combine research πŸ”¬ with triathlons πŸŠβ€β™‚οΈπŸš΄β€β™‚οΈπŸƒβ€β™‚οΈ, then later switched to herding Atlas probes and inline skating. A decade later, he finished restoring a small warehouse, obtained a family and, at NLnet Labs, switched to fulltime DNS.

Last but not least, after a one year stint elsewhere, Jeroen Koekkoek returned to NLnet Labs after realising it was the most fun place he had ever worked.

Jeroen is trying his luck at applying a hacker-mindset to fixing up his home πŸͺš. He plays a bit of guitar 🎸, hopes to play the accordion πŸͺ— at some point too and likes cycling in the Dutch mountains πŸš΄β€β™‚οΈ. He hopes SIMD operations will be available in real-life soon.

Philip and Jeroen bring a wealth of development skills and industry knowledge to the organisation and will both initially focus on stengthening our DNS team.

πŸ‘©β€πŸŽ¨
We are always looking for talented people to join our team. If you would like to be our new Data Visualisation Designer / Front-End Developer with complete freedom and no legacy code, read on!

DNS Software Developments

In addition to the continuous developments on our recursive resolver Unbound, authoritative name server NSD and signing toolkit OpenDNSSEC, we perform extensive R&D into the future of DNS. This includes Martin's work on the domain crate for Rust and Jeroen's work on improving performance of zone loading in NSD.

Philip and Willem are currently exploring new avenues with Connect by Name. The traditional idea of this API is to pass the function a name and get a connected TCP socket in return. However, these days we expect a lot more: instead of just a TCP socket, we want a TLS connection, β€œhappy eyeballs” and an asynchronous interface. Also, DNS got a lot more complex with DNS over TLS, DNS over HTTPS, and DNS over QUIC. We are working on a design and prototype implementation to eventually cover all of this.

Unbound: Extended DNS Errors

RFC 8914 describes Extended DNS Errors (EDE), an extensible method to return additional information about the cause of DNS failures. A good example of situations where additional information is greately beneficial are errors caused by DNSSEC validation issues.

Tom has recently completed support for the basic EDE cases, which has now been merged into Unbound's main branch. With an EDE option enclosed in the response message, Unbound is able to return a more descriptive reason as to why any failures happened in a broad range of cases.

Add the basic EDE (RFC8914) cases by TCY16 Β· Pull Request #604 Β· NLnetLabs/unbound
this branch is a split from #504 which implements all the easier EDE cases.

Unbound: PROXY Protocol

The PROXY protocol provides a convenient way to safely transport connection information, such as a client's address, across multiple layers of NAT or TCP proxies. It is designed to require little changes to existing components and to limit the performance impact caused by the processing of the transported information.

The PROXY protocol for DNS allows passing source information from load balancers to DNS backends. We received several requests from customers to support this functionality in Unbound. Yorgos has made an implementation to support version 2 over the last few months and is now putting the finishing touches on it.

πŸ’
The PROXY protocol functionality in Unbound is graciously sponsored by Sunet, the Swedish University Computer Network. In addition to financial support they continually test our pre-release code and provide us with valuable, real-world feedback throughout the development process.

NSD: Outgoing Incremental Zone Transfers

Incremental zone transfer, or IXFR for short, lets secondary name servers tell their primaries which version of a zone they currently hold and to request just the changes to the zone between that version and the current one. This can reduce the size and duration of a zone transfer dramatically.

Wouter has recently finished his implementation of IXFR out, towards requestors. This has now been merged into the main branch and is ready for the next NSD release.

IXFR out by wcawijngaards Β· Pull Request #209 Β· NLnetLabs/nsd
IXFR support to provide IXFR going out, towards requestors. The implementation can store downloaded IXFRs, with store-ixfr: yes and create IXFRs from zonefiles with create-ixfr: yes.The ixfr-numbe...

NSD: Explicit Socket Types

While we are continuing our journey into supporting eXpress Data Path (XDP), Jeroen is doing some preparation work that will help the deployment in NSD. Specifically, listening on both UDP and TCP is likely unwanted behavior when support for XDP lands.

The implementation allows the user to configure listening on UDP, TCP or both per ip-address option in preparation. Specifying no socket type at all ensures both UDP and TCP are opened, which is the current default behavior. This ensures the configuration remains backwards compatible.

Allow user to specify socket type per ip-addres by k0ekk0ek Β· Pull Request #210 Β· NLnetLabs/nsd
Listening on both UDP and TCP is likely unwanted behavior when support for XDP lands. Allow the user to configure listening on UDP, TCP or both per ip-address option in preparation. Specifying no s...

To learn more about XDP, you can also listen to Willem, Luuk and Tom discussing this topic on APNIC's PING podcast.

Routing Software Developments

Our work on tooling for routing security has led to multiple requests from the industry to create building blocks for a wider range of BGP routing purposes. As a result, Jasper, Ximon, Luuk and Martin are developing the Rotonda modular BGP engine. All components are written in the Rust programming language, making them blazingly fast while guaranteeing memory-safety and thread-safety.

One of the first publicly available components is the rotonda-store, a data structure to store IPv4 and IPv6 prefixes in a tree bitmap. We have written about this data structure earlier in this blog post. The project also includes roto-api, an HTTP/JSON API that exposes data from BGP announcements through the RIPE Routing Information Service and Extended Delegation Statistics files from the five RIRs. The API currently powers the user interface for Routinator, but can also be used for other purposes.

Lastly, we should also mention routecore, a Rust crate that aims to provide fundamental building blocks, i.e. Types and Traits for applications, that need to deal with BGP routing related data.

There is a lot of exciting work in the pipeline that we will be able to tell you about in future newsletters!

Routinator

In recent months, Martin introduced support for BGPsec router keys in Routinator. He also added TLS support to the RPKI-to-Router (RTR) and HTTP servers, which is one of the two features sponsored by the Internet Society. The other will be support for TCP Authentication Option (TCP-AO), planned for later this year. Please note that version 0.11.2 contains an important fix to the RTR server, so make sure you keep the application up-to-date.

Lastly, Ximon also expanded our software package repository to support various flavours of the ARM architecture. We'll make sure to apply to this workflow to all of our Rust-based projects.

Krill

Our RPKI Certificate Authority (CA) software Krill is used by two National Internet Registries (NIRs): the Brazilian NIC.br and Indonesian IDNIC. Both NIRs now have well over a thousand organisations running a delegated CA. As a result, Tim has been hard at work to make sure Krill scales well on modest hardware. With these improvement released in version 0.9.5, the focus is now to make supporting Hardware Security Modules a production feature that is part of the standard binary.

Community Update

At NANOG 84 earlier this year, Alex participated in a panel discussion together with Ondrej Filip (CZ.NIC) and Jeff Osborn (ISC) on sustainable open-source software development. We explored how we make development decisions, interact with users, compete or partner with for-profit entities and raise funds. You can watch the recording on YouTube.

We we were also incredibly happy to be back at an in-person IETF meeting, this time in Vienna. Of course we participated in the Hackathon with our DNS friends.

In the IEPG session, an informal gathering that meets on the Sunday prior to IETF meetings, Willem presented his research on Measuring Route Origin Validation with the Resource Public Key Infrastructure (RPKI) beacons we have deployed.


We want to end this newsletter with a pitch. NLnet Labs is an independent foundation and our open-source work will always be free. In our README on GitHub, we formulate our commitment to you. If you think our work is important, please consider supporting us.

That's all for now, until next time!

πŸ’š from the NLnet Labs crew