The Domain Name System (DNS) has been operated as a plaintext-based service by default since its first proposal in 1984. While it serves us well by converting human-readable domain names to machine-friendly IP binaries and vice versa, the plaintext nature of the DNS makes the service lightweight and could put user privacy at risk. Therefore, encrypting DNS lookups from clients is now in rapid development.
In this post, I briefly walk through a problem that motivates encrypted DNS, standard protocols (as RFCs), adoption status, common vulnerabilities, and practical problems that could slow down its public adoption.
DNS encryption as a viable approach to protect user privacy
A typical domain name lookup via plaintext DNS is shown in Figure 1.
The client asks its local DNS resolver the question ‘what is the IP address of a.i.com?’ (step 1). The resolver then performs a sequence of recursive lookups toward DNS servers at different levels of the hierarchy until it returns an answer to the client (steps 2, 3, and 4). Although the low-cost process seems perfectly effective, malicious actors could easily eavesdrop or hijack the requests between the client and resolver (step 1), which put user privacy at risk.
To address the privacy concern, our Internet community is proposing standard protocols to encrypt the vulnerable part of DNS communications, which will be discussed next. It is also worthwhile to note that recursive lookups between the resolver and authoritative name servers (steps 2, 3, and 4) do not directly contain client information, therefore, do not suffer from this problem.
Standard DNS encryption methods as RFCs
There are three standardized protocols (shown in Figure 2) that have been proposed as IETF RFCs.
DNS-over-TLS (DoT): Released in 2016, it directly encrypts DNS content using the TLS layer, which has been proven to be effective in encrypting many other application layer protocols such as SMTP, HTTP, and VoIP. Like other secured protocols, it uses a dedicated port number TCP/853 on the resolvers. However, this newly assigned port number is still not accepted by many security firewalls, which become a known stopper for its public adoption.
DNS-over-HTTPS (DoH): It uses existing HTTPS (TLS+HTTP) encryption capability via service port TCP/443 that is well accepted by current security infrastructures. As it is built upon HTTPS, DoH benefits from many existing performance enhancements designed for HTTPS and is also more browser-friendly than DoT. As reported by academia, it is not the most popular encrypted DNS on the market.
DNS-over-QUIC (DoQ): Similar to DoH except it uses QUIC protocol over UDP and has just been finalized as RFC 9250 in 2022 after the draft phase.
Adoption status
The above-mentioned protocols (mostly DoH) have been widely supported by the two sides, that is, user applications and resolvers. Some of the popular resolver providers, operating systems, and browsers are listed in Figure 3. However, a client has to deliberately select an encrypted DNS server and enable the encryption option on the OS or browser, which makes it not possible for many users who often go with default settings or do not have a technical background.
Common issues in the current encrypted DNS
Although encrypting DNS lookups between the client and public resolvers are primarily for the protection of user privacy, if not properly or securely operated, there are issues that could impair the trustworthiness of encrypted DNS services. The three frequently discussed by academia are:
Invalid SSL certificates: Recent academic studies show that a negligible fraction of SSL certificates on encrypted DNS resolvers are invalid or expired, which makes the resolvers not trustable by the user. Although many of the invalid ones may not be currently in use, it is not good practice for letting them be reachable on the Internet.
Fallback attacks: By creating spoofed negotiations (one such possible way is through man-in-the-middle) with the resolver on behalf of a client, attackers are capable of forcing the encrypted resolver to provide DNS service via plaintext.
Imperfect padding strategies: Encrypted DNS packets could be padded to a certain length so that smart hackers would not be able to infer the requested domain name by analysing packet lengths, which has been proven effective. However, as studied by academia, a significant fraction of encrypted DNS packets is not properly padded, thus, leaving space for privacy leakage.
More discussion on practical issues and security vulnerabilities can be found in this paper.
Practical barriers to better public adoption
There are practical barriers to the adoption of encrypted DNS from existing Internet infrastructures; some are given in Figure 4. For simplicity, we examine ‘enterprise security’ as an example.
As a common practice, enterprise network security tools like border firewalls and intrusion detection systems could be configured to block certain domains identified as harmful or illegal and drop malicious DNS requests (for example, asking irrelevant domains) to their organizational DNS servers. Encrypted DNS would render such established security measures as well as others listed in Figure 4 invalid. Therefore, better public adoption of encrypted DNS requires proper alternatives or solutions to those existing methods that inspect plaintext DNS.
While DNS encryption is developing a more trustable and reliable future for domain name lookups, just like many other emerging technologies, its successful public adoption at scale requires our community to put more effort into addressing its vulnerabilities and practical barriers.
Interested readers should refer to our paper published in ACM Computing Surveys for details.
Minzhao Lyu is currently a postdoctoral research associate at the University of New South Wales, Sydney, Australia, where he received a B.Eng. degree (First Class Hons.) in electrical engineering and a PhD in network security in 2017 and 2022, respectively. His research interests include network traffic analytics, programmable networks, network security, and machine learning for network problems.
Contributors/co-authors of the original paper: Hassan Habibi Gharakheili and Vijay Sivaraman.
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.
Very good. Thanks.
Hello plz one confing