DNS-over-QUIC coming to Unbound

Runner at starting line
Photo by Braden Collum / Unsplash

Welcome to this new edition of the NLnet Labs newsletter, bringing you the latest on our adventures from the shores of DNS and BGP land. 🏖

In this issue we continue work on our all-singing, all-dancing RPKI library 🕺, uncover the difference between the two NLnets, prove that time spent with catz 😽 is never wasted and commence work on supporting another encrypted DNS standard.

Oh, and we gave our newsletter a name: "Of Trees and Tries". Because, obviously...

Do53 ➡ DoT ➡ DoH 🔜 DoQ ⚡️

Privacy plays an important part in the development of NLnet Labs products. In our resolver Unbound we promote this with features such as Query Name Minimisation, which we enabled by default in 2018. We also support DNS-over-TLS (DoT) for over a decade now, and two years ago we introduced DNS-over-HTTPS (DoH).

Now there is another standard to encrypt DNS traffic, which tries to overcome some of the shortcomings of the others: DNS-over-QUIC (DoQ), as described in RFC 9250. QUIC and HTTP/3 were developed by Google as an experiment in 2012, moved work to the IETF in 2015 and evolved into a standard last year.

The most important advantages of DoQ are a reduced latency in the handshake, 0-RTT connection resumption, stream based multiplexing, improved error detection and loss recovery compared to TCP, as well as connection migration, allowing the IP address to change. All of this means that DoQ has privacy properties similar to DoT and DoH, but latency characteristics similar to classic DNS over UDP (Do53).

DNS-over-QUIC motivation
From Christrian Huitema's DNS-over-QUIC presentation at IETF99

For more information, you can check out the presentation that Sara Dickinson did at RIPE 84 and this blog post by Cloudflare.

We've recently started development work on supporting DNS-over-QUIC in Unbound. You can follow the progress on the GitHub branch.

GitHub - NLnetLabs/unbound at dnsoverquic
Unbound is a validating, recursive, and caching DNS resolver. - GitHub - NLnetLabs/unbound at dnsoverquic

An Organisation So Nice They Named It Twice ✌️

It's not just the spelling of our company name that is tripping us all up, the difference between the NLnet Foundation and NLnet Labs tends to cause quite some confusion too...

You might have guessed we share a history. Let's quote the NLnet website for the low-down:

NLnet pioneered the worlds first dial-in and ISDN infrastructure with full country coverage. In 1997 all commercial activities were sold to UUnet (now Verizon) and since that time NLnet has focused on supporting the open Internet, and the privacy and security of Internet users.

Along with funding projects that contribute to an open information society, the NLnet board members and Managing Director Ted Lindgreen had another great idea on how to put their dot-com-bubble-bag-o'-money to good use: for long term research projects NLnet Labs was founded in the final days of 1999.

Ten Lindgreen, Credits Frank Groeiliken
Ted Lindgreen — Credits Frank Groeiliken
In addition to setting up NLnet Labs, Ted Lindgreen was also involved in the creation of the Amsterdam Internet Exchange (AMS-IX) and SIDN, the registry for the .nl country code top-level domain. Quite the pioneer!

NLnet used to fund the work of NLnet Labs completely, but we've been standing on our own feet for almost a decade now. We are completely separate, independent organisations that both support an open Internet in their own way: the NLnet Foundation with project funding 💸, NLnet Labs with open-source software and applied research 🧑‍💻.

Phew! I'm glad we cleared that up. Now, was it NLNETLabs, NL Netlabs, NLNetLabs, or... 😭

Herding Zones with CATZ 😻

The content of a DNS zone is synchronised amongst its primary and secondary nameservers using authoritative and incremental zone transfers (AXFR and IXFR). However, the list of zones served by the primary (called a catalog) is not automatically synced with the secondaries.

To add or remove a zone, the admin of a DNS nameserver farm not only has to add or remove the zone from the primary, they also have to add or remove it from all secondaries – either manually or via a home grown solution using for example Ansible, Puppet or Chef. This can be both inconvenient and error-prone, and often only works for a single DNS implementation.

"lots of zones" meme
Managing a lot of zones can be daunting...

To solve this problem, we have worked together with our fellow open-source DNS implementers to standardise Catalog Zones (CATZ). With CATZ the catalog is represented as a regular DNS zone and transferred using DNS zone transfers.

At RIPE 84 in Berlin, Petr Špaček from ISC presented on CATZ, where he mentions that BIND9 and Knot have now released this functionality in production. At NLnet Labs we haven't yet built a production grade implementation for NSD, but we'd really like to sink our teeth into it.

We are looking for sponsors to the development of Catalog Zones in NSD. Reach out to learn more! You can also help out our friends at PowerDNS and ISC.

An All-Purpose Library for RPKI 📚

Also at RIPE 84, Tim gave a lightning talk about rpki-rs, our RPKI library for Rust that forms the core of what powers Krill and Routinator.

GitHub - NLnetLabs/rpki-rs: An RPKI library for Rust
An RPKI library for Rust. Contribute to NLnetLabs/rpki-rs development by creating an account on GitHub.

We recently ported all functions for Certification Authority support from Krill to rpki-rs. This means the library now features almost all object types, validation logic and communications protocols for RPKI. Anyone who wants to build their own tooling can rely on this open-source library.

An overview of the rpki-rs capabilities
The bag of tricks rpki-rs offers

‌Quick Updates

🔀  In our previous newsletter we talked about outgoing incremental zone transfers (IXFR out). This is now released in NSD 4.5.0.‌‌
🚦 In the previous newsletter we also covered Extended DNS Errors. This is available in Unbound 1.16.0.
📦 The armhf/arm64 packages that we introduced a few months ago for Routinator are now also available for Krill.
🛝 If you want to play around with Delegated RPKI to see how it can streamline your ROA management, Tim explains how to make a Krill sandbox on the APNIC blog.

That's it for now. Thanks for reading, until next time!

💚 from the NLnet Labs crew