Domain – DNS Building Blocks for Application Developers

In the previous article of this series, we presented our vision for DNS for the coming five years. In this post, we'll outline this year's milestones for expanding the domain crate, our Rust library serving as a collection of building blocks to include components of the DNS protocol in applications or to build specialised DNS tooling.

By Alex Band and Martin Hoffmann

Our strategy is not to rewrite our existing products that currently power much of today’s DNS infrastructure in the world but to rethink how people develop and deploy software that uses the domain name system.

Domain is written in the Rust programming language, which is fast, memory efficient, and has a healthy, vibrant ecosystem. Rust also guarantees memory-safety and thread-safety — enabling developers to eliminate many classes of bugs.

Over the next year, we are committed to laying a new foundation of building blocks to perform resilient and secure name resolution, abstracting as much DNS complexity away as possible. With your feedback, contributions, and the lessons learned along the way, we’ll build a roadmap for next year, and so on. 

Handling DNS Complexity So You Don’t Have To

Software developers currently have to implement a significant number of steps to set up a connection to perform a DNS lookup: check both IPv6 and IPv4 connectivity – preferring IPv6 – and use the first connection that is returned, then establish a TLS encrypted session on top of the link, and if possible, authenticate the remote endpoint using DANE (DNS Authentication of Named Entities). In many cases this makes maximising security and privacy too much effort to tackle.

In the last couple of years, we developed several prototype libraries to research the practicality of the connect-by-name concept. We have built implementations capable of supporting Happy Eyeballs, DANE authentication, selecting DNS upstreams (such as DNS-over-port-53, DNS-over-TLS and DNS-over-HTTPS), as well as limited support for SVCB/HTTPS.

We shared and discussed the resulting library with industry partners to validate our assumptions. This collaboration has also helped us refine our ideas about the usability of connect-by-name in comparison to other existing concepts. We are now ready to build a production-grade implementation with the lessons learned from this research using a modern, memory-safe programming language.

The Milestones: From Core Features to Useful Tools

The domain crate aims to provide a comprehensive – ideally complete – range of building blocks necessary to build specialised DNS applications or include uses of DNS in other applications. By now, it provides several foundational features centred around representing the components of a DNS message – domain names, resource records, etc. – and creating, parsing, and processing them. In addition, it contains a simple, async stub resolver that you can use to initiate specific queries towards upstream resolvers.

Throughout the year, we will extend the foundation to cover most functionality necessary to build other DNS components: authoritative servers, simple resolvers, and proxies. We have structured this work into two tracks: client and server. Naturally, both tracks will start with the ability to send and receive messages using the various existing transports. 

For the client, we will add response caching and DNSSEC validation. In the server track, we will provide means to load zones from zone files, keep them available in memory, and use them to answer queries. We will also provide the means for zone transfers, both its primary and secondary sides. Finally, DNSSEC signing of zones and key management will round out the server track.

Because the only way to judge the quality of these components is to use them in a real-world scenario (and because this is something that many people have asked for), we will start work on a flexible DNS proxy which will allow you to define rules for how to handle requests – whether to have them answered by a specific upstream server, from a configured local zone, or even not at all – based on properties of the request. An initial version of this proxy will tie everything together.

First, we believe a fresh implementation of a DNS diagnostics tool will be valuable. The idea is to provide functions beyond simple DNS queries. For instance, it could allow you to check the DNSSEC status of a zone or whether your local resolver provides answers that match those given by the authoritative servers.

Secondly, our ldns C library includes a number of tools for zone management – sign a zone, check the correctness of a zone, and so on. These were originally intended merely as examples for the library but have since been adopted for production purposes. We will provide a tool (or a set of tools) in Rust as their successor.

Join us on our Open-Source Journey

With a dedicated team of seasoned developers and DNS experts, we will bring domain to the next level, written in a modern language and offering a comprehensive set of features that help DNS developers and operators alike. We will do all development transparently so you can follow the progress as we build, review and release new functionality.

This work lays the foundation for a new generation of open-source DNS software — by us and others. We aim to lower the barrier to developing high-quality software and thereby improve the security and privacy of end users.

In the next article in this series, we'll look at how we are able to offer free, open-source, liberally licensed software in a financially sustainable way and how pioneering work like domain is funded.