Authors: Olivier van der Toorn, Moritz Müller, Sara Dickinson, Cristian Hesselman, Anna Sperotto, and Roland van Rijswijk-Deij.
Earlier this year, we published a tutorial paper ‘Addressing the challenges of modern DNS: A comprehensive tutorial‘. The paper was co-authored with colleagues at the University of Twente and sinodun. It describes the Domain Name System (DNS) from two perspectives — what the modern DNS actually looks like in practice, and what security challenges the DNS currently faces. The paper is aimed at technical personnel who want to know more about the DNS, and at DNS specialists looking for somewhere to get started on a more detailed exploration of the subject. In this article, we want to give an overview of our paper and to discuss open challenges.
Why a(nother) DNS tutorial?
We wrote the tutorial because finding out about the current state of the DNS can be quite an undertaking. Numerous DNS tutorials can be found online, but most explain only the basics of how the system works. And only a few of them cover recent developments such as DNS-over-HTTPS (DoH) or DNS centralization. Another problem is that the formal documentation on the DNS is extensive. In the early days of the DNS, the RFCs defining the system ran to maybe a hundred pages. Now, there are more than two hundred documents numbering a total of more than 3,500 pages. Anyone who wants to get to grips with the subject therefore needs to read a huge number of documents, and then consider which parts of them actually apply in the modern world.
Our paper is intended to help people get past those problems. We explain what the modern DNS looks like in practice, and we help (budding) DNS specialists identify the key security issues currently associated with the DNS. Our target audience consists of two groups. Firstly, technical personnel who are relatively new to the DNS (such as students, researchers, and software developers). Secondly, people who already have significant expertise and want somewhere to get started on a more detailed exploration of the subject (for which our reference list is potentially useful). The paper draws on our own DNS research, our operational experience, and our familiarity with the DNS RFCs and academic literature.
Ultimately, we hope to contribute to further reinforcement of the DNS community in the Netherlands, Europe, and beyond. That’s an important goal because the DNS is one of the Internet’s core systems, playing a role in almost every Internet transaction. A strong technical community of DNS experts is therefore vital for the health of the Internet.
Perspective 1: The modern DNS in practice
Our tutorial considers the DNS first from the perspective of recent developments in DNS practice. Examples include the encryption of DNS messages, progressive centralization of the DNS infrastructure, and the influence of centralization on DNS functionality and on users, operators, developers, and researchers. In other words, we portray the DNS as a dynamic and continuously evolving (eco)system.
Our tutorial also explains how large-scale measurements can be performed to shed light on the evolutionary changes taking place in the DNS. Broadly speaking, there are two approaches to large-scale DNS measurement. One is active measurement — querying the DNS ‘from outside’, such as with OpenINTEL. The other is passive measurement — gathering data on DNS servers, for example, using ENTRADA. In our paper, we describe how you can set up such measurements yourself, and what the pros and cons of the different measurement methods are.
Perspective 2: Four key security challenges for the DNS
The second perspective offered by our tutorial is a description of four key security challenges for the current DNS — increasing the confidentiality, integrity, and availability of the DNS, and tackling abuse. The figure below gives a schematic overview. For each challenge, we explain which solutions already exist, but also discuss open challenges. We highlight some of these open challenges in the following paragraphs.
Confidentiality
By default, DNS messages are transmitted in plain text. This, however, leads to all sorts of different security and privacy issues. Luckily, the community has proposed several ways to mitigate the threats. For example, query name (QNAME) minimization is now supported by all major open source resolver software vendors, reducing the amount of information shared unnecessarily throughout the DNS resolution process. Furthermore, DNS messages can now be encrypted, using TLS, either directly or embedded in HTTP or QUIC.
Nevertheless, these solutions are still far from perfect. For example, the community is busy finding ways to allow clients to discover and securely connect to resolvers that offer encrypted transport. Additionally, and despite the wider deployment of QNAME minimization, query confidentiality at recursive resolvers remains an open problem. Oblivious DNS over HTTPS (ODoH) or Apple’s Private Relay are possible solutions but can have negative effects on performance. Finally, the channel between recursive resolvers and authoritative name servers should be encrypted. The standardization of DNS over QUIC (DoQ) is an important step in this direction, but its impact on large-scale name server deployments as well as means to establish authenticated connections are still being researched.
Integrity
In principle, integrity in the DNS has been achieved for many years. DNS Security Extensions (DNSSEC) was standardized in its current form in 2005 and has been deployed at millions of domain names and recursive resolvers. Ideally however, DNSSEC signatures are not validated by recursive resolvers but directly at the requesting clients. Only then can clients be sure their recursive resolver has not been tampering with the responses. Additionally, this would make new deployment models like ‘Resolverless DNS’ possible.
Another open challenge appearing on the horizon is the emergence of quantum computers and the potential threat they could pose on DNS message integrity. There are still many open questions about the development of quantum computers and their actual impact on the DNS. Nevertheless, we believe it is necessary to discuss how we can secure the DNS also in a quantum world. First steps have been made, but more research needs to be done.
Availability
Due to its crucial role on the Internet, information stored in the DNS must be available to anyone all the time. The DNS protocol already has several approaches in place that enable operators to increase the resilience of their DNS systems. For example, they can replicate their zone files across multiple name servers spreading load and increasing availability. Recursive resolvers, in turn, automatically query the second name server if the first becomes unavailable. Other, more elaborate solutions exist and are used widely, and we describe them in our paper in more detail.
But, as with other protocols and applications on the Internet, Denial of Service Attacks (DoS) remain a threat and additional solutions to guarantee availability of the DNS are welcome.
One possible solution to DoS attacks also causes problems — the concentration of DNS services at a few providers. While these providers can deploy more and more resources to handle such attacks, this also increases centralization in the DNS ecosystem. Centralization not only raises privacy concerns but also increases the impact of an outage of one of these providers. Solutions that increase availability without leading towards more centralization are still needed.
Abuse
Misuse of domain names to facilitate or coordinate malicious activities on the Internet remains a problem. Many techniques to detect and mitigate such misuse exist, and we discuss those in our paper. Often, however, these techniques only work for a limited period or only for specific use cases. Also, some problems with DNS abuse are inherent in the design of the protocol itself. This includes the fact that DNS relies mainly on UDP for transport, which enables spoofing of DNS messages. DNS over HTTPS and DNS over QUIC address this problem to some extent but are likely not a solution on a wider scale due to their potential performance impact. DNS cookies address this issue without changing the transport protocol but are not widely deployed yet.
Ironically, solutions to one challenge can introduce new problems for others. Encryption of DNS messages, for example, addresses the challenge of confidentiality but operators fear that it makes detecting misuse of the DNS for malicious purposes harder. We still need to find a balance between these two.
Getting inspired by other naming systems
While DNS is the only naming system that is widely deployed on the Internet, alternative naming systems do exist. We were wondering if those naming systems address the challenges in the DNS and whether we can use them for inspiration.
In particular, we look at blockchain-based naming systems and systems used in other Internet architectures like SCION or NDN. None of them provide a perfect solution to the discussed challenges and have their own unique problems. Some of their design choices, like the inherent encryption in the case of SCION’s naming system RAINS, or the goal to distribute name resolution as much as possible in the case of blockchain-based naming systems, could inspire solutions that may also be applicable to the DNS. Our hope is that the tutorial’s second perspective may inspire and motivate academics and the wider DNS community to embark on new research and develop new solutions.
Want to know more?
Following publication in the Elsevier Computer Science Review, access to our paper is now open. Fancy taking a look? The tutorial is available to download (PDF) from our website, or to read online. We hope that our paper will help you to follow and contribute to more complex DNS community debates, such as those that take place within the IETF.
Moritz Müller is a research engineer at SIDN Labs and a fourth-year PhD candidate at the University of Twente, the Netherlands.
This is an extended version of an article previously published at sidnlabs.nl.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.