DNS-over-QUIC coming to Unbound
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...
Binary tree in its natural habitat β¦ π pic.twitter.com/J5TvGkAvvX
β Laurel Coons π§¬π§¬π§¬ (@LaurelCoons) May 31, 2022
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).
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.
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.
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.
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.
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.
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.
β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