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… 👨🚀
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.
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.
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.
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.
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.
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!
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.
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.
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