A Survey on DNS Encryption: Current Development, Malware Misuse, and Inference Techniques

by   Minzhao Lyu, et al.

The domain name system (DNS) that maps alphabetic names to numeric Internet Protocol (IP) addresses plays a foundational role for Internet communications. By default, DNS queries and responses are exchanged in unencrypted plaintext, and hence, can be read and/or hijacked by third parties. To protect user privacy, the networking community has proposed standard encryption technologies such as DNS over TLS (DoT), DNS over HTTPS (DoH), and DNS over QUIC (DoQ) for DNS communications, enabling clients to perform secure and private domain name lookups. We survey the DNS encryption literature published since 2016, focusing on its current landscape and how it is misused by malware, and highlighting the existing techniques developed to make inferences from encrypted DNS traffic. First, we provide an overview of various standards developed in the space of DNS encryption and their adoption status, performance, benefits, and security issues. Second, we highlight ways that various malware families can exploit DNS encryption to their advantage for botnet communications and/or data exfiltration. Third, we discuss existing inference methods for profiling normal patterns and/or detecting malicious encrypted DNS traffic. Several directions are presented to motivate future research in enhancing the performance and security of DNS encryption.


page 4

page 5

page 16

page 19

page 20


Measuring the Accessibility of Domain Name Encryption and Its Impact on Internet Filtering

Most online communications rely on DNS to map domain names to their host...

Large Scale Measurement on the Adoption of Encrypted DNS

Several encryption proposals for DNS have been presented since 2016, but...

Masking Host Identity on Internet: Encrypted TLS/SSL Handshake

Network middle-boxes often classify the traffic flows on the Internet to...

QPEP: A QUIC-Based Approach to Encrypted Performance Enhancing Proxies for High-Latency Satellite Broadband

Satellite broadband services are critical infrastructures enabling advan...

Encrypted and Covert DNS Queries for Botnets: Challenges and Countermeasures

There is a continuous increase in the sophistication that modern malware...

A Survey of HTTPS Traffic and Services Identification Approaches

HTTPS is quickly rising alongside the need of Internet users to benefit ...

Discovering Encrypted Bot and Ransomware Payloads Through Memory Inspection Without A Priori Knowledge

Malware writers frequently try to hide the activities of their agents wi...

1. Introduction

The domain name system (DNS) protocol (rfcDNS1987) takes the responsibility of converting human-readable domain names into machine-friendly IP addresses and vice versa, which is critical to the Internet communications today. We start by illustrating the basic operation of DNS in Fig. 1: a client embeds its question (typically for domain names) in DNS queries and sends them to DNS resolvers for lookups of the answers (step [colframe=black,colback=white,shrink tight,boxrule=0.5pt,extrude by=1mm]1). The resolver then performs recursive lookups of the questioned domain name by successively/recursively querying a root server, top-level-domain (TLD) server, and authoritative name server (steps [colframe=black,colback=white,shrink tight,boxrule=0.5pt,extrude by=1mm]2, [colframe=black,colback=white,shrink tight,boxrule=0.5pt,extrude by=1mm]3, and [colframe=black,colback=white,shrink tight,boxrule=0.5pt,extrude by=1mm]4 in Fig. 1, respectively).

The DNS ecosystem presents various types of security and privacy risks that could be exploited by malicious actors. For example, DNS resolvers and name servers often become attractive targets of denial-of-service (DoS) attacks that slow down or even paralyze their services. For countermeasures, there exist specialized security systems and appliances that are able to detect and mitigate DoS attacks on DNS infrastructures included (BHiteshCCS2008; MLyuTNSM2021). It is also a common practice for attackers to mislead clients by fake responses (DNS spoofing and/or hijacking), directing them to malicious servers. To tackle this problem, DNSSEC (rfcDNSSEC2005) was proposed for protecting the data integrity of DNS. It provides cryptographic verification through digital signatures that can be used to validate the records delivered in a DNS response from the authoritative DNS server. Furthermore, as shown in Fig. 1, DNS queries and responses are communicated as plaintext via UDP transport-layer protocol which offers various benefits such as low computational overheads, fast resolution, and ease of deployment and management (DoHThreatLandscape). However, malicious actors take advantage of unencrypted contents, putting user privacy at risk (YORK201041) or spoofing (XBaiWISM2011) DNS lookups between clients and resolvers. To address privacy concerns, encrypting DNS lookups (exchanged between client and resolver) has been developed and promoted, which is the focus of this survey.

Figure 1. A visual example of DNS lookup activities from a client and the potential threats introduced by malicious actors.
DoH DoT DNS over HTTPS DNS over TLS DoQ DNS over QUIC DNS Encrypt # Total
IEEE Xplore (IEEEXplore) 4 0 4 0 0 0 0 8
ACM Digital Library (ACMDL) 4 3 5 3 0 0 5 19
ScienceDirect (ScienceDirect) 0 0 2 0 0 0 0 2
USENIX Proceedings (USENIXProceedings) 2 0 0 0 0 0 0 2
Springer Link (SpringerLink) 1 0 0 1 0 0 1 3
Wiley Online Library (WileyOnlineLibrary) 0 0 0 0 0 0 0 0
Web of Science (WebOfScience) 0 0 0 0 0 0 0 0
Google Scholar (GoogleScholar) 0 0 8 0 0 0 0 8
Overall 11 3 19 4 0 0 6 43
Table 1. Number of unique peer-reviewed papers retrieved from eight major libraries by title keywords.

Various techniques of DNS encryption have been developed, experimented with, and deployed across the Internet over the past few years to protect user privacy. Some early proposals such as DNSCurve (rfcDNSCurve2010) and DNSCrypt (DNSCrypt2018) were introduced in 2008 and 2011 (MSehring2020), respectively. However, none of them became officially standardized, and hence are not widely deployed by the Internet community. To facilitate the adoption of DNS encryption, the Internet Engineering Task Force (IETF) has proposed a series of standards (RFCs) starting from 2016, relying upon existing secure/private protocols, including DNS over TLS (DoT) (rfcDNSTLS2016), DNS over HTTPS (DoH) (rfcDNSHTTPS2018), and DNS over QUIC (DoQ) (rfcDNSDoQ2021). Currently, the public adoption of encrypted DNS (compared with plaintext DNS) is still relatively low, but several major Internet technology and service providers such as Google, Cloudflare, Cisco, and Alibaba have launched their encrypted DNS resolvers (DOHServerLists), fueling the growth of encrypted DNS traffic on the Internet (SGarciaARXIV2021).

Regardless of the benefits brought by DNS encryption, some practical issues and security problems have been identified by the existing literature, impacting its public adoption. For example, encrypted resolution may not be feasible if encryption-enabled DNS resolvers fail to provide a valid certificate. Unfortunately, as reported in (CLuIMC2019), lack of best practice encryption setups is not uncommon in today’s public encrypted DNS resolvers. Moreover, inappropriately configured DNS resolvers are vulnerable to fallback (downgrade) attacks (e.g., SSL stripping), forcing resolvers to return DNS responses in plaintext.

Figure 2. Key contributions and structure of this survey paper.

Among those practical issues, the misuse of DNS encryption by malware is one of the problems that has attracted attention from the security community. Cybercriminals can easily hide their identities and activities via encrypted DNS traffic to bypass legacy security tools and appliances. Many monitoring and detection methods today rely on DNS packet content inspection, which is highly effective in processing plaintext-based DNS communications. Existing literature has reported that malicious actors use encrypted DNS for command-and-control (C&C) communications and/or exfiltrating and tunneling data between malware-infected devices and cloud-based servers – further details will be discussed later in §3

. To tackle the malicious usage of DNS encryption by malware, researchers have developed various analytical methods to detect encrypted DNS packets from network traffic and classify benign and anomalous streams. In addition, there are also research works that profile user behaviors by analyzing encrypted DNS traffic. Prior works collectively provide solid insights into challenges and opportunities, and motivate future researches in detecting and fingerprinting malware-infected devices that utilize encrypted DNS for stealthy communications.

This survey is the first to comprehensively review relevant literature on DNS encryption techniques, their opportunities, and risks. To guarantee that our survey has a full coverage of peer-reviewed papers in the domain of DNS encryption, we searched seven title keywords from eight major scientific digital libraries such as IEEE Xplore and ACM Digital Library – the entire list along with the number of peer-reviewed papers identified by key words in each library are shown in Table 1. We made sure that duplicate counting is avoided – a paper already found in a library (e.g., IEEE Xplore) is excluded from being counted against other libraries (e.g., Google Scholar). In addition, we incorporated relevant Internet standard documents (RFCs), technical reports from reputable organizations, and research papers that do not directly focus on encrypted DNS to cover certain key points around DNS encryption.

Category of topics covered by this survey List of references
Standardized DNS encryption methodologies (PWu2019; rfcDNSTLS2016; rfcTLS2008; RKartch2017; HTTPSOnly; rfcDNSHTTPS2018; DFisher2020; rfcDNSDoQ2021; rfcQUIC2021; AGhedini2019; TBucutiISI2015; GCarlucciSAC2015)
Adoption and performance (MVale2019; DNSEncryptedResolver; DoHResolver; VBagirov2020; SGarciaARXIV2021; MCWasastjernaECJ2018; TANideck2019; CHesselmanIC2020; PWu2019; ANisenoffDNSPW2021; SDeckelmann2020; ZYanFGCS2020; HShulmanWPES2014; AHounselANRW2019; TBottgerIMC2019; KBorgolteEJ2019; AHounselWWW2020; ESMbeweAFRICOMM2021; TNDoanPAM2021; AHounselPAM2021; RChhabraIMC2021)
Benefits of DNS encryption (HShulmanWPES2014; ZYanFGCS2020; KBumanglagICICT2020; MAnagnostopoulosCS2013; LZhuSP2015; NNayakICCSIT2010; PJeitnerDSNS2020)
Practical issues and security vulnerability (LJinWWW2021; SRiveraARES2020; YNakatsukaACSAC2019; YNakatsukaDT2021; CLuIMC2019; jahromi2021comparative; DShinACSAC2011; QHuangFOCI2020; RHouserCoNEXT2019; rfcDNSPadding2018; KHynekIEMCON2020; JBushartFOCI2020; KRadinsky2015; PSchmittANRW2019; rfcODNS2021; AHounselANRW2021; MLyuPAM2019; JAhmedTNSM2020; MLyuTNSM2021; DoHThreatLandscape; PBischoff2021; ZYanFGCS2020; HHabibiGharakheiliCAN2017; CCimpanu2019; hynek2020doh; MSinghDI2019; KAlieyanNCA2017)
Malware misuse: command and control (C&C) communications (CommandAndControl; KXuTDSC2013; JLeeWSNP2010; AUdiyonoICONETSI2020; YZengCN2021; LBilgeNDSS2011; CJDietrichEC2ND; CPatsakisCS2020; Godlua2019; PsiXBot2019; KBumanglagICICT2020; MGrillIM2015)
Malware misuse: data exfiltration (or tunneling) (FUllahJNCA2018; ANadlerCS2019; BSabirCS2022; CCimpanu2020; ExfilDoHTool2; ExfilDoHTool; XHuDSN2016; JAhmedTNSM2020; DHaddonICGS32019)
Detecting and classifying encrypted DNS traffic (CPatsakisCS2020; DVekshinARES2020; DVekshinARES2020; vekshin_dmitrii_2020_3906526; LCsikorESP2021; CKwan2021FOCI; MMontazeriShatooriDASC2020; CIRACICDoHBrw2020; SKSingh3ICT2020; YMBanadakiJCSA2020; MBehnkeAccess2021)
Profiling user activities by analyzing encrypted DNS analysis (RHouserCoNEXT2019; rfcDNSPadding2018; SDSibyNDSS2020; siby2018dns; MMuhlhauserARES2021; MMulhauser2021; GVarshneyCOMSNETS2021)
Table 2. List of references cited in each category of DNS encryption research.

Fig. 2 depicts key contribution and structure of this survey. We also list the references cited in each of the eight subsections in Table 2. The contributions of this survey paper can be summarized as follows:

  • First, we outline the current development of DNS encryption, highlighting aspects like standard techniques (i.e., DoT, DoH, and DoQ), the current status of their adoption across the Internet, performance analysis, benefits, practical issues, and security vulnerabilities identified by the current literature (in §2).

  • Second, we discuss how DNS encryption can be misused by malware for purposes including command-and-control (C&C) communications and data exfiltration, with highlights on the (in)effectiveness of existing countermeasures originally developed for plaintext DNS when applied to encrypted DNS (in §3).

  • Third, we survey the current analysis and inference methods for detecting encrypted DNS traffic from generic encrypted network streams (e.g., HTTPS), classify malicious encrypted DNS communications, and fingerprint host profiles by analyzing encrypted DNS traffic. They provide strong references and motivations for future research in detecting malware-infected devices that exploit encrypted DNS protocol (in §4).

Moreover, four research directions in the field of DNS encryption are identified in §5; the related surveys on DNS security are discussed in §6; this survey is concluded in §7.

2. DNS Encryption: Methodologies, Adoption & Performance, Benifits, and Issues

Encrypting DNS queries and responses between clients and resolvers holds the promise of protecting user privacy against eavesdroppers and man-in-the-middle (MITM) attackers (PWu2019). In this section, we review the development of DNS encryption by highlighting current standard techniques (§2.1), their adoption status and performance impacts (§2.2), benefits provided by DNS encryption (§2.3), and its open issues and security vulnerabilities (§2.4).

Figure 3. The structure of packet layer (starting from IP layer) of plaintext DNS, encrypted DNS over TLS, encrypted DNS over HTTPS, and encrypted DNS over QUIC.

2.1. Standard Methods of DNS Encryption

In general, DNS encryption is achieved by encapsulating the content of queries and responses (between clients and resolvers) in an upper layer protocol that encrypts the packet content using available cryptographic techniques. To date, there are three standardized DNS encryption methods, each utilizing a specific upper-layer protocol, including DNS-over-TLS (DoT), DNS-over-HTTPS (DoH), and DNS-over-QUIC (DoQ), ordered by their time of proposal. As illustrated in Fig. 3, unlike the plaintext-based DNS that is directly embedded under the UDP transport layer, the three DNS encryption methods encapsulate DNS in their encryption-enabled layer, i.e., TLS, TLS with HTTP (i.e., HTTPS), and QUIC, respectively.

2.1.1. DNS over TLS (DoT)

This is the first standard protocol proposed for DNS encryption that has its RFC (rfcDNSTLS2016) published in 2016. It uses a Transport Layer Security (TLS) layer under the TCP transport layer to encrypt DNS queries and responses. Before being applied to the DNS applications, TLS has proven its efficacy in encrypting popular network applications such as email (SMTP), hypertext (HTTP), and voice-over-IP (VoIP).

During DNS lookups, the client first initiates a TLS connection with its intended DoT-enabled resolver via a typical TLS handshake process, exchanging their cryptographic keys (rfcTLS2008). Upon successful establishment of the TLS session, the client is able to perform TLS-encrypted DNS lookups to a designated DoT port TCP/853 on the resolver side. Depending on the configurations of clients and servers, the TLS connection may remain open for further DNS lookups to reduce computational overheads introduced by additional handshakes.

Although DoT is a viable approach for DNS encryption, it faces several practical challenges that may limit its usage. The first concern is that, as reported in (RKartch2017), the port TCP/853 dedicated to DoT services is currently not well recognized by the security community thus is likely to be blocked by firewall appliances. While the content of queries and responses is encrypted, anyone can know that TCP/853 carries DNS-related traffic, and hence not perceived a privacy-friendly protocol. Another shortcoming of DoT is that it requires application developers and hardware manufacturers to support the protocol – if not supported, users may still go unprotected. For example, major web browsers like Google Chrome only allow the HTTPS protocol (HTTPSOnly) for secures communications. This has negatively impacted the public adoption of DoT protocol that is directly built on TLS instead of HTTPS (i.e., TLS with HTTP).

2.1.2. DNS over HTTPS (DoH)

DoH (rfcDNSHTTPS2018) has been standardized in 2018 to address the practical difficulties of DoT discussed above. Anyone using a supported web browser automatically benefits from encrypted DNS. It utilizes the widely-used HTTPS protocol (i.e., TLS with HTTP as depicted in Fig. 3) to encapsulate DNS contents, delivered via the service port TCP/443 so that existing security measures would not hinder its transmission. DoH is also more acceptable on the client-side as HTTPS is the default (or the only enabled) hypertext protocol used by major browsers. From a privacy viewpoint, DoH is more preferred than DoT since DNS traffic is mixed with other applications (e.g., Web) exchanged over HTTPS. In addition, any future performance and security enhancements for HTTPS would also benefit DoH. Given the above practical benefits, DoH has become the most popular DNS encryption method used by the current Internet industry (DFisher2020).

2.1.3. DNS over QUIC (DoQ)

The transport-layer protocol of both DoT and DoH is TCP. Thus, their overhead (due to TCP & TLS handshakes for connection establishment plus TCP acknowledgment) is non-negligible. Therefore, DoQ (rfcDNSDoQ2021) was first proposed in 2017 by Google as an Internet draft (not officially finalized as an RFC yet) to further improve the performance of encrypted DNS. It leverages QUIC (rfcQUIC2021) protocol (built on the top of UDP transport layer) that enables faster and lighter encrypted communications by zero-RTT handshakes (AGhedini2019) and multiplexing data streams. As reported by (GCarlucciSAC2015), QUIC empirically outperforms its competitor HTTPS in response quality metrics like page load times.

Despite its performance merits, similar to DoT, DoQ uses dedicated service ports (UDP/784 and UDP/8853) that are not well-recognized by security systems at present time, therefore, its traffic might get blocked (as the default option) by firewalls during transmission.

2.2. Adoption and Performance of DNS Encryption

Having understood the current DNS encryption techniques and protocols, we now discuss their state of adoption across the Internet as well as their performance reported by the data networking community.

2.2.1. Current State of Public Adoption

As described in §2.1, DNS encryption is applied for the queries and responses between clients and resovlers, and hence, the public adoption highly depends on the technical supports from two key stakeholders, i.e., public resolvers and user applications (e.g., browsers and operating systems).

Public Resolvers: A few public resolvers, mostly operated by major cloud providers such as Google and Cloudflare, start to support DNS encryption since 2019 (MVale2019), followed by many other providers such as AdGuard, Alibaba, Cisco, Comcast, and Quad9. According to (DNSEncryptedResolver) and (DoHResolver), there are at least seven DoT-enabled and 62 DoH-enabled public resolvers on the Internet. AdGuard announced (VBagirov2020) the support of DoQ on their public resolvers since December 2020, though this protocol is still in its experimental stage.

The public adoption of DNS encryption holds a growing promise, evidenced by its increasing Internet-wide traffic volumes (SGarciaARXIV2021). However, it is dominated by a small number of major service providers, raising concerns of data monopolization (MCWasastjernaECJ2018). Also, there are oppositions, like the UK Internet Services Providers’ Association (ISPA) (TANideck2019), who argue that DNS encryption can bypass existing filtering obligations, thus undermine the Internet safety standards.

Option Description
Off Plaintext without attempting to apply encryption for DNS communications.
Opportunistic/Automatic (TBucutiISI2015) Apply encryption if possible by both client and server; otherwise, plaintext DNS (if no encryption protocol is available/possible).
Strict Apply specified encrypted DNS protocols.
Table 3. DNS encryption options provided by user applications.

User Applications: DNS encryption is increasingly supported by a variety of end-user platforms and applications including operating systems for mobile and desktop devices, Internet broswers, and even IoT devices (CHesselmanIC2020). As reported by (PWu2019), major operating systems including Android, iOS, Linux, macOS, and Windows have included DoH features in their latest versions. Similarly, popular Internet browsers such as Firefox, Chrome, and Opera also offer DNS encryption options to their users – “Off”, “Opportunistic” (or “Automatic”), and “Strict”. By the “Off” mode, DNS lookups will be performed via plaintext. For the “Opportunistic” mode, a client and its resolver try to agree on a DNS encryption protocol that is available on both sides. However, plaintext data exchange is used if no agreement can be made. For the “Strict” mode, DNS lookups can only be performed via a certain encryption protocol specified by the user. Their short descriptions are also summarized in Table 3.

However, according to an online survey studying the attitude of clients towards DNS encryption (ANisenoffDNSPW2021), users are quite reluctant and reactive to accept DNS encryption. Majority (67%) of the surveyed population selected the Opportunistic option followed by Strict (20%) and Off (13%) options. This indicates that the adoption of DNS encryption would be highly contingent on how easily application developers enable DNS encryption features on their application, without additional manual configurations from users. One such good example is that Firefox start to bring DoH as its default DNS protocol for their U.S. based users since 2020 (SDeckelmann2020).

2.2.2. Performance Analysis

Compared with UDP-based DNS in plaintext, encrypted DNS requires additional communication steps for exchanging cryptographic keys (e.g., TLS handshake) and TCP communications (e.g., TCP handshake and payload acknowledgment). Therefore, introducing encryption to DNS inevitably brings more computational and communication overheads that might not be favorable to sensitive applications (e.g., website fetching) (ZYanFGCS2020; HShulmanWPES2014). A number of research articles have attempted to quantify the performance implications of DNS encryption by empirically measuring various metrics such as page load time, DNS resolution time, or query response time across a range of access network types (e.g., cellular, campus, or home networks), and resolvers. Their setup details are summarized in Table 4, and will be explained next.

Work Protocols Key performance metrics Access network types Target resolvers
(AHounselANRW2019) DNS, DoH, DoT page loading time 3G, 4G, campus networks Cloudflare
(TBottgerIMC2019) DNS, DoH, DoT query resolution time, page loading time not specified one local resolver, Google, Cloudflare
(KBorgolteEJ2019) DNS, DoH page loading time 4G, campus networks Google, Cloudflare, Quad9
(AHounselWWW2020) DNS, DoH, DoT query resolution time, page loading time five different ISP networks Google, Cloudflare, Quad9
(ESMbeweAFRICOMM2021) DNS, DoH, DoT DNS resolution time, page loading time mobile, community, and educational networks local and five public resolvers
(TNDoanPAM2021) DNS, DoT query resolution time, failure rate home networks (mainly in NA & EU) one local and 15 public resolvers
(AHounselPAM2021) DNS, DoH, DoT query resolution time, latency home networks in MBA program three anonymized public resolvers
(RChhabraIMC2021) DNS, DoH query resolution time, number of requests per connection clients from 2190 different autonomous systems Cloudflare, Google, Quad9, NextDNS
Table 4. A summary of measurement setup in prior works on performance analysis of DNS encryption.

The authors of (AHounselANRW2019) studied the impact of DNS options (plaintext DNS, DoH, and DoT) on the load time of web pages in various networks including 3G, 4G, or campus wired networks. Their work highlights that DoT gives the best performance in page load time followed by DoH and plaintext DNS in both near ideal (university network) and lossy (3G and 4G) networks. The authors of (AHounselANRW2019) believe that it is possibly because TCP (employed by DoT and DoH) has shorter timeout thresholds than UDP (employed by plaintext DNS). Furthermore, T. Bottger et al. (TBottgerIMC2019) quantified the overhead of DNS encryption in resolution time and page load time introduced by the TLS layer (in DoT and DoH) and HTTP layer of version 1.1 and 2.0 (in DoH). They concluded that both DoT and DoH via HTTP1.0 have significant performance degradation due to the head-of-line blocking problem, while DoH using HTTP2.0 is more promising as it results in similar delays compared with plaintext DNS. K. Borgolte et al. (KBorgolteEJ2019) investigated the page load time of DoH and plaintext DNS under mobile and campus network scenarios using three different open resolvers by Google, Cloudflare, and Quad9. The authors revealed that only the DoH service of Cloudflare under the university network gives the most reasonable load time while other combinations incur significant delays of up to several seconds. Therefore, poor network conditions and sub-optimal provider selections may widen the performance gaps between DNS and DoH. The work in (AHounselWWW2020) highlights that the performance (response time) of DoT and DoH is better than that of plaintext DNS in slightly lossy network conditions (e.g., cellular network). This is because it takes a longer time for UDP (plaintext DNS) to detect a lost query, while TCP can quickly react and transmit the lost packet over an existing connection. Given its connection-less property, UDP achieves a shorter response time than TCP in ideal situations (lossless network). Also, if the the network becomes heavily lossy (e.g., 3G network in remote location), UDP-based DNS outperforms TCP-based versions (DoH and DoT), since the time for connection establishment would dominate and UDP would have time to react on losses.

From the above studies, it is quite clear that DNS encryption protocols perform not so well when network conditions are less ideal. This remark has also been drawn from measurement research works done on edge networks (RChhabraIMC2021; ESMbeweAFRICOMM2021; TNDoanPAM2021; AHounselPAM2021) (e.g., home) that have substantial distance from the essential Internet infrastructures. By measuring DoH resolution times from 22K unique hosts across the world, the authors of (RChhabraIMC2021) found that hosts in high-income countries/regions with better Internet infrastructure are less likely to have performance degradation. At the same time, clients from less-developed areas experience a significant slowdown by switching from plaintext DNS to DoH. Furthermore, E. S. Mbewe et al. measured the performance of DoH, DoT, and plaintext DNS of hosts in Africa (ESMbeweAFRICOMM2021) and observed high latency and circuitous DNS resolution paths for encrypted DNS packets. The authors of (TNDoanPAM2021) measured DoT lookups from 3.2K RIPE Atlas probes deployed in home networks and obtained high failure rates (up to 32%) and equivalent response times (around 150ms) compared with plaintext DNS, which had its low failure rates of less than 3%. Lastly, A. Hounsel et al. (AHounselPAM2021) performed measurements on more than 2500 home networks participating in a Measuring Broadband America program by the Federal Communications Commission (FCC). They highlighted that DNS clients could periodically conduct active probing in order to select their optimal user settings in terms of the choice of protocol (DoT or DoH) and resolvers that give satisfying performance for each home network.

2.3. Benefits of DNS Encryption

Regardless of some performance issues, the industry has advocated encrypted DNS due to its unprecedented benefits such as protecting user privacy and preventing certain attacks that exploit the connectionless property of UDP.

2.3.1. Protecting User Privacy

The risk of end-user privacy leakage is present in various nodes across the path of DNS lookups, shown in Fig. 1. As highlighted by works in (HShulmanWPES2014; ZYanFGCS2020), eavesdroppers may monitor:

  • DNS queries and responses through the links between clients and recursive resolvers.

  • DNS logs from recursive resolvers.

  • DNS queries and responses through the links between recursive resolvers and authoritative name servers.

  • DNS logs from authoritative name servers.

Among these four risks, the first one is of the highest importance since both the client identity and the domain name are exposed to malicious actors who perform passive traffic sniffing. Retrieving logs from recursive resolvers (the second risk listed above) would result in the same outcomes for adversaries; however, it requires them to compromise the servers, which is more challenging than traffic eavesdropping. On the other hand, plaintext DNS lookups between resolvers and name servers can only reveal an aggregate profile of (e.g., millions of) users served by the public recursive resolver without exposing the identity of individual users. Also, the logs from authoritative name servers do not give away individual user information. DNS encryption protocols, therefore, are primarily designed to protect queries and responses from third-parties, eavesdropping between clients and recursive resolvers (KBumanglagICICT2020), as decrypting ciphertext would be largely impractical without knowledge of the secret key.

2.3.2. Preventing Network Attacks on UDP-based DNS

In addition to preserving user privacy, applying encryption techniques to DNS traffic requires the establishment of a secure connection (e.g., TLS, HTTPS, or QUIC) between the client and intended resolver. It changes the connectionless nature of legacy (plaintext) DNS exchanged via port UDP/53 that may be exploited by malicious actors for various types of network attacks (discussed next). Therefore, applying encryption prevents certain network attacks in the DNS ecosystem. For example, DNS amplification attack is a popular form of distributed denial of service (DDoS) that relies on the use of publicly accessible open DNS servers to overwhelm a victim system with DNS response traffic (MAnagnostopoulosCS2013). Attackers often craft small-sized DNS queries with source IP addresses spoofed to be a victim’s address and send them to resolvers. When resolvers send the DNS record response, it is sent instead to the victim (never requested anything). Attackers will typically submit a request for as much zone information as possible to maximize the amplification effect. Because the size of the response is larger than the request, the attacker is able to increase the amount of traffic directed at the victim. Such attacks are hard to be prevented by the resolvers if DNS queries arrive over connectionless protocol – resolvers are unable to determine whether a query is with spoofed source IP addresses or not. DNS encryption protocols, instead, prevent (LZhuSP2015) this problem by requiring a connection to establish via handshaking processes. Therefore, no large-sized DNS response could be sent to a (spoofed) victim IP address.

In addition, the authors of (LZhuSP2015) demonstrated that direct DDoS attack on DNS servers is weakened by DNS encryption. This is because attackers need to establish TCP and TLS connections for each attempt of attack (i.e., malicious DNS lookup), leading to higher computing resources required to overwhelm a DNS server. Lastly, encrypting DNS communications between clients and resolvers also reduces the chance of man-in-the-middle (MITM) DNS spoofing attacks (NNayakICCSIT2010) that aim to mislead (i.e., redirect) clients towards malicious destination IP addresses by hijacking and manipulating DNS responses. As a use-case, authors of (PJeitnerDSNS2020) developed a secured addressing mechanism using DoH for network time protocol (NTP) systems to prevent the off-path attacks (JPhilippDSN2020) which redirect clients to malicious timing servers via manipulated DNS responses.

Practical issues and security vulnerabilities References
Privacy leakage by compromised resolvers (§2.4.1) (LJinWWW2021; SRiveraARES2020; YNakatsukaACSAC2019; YNakatsukaDT2021)
Invalid SSL certificates (§2.4.2) (CLuIMC2019; jahromi2021comparative)
Fallback attacks (§2.4.3) (DShinACSAC2011; QHuangFOCI2020)

Imperfect padding strategies (§

(RHouserCoNEXT2019; rfcDNSPadding2018; KHynekIEMCON2020; RHouserCoNEXT2019; JBushartFOCI2020)
Problems of monopolized DNS resolution (§2.4.5) (KRadinsky2015; PSchmittANRW2019; rfcODNS2021; AHounselANRW2021)
Existing barriers for public adoption (§2.4.6) (MLyuPAM2019; JAhmedTNSM2020; MLyuTNSM2021; DoHThreatLandscape; PBischoff2021; ZYanFGCS2020; HHabibiGharakheiliCAN2017; AJMartin2019; CCimpanu2019; hynek2020doh; MSinghDI2019; KAlieyanNCA2017)
Table 5. Practical issues and security vulnerabilities of encrypted DNS highlighted by existing literature as discussed in §2.4.

2.4. Practical Issues and Security Vulnerability

As highlighted by recent research, although DNS encryption has brought significant enhancements in security and privacy, there are still unsolved issues and security vulnerabilities of encrypted DNS. Some of those include privacy leakage by compromised resolvers, invalid SSL certificates, fallback attacks, imperfect padding strategies, problems of monopolized DNS resolution, and existing barriers for public adoption, as listed in Table 5, discussed as follows.

2.4.1. Privacy leakage by Compromised Resolvers

As discussed in §2.3, current protocols (DoT, DoH, and DoQ) focus on the encryption of DNS communications between clients and recursive resolvers. However, malicious actors may still directly collect queried domain names of each client by compromising and taking control of a resolver. According to (LJinWWW2021), payload manipulation by compromised resolvers is not uncommon even for encrypted DNS. The authors performed more than seven million lookups towards thousands of DoT/DoH-enabled DNS resolvers. They observed that more than 1.5% of responses are manipulated according to their ground-truth records of domain names and the respective IP addresses.

To tackle this potential threat, work in (SRiveraARES2020) developed a privacy-preserving mechanism that leverages extended Berkeley Packet Filter (eBPF) to assist users in distributing their queries towards a set of resolvers randomly. That way, a compromised resolver would not expose the entire history of query records from a client. Y. Nakatsuka et al. (YNakatsukaACSAC2019; YNakatsukaDT2021) developed PDoT, an architecture that hosts recursive resolvers in a Trusted Execution Environment (TEE), so that they can be verified, authenticated, and trusted by end-users before performing DNS lookups.

2.4.2. Invalid SSL Certificates

The SSL certificates of DoT and DoH resolvers are provided to users as proof of their identities prior to the start of encrypted sessions (the process is known as SSL handshake). As reported in (CLuIMC2019), a non-negligible fraction (25%) of 150 DoT servers they studied have invalid SSL certificates that may impose privacy risks to clients as they cannot be verified as trusted entities. Similarly, the authors of (jahromi2021comparative) analyzed about SSL certificates collected from public DoT servers and found out that only 65% of them are checked as valid. In contrast, the popular reasons for invalidity include non-existent issuers, self-assigned certificates, expired certificates, and expired windows. In summary, given the above unsatisfying statistics on the validity of SSL certificates, the Internet community is expected to improve the trust of DNS encryption ecosystems to make them more acceptable to the public.

2.4.3. Fallback Attacks

According to §2.2, clients often use the “opportunistic” (or “automatic”) mode as their default option to establish encrypted connections with resolvers via the available DNS encryption protocol. Plaintext-based DNS will be used if both sides agree on no encryption protocol. Unfortunately, malicious actors may utilize this fact to stealth user privacy by forcing the clients to perform their DNS lookups in plaintext – it is known as fallback (or rollback/downgrade) attack (DShinACSAC2011).

As for the viability of fallback attacks, in (QHuangFOCI2020), Q. Huang et al. reported that four techniques could achieve such fallback, including DNS traffic interception, DNS cache poisoning, TCP traffic interception, or TCP reset injection. The authors have experimented with the four methods on six major browsers such as Chrome and Firefox. Although the response patterns exhibit variations, all tested browsers are found vulnerable to at least one of the four fallback techniques. Therefore, the authors suggested application developers revisit their encryption policies (e.g., notifying users if the plaintext is chosen) instead of simply leaving “opportunistic” as the default option.

2.4.4. Imperfect Padding Strategies

DNS encryption seems to be promising in protecting privacy by way of ciphertext. However, a recent research (RHouserCoNEXT2019) found that eavesdroppers can still infer the visited websites of clients with more than 99.5% accuracy through statistical features of DoT traffic such as the temporal patterns of packet sizes.

To prevent data leak from encrypted DNS messages via size-based traffic analysis, the Internet Society proposed a padding strategy in 2018 (rfcDNSPadding2018) that fills the DNS queries and responses to a certain size as configured by the users. However, according to (KHynekIEMCON2020), DNS message padding was not well supported (at least until 2020) by the majority of browsers such as Firefox that limits its public adoption.

Regardless of its public adoption, padding encrypted DNS packets is not a perfect solution against data leakage. Work in (RHouserCoNEXT2019) managed to achieve more than 80% accuracy in inferring visited websites by analyzing the temporal patterns of padded DoT messages. J. Bushart et al. demonstrated in (JBushartFOCI2020) how their method classifies (more than 85%) client device types and predicts (more than 65%) visited domains by combining the size and inter-arrival timing information of padded DoT and DoH from end-users.

2.4.5. Problems of Monopolized DNS Resolution

In the current ecosystem of encrypted DNS, a few major providers such as Google and Cloudflare dominate the market of public resolvers on the Internet. Instead, in plaintext DNS systems, recursive resolvers are well distributed across Internet service providers (ISP) and large public organizations. As discussed next, the related articles pointed out that such a monopolization (also known as centralization) can be detrimental to the reliability and usability of encrypted DNS resolution.

First, having a limited number of major providers dominating the ecosystem can lead to data monopolization (KRadinsky2015), which can threaten users’ privacy as they would be able to profile user online preference and behavior by their queried domain names. Apart from having more players in this ecosystem, researchers have developed novel methods like Oblivious DNS (ODNS) (PSchmittANRW2019) to alleviate this problem. The authors of (PSchmittANRW2019) propose to introduce a client proxy to operate between clients and public resolvers – client proxies receive queries from end-hosts and send them to respective recursive resolvers without revealing their identities. Therefore, with ODNS, monopolized service providers would not have the IP address of their clients. In 2021, ODNS over HTTPS (ODoH) has been standardized as an RFC (rfcODNS2021) to prevent the potential misuse of user data by resolver providers. We believe that it is an effective method yet requires public awareness before it is widely adopted.

Second, the monopolized DNS resolution via encrypted protocols provides a sub-optimal quality of service (e.g., resolution time) for user devices that require flexibility in setting their strategy for dynamic selection (depending on geolocation and network conditions) of recursive resolvers. To this end, the authors of (AHounselANRW2021) developed a refactored DNS resolver architecture that supports de-monopolized name resolution, enabling users to specify their lookup preference such as distributing queries across a set of DoH resolvers with certain latency requirements – provides an optimal and flexible selection of resolvers for edge devices. Their prototype evaluation demonstrated an improved performance while preserving user privacy.

2.4.6. Existing Barriers for Public Adoption

The encryption of DNS queries and responses significantly impacts the usability of legacy security measures that inspect plaintext DNS payload for inference and classification purposes. According to the current literature, we now enumerate some security functionalities that have been affected by DNS encryption.

  • Enterprise security via DNS monitoring: Legacy middleboxes for network security (e.g., border firewalls and network intrusion detection systems) can be configured to inspect DNS messages, gaining visibility into the role of connected assets (MLyuPAM2019) and/or detecting anomalous/malicious patterns (JAhmedTNSM2020; MLyuTNSM2021), indicative of DNS-based volumetric attacks, accessing illegal contents, or performing data exfiltration. However, payload inspection becomes relatively ineffective with the increasing adoption of encrypted DNS. Hence, new challenges (DoHThreatLandscape) such as lack of complete visibility into DNS traffic, losing control over DNS data, potential leakage of information, and inability to block illegal (inappropriate) contents emerge for enterprise network operators.

  • Internet censorship, parental control, and advertisement blocking: Internet censorship has been enforced at various levels by the government of many countries such as the U.S., China, and the U.K. (PBischoff2021) to restrict access to certain online services such as pornography, violence, and scandals. Also, monitoring DNS traffic has been used for home networks for parental control purposes (ZYanFGCS2020; HHabibiGharakheiliCAN2017). As criticized by relevant stakeholders such as the Internet Watch Foundation (AJMartin2019), with encrypted DNS such as DoH, users can easily bypass censorship imposed at home, organizational, ISP, or national level (CCimpanu2019). In addition, the efficacy of ad-blocking mechanisms, which rely on blocklists of DNS names, is impacted (hynek2020doh).

  • DNS-based criminal investigations: Internet service providers (ZYanFGCS2020) are often required by laws to record online activities (queried domains) of their subscribers for a certain period that may be needed for criminal investigations. Therefore, serious concerns are raised by agencies like Government Communications Headquarters (GCHQ) that encrypted DNS (as it bypasses current surveillance systems) would cause significant challenges for lawful investigation (CCimpanu2019).

  • Captive portal via DNS hijacking: Commercial venues (e.g., shopping malls and airports) that offer public wireless Internet access to customers often use captive portals to manage their network access through their network gateways. Via DNS hijacking, unauthorized users will be redirected to the login page configured by operators regardless of their actual destinations specified in DNS lookups. The adoption of DNS encryption may render the captive portals ineffective (ZYanFGCS2020) as the network gateways are no longer able to modify DNS responses sent to the end users.

  • Detection of malware distribution: DNS plays a critical role in the activities of malware. Therefore, security experts have developed methods to detect malware distribution by analyzing domain names in plaintext DNS messages (MSinghDI2019; KAlieyanNCA2017). Unfortunately, those methods are incapable of processing encrypted DNS packets, which do not give visibility into the DNS message content (e.g., query names). This topic will be discussed in detail in §3.

Figure 4. A visual example of command-and-control (C&C) communications via DNS from malware-infected devices.

3. Malware Communications Empowered by DNS Encryption

Various malware families frequently use DNS for command-and-control (C&C) communications and data exfiltration (CPatsakisCS2020; Godlua2019; PsiXBot2019). While the security community has comprehensively understood such misuse via plaintext DNS, the threat landscape introduced by encrypted DNS has not been well studied yet. This section reviews some of the known ways of malware misusing encrypted DNS by malware and highlights emerging challenges for security teams for detecting those malicious activities. We focus on C&C communications (§3.1) and data exfiltration (§3.2).

3.1. Command-and-Control (C&C) Communications

Malicious actors on the Internet spread their malware to infect connected devices by various methods such as phishing emails, scripts embedded in web pages, and manipulating vulnerable firmware. Those malware-infected devices form botnets that establish connections with the external malicious actors to conduct cyber crimes as instructed automatically. The process of establishing connections between botnet and masters followed by exchanging information and instructions between these two parties is known as command-and-control (C&C) communications.

3.1.1. C&C Communications via Plaintext DNS

Security appliances and middleboxes (in most enterprise networks) often permit DNS traffic (MLyuPAM2019). Attackers, therefore, take advantage of getting free rides and make C&C communications via DNS instead of other proprietary protocols to bypass possible security measures that may block malicious traffic (CommandAndControl).

What is C&C over DNS?: Fig. 4 depicts a typical process of DNS-based C&C communications. In parallel to benign DNS lookups through recursive resolvers (step [colframe=black,colback=white,shrink tight,boxrule=0.5pt,extrude by=1mm]1 and [colframe=black,colback=white,shrink tight,boxrule=0.5pt,extrude by=1mm]2) for legitimate activities, malware-infected devices send DNS queries with intentions embedded in the questioned domain names (e.g., waitForCommand.malware.com) towards a malicious authoritative name server (e.g., for malware.com) operated by an adversary(step [colframe=black,colback=white,shrink tight,boxrule=0.5pt,extrude by=1mm]3 and [colframe=black,colback=white,shrink tight,boxrule=0.5pt,extrude by=1mm]4). Note that malicious queries are transmitted to typical DNS recursive resolvers, much like the way for benign DNS lookups. The authoritative name server for malware.com may directly send instructions to its botnet via DNS responses with text format (i.e., TXT type). Also, as reported by (KXuTDSC2013), it is common for other types of C&C communications (e.g., HTTP-based) to locate their masters via DNS resolution, i.e., sending the IP address of a dedicated C&C server (a.b.c.d in step [colframe=black,colback=white,shrink tight,boxrule=0.5pt,extrude by=1mm]5) for the malware-infected device to connect.

Features Plaintext DNS Encrypted DNS
Query packet size (AUdiyonoICONETSI2020; CJDietrichEC2ND) Yes ✓ Yes ✓
Domain TTL value (AUdiyonoICONETSI2020) Yes ✓ No ✗
Number of distinct domain names (AUdiyonoICONETSI2020; LBilgeNDSS2011) Yes ✓ No ✗
Number of client IP addresses (LBilgeNDSS2011) Yes ✓ Yes ✓
Temporal and spatial query pattern (LBilgeNDSS2011; CJDietrichEC2ND) Yes ✓ Yes ✓
Fraction of numerical characters in domain names (LBilgeNDSS2011) Yes ✓ No ✗
Length of the longest meaningful substring (LMS) (LBilgeNDSS2011) Yes ✓ No ✗
Entropy of domain names (CJDietrichEC2ND) Yes ✓ No ✗
Volume of NxDomain response (YWangCN2021) Yes ✓ No ✗
Table 6. Detecting C&C communications: example DNS features and their availability for plaintext and encrypted DNS.

What are the countermeasures against C&C over plaintext DNS?:

Malware-infected devices that perform regular C&C communications via legacy DNS exhibit relatively distinct patterns that can be used for network monitoring and anomaly detection purposes. The plaintext nature of DNS traffic makes the detection of C&C-related activities reasonably achievable by way of traffic flow analysis and/or packet inspection


For example, features (e.g., temporal activities, composition of domain name strings, DNS header flags) extracted from DNS traffic can be used to detect malware-infected devices. As pointed out in (AUdiyonoICONETSI2020), botnet devices (as opposed to benign hosts) often send regular updates via periodic DNS messages on their status to the master servers, resulting in a high volume of DNS queries. Also, domain names owned and operated by malicious actors are likely to be short-lived with low TTL values (i.e., also known as disposable domains (YZengCN2021)). That way, they can frequently change their DNS mapping and hence bypass static measures like blocklisting. In addition, devices that are infected by certain types of malware query for a relatively high number of distinct domain names due to the use of domain generation algorithms (DGA) that automatically emits a sophisticated set of domain names as the rendezvous points with C&C servers. Using the DNS features discussed above, the authors of (AUdiyonoICONETSI2020) were able to detect botnet traffic with a relatively high accuracy (90%).

DNS features have proven effective in detecting malicious domain names used in C&C communications. L. Bilge et al. (LBilgeNDSS2011)

extracts 15 DNS traffic features of four categories, including time-based, DNS answer-based, TTL value-based, and domain name-based properties, which collectively detect malicious domain names used for C&C. The authors developed machine learning models (trained on the identified features) with a large dataset containing over 100 billion DNS requests collected from an ISP network. The evaluation results show a close to perfect accuracy (more than 99.5%) can be achieved in detecting malicious domains.

In addition, by employing attributes of DNS traffic, researchers have identified a group of hosts managed certain malware families. Work in (CJDietrichEC2ND) shows how traffic characteristics like the entropy of queried domain names or aggregate behavioral activity profiles (e.g., DNS response rates) enabled the authors to detect C&C via DNS and determine their malware families.

3.1.2. C&C Communications via Encrypted DNS

Recent evidence from the security community (CPatsakisCS2020) has shown that malware developers are increasingly exploiting encrypted DNS (i.e., DoH) for C&C communications, bypassing the existing tools for security monitoring. For example, in 2019, the security team of 360 Netlab reported the existence of Godlua backdoor malware (Godlua2019) that uses DoH for C&C communications. According to (Godlua2019), several vendors mark Godlua as mining-related trojan malware while also involved in DDoS attacks. Malware strains that use encrypted DNS for C&C communications continue to evolve and display more dynamic and stealthy behaviors to reduce their chance of being detected. As reported in (PsiXBot2019), the “.NET-based” malware PsiXBot that emerged to perform C&C communications via the resolution of certain malicious domains now uses Google’s public DoH resolver, and hence does not look suspicious anymore. Therefore, network security appliances become ineffective when applying their pre-populated blocklists to those malicious C&C-related queries.

Implications of encryption for C&C detection: The trend of C&C via encrypted DNS inevitably introduces significant challenges to defenders as they become unable to extract most of the key DNS features as in legacy plaintext DNS (KBumanglagICICT2020). Table 6

shows some example key features extracted from plaintext DNS traffic(already discussed in §

3.1.1) and their availability when applied for encrypted DNS. Unsurprisingly, those features that require inspection of DNS packet headers and payloads (e.g., query name, query type, error code, resource records, and domain TTL) are not available anymore due to content encryption. In contrast, obtaining features from unencrypted IP headers (e.g., client IP addresses in Table 6), aggregated network profiles (e.g., query packet volume), and time-series patterns (MMontazeriShatooriDASC2020) may still be feasible (MGrillIM2015) for detecting C&C over encrypted DNS.

Figure 5. A visual example of data exfiltration via DNS from malware-infected devices.

3.2. Data Exfiltration (Tunneling)

Malware may retrieve sensitive and critical data (e.g., user credentials, credit card details, business financial, or medical records) from the infected devices and send it to unauthorized external entities. This process is known as “data exfiltration” by the security community (FUllahJNCA2018).

3.2.1. Data Exfiltration via Plaintext DNS

Commercial security middleware and appliances, operation on the network of ISPs and/or enterprises, may be empowered to prevent or detect data thefts (CISCODataExfiltration) by way of traffic inspection. However, DNS communication is relatively poorly policed by organizations (compared to services like email, FTP, and HTTP) and has been exploited by cyber-criminals to maintain covert communication channels with compromised hosts. Such stealthy methods, leveraging the DNS protocol, is known as DNS exfiltration or tunneling (ANadlerCS2019) .

DNS exfiltration: Fig. 5 illustrates a typical process of DNS exfiltration, with a sequence of events annotated by circled numbers. For the first step (the top-left region of Fig. 5), a malware-infected device factorizes the sensitive data into small snippets that are suitable to be encoded into (the subdomain of) DNS query names. From step [colframe=black,colback=white,shrink tight,boxrule=0.5pt,extrude by=1mm]2 to [colframe=black,colback=white,shrink tight,boxrule=0.5pt,extrude by=1mm]5, the device crafts and sends a series of DNS queries with their subdomain names carrying the encoded data (i.e., encoded-datasnippet_1 till encoded-datasnippet_n) belonging to a malicious domain (i.e., malware.com) managed by an external attacker. These queries reach the malicious name server (malware.com) through private/public recursive resolvers and might get dummy responses as the acknowledgments of received data. Exfiltrating data via DNS recursive resolvers makes the delivery path seemingly legitimate, however, recursive resolvers may block some of the reported primary domains to stop such misuses. We note that malicious actors may choose to directly send exfiltration DNS queries to a collection server managed by them (step [colframe=black,colback=white,shrink tight,boxrule=0.5pt,extrude by=1mm]6 in Fig. 5). Finally, upon arrival of all malicious DNS queries (sourced from the infected device), the attacker can reconstruct the exfiltrated data file by decoding and combining all snippets extracted from the subdomain names.

Type Domain name
Benign www.google.com
Benign p4-ces3lawazdkbw-qlrq5qalxdt7ytcq-385202-i1-v6exp3.ds.metric.gstatic.com
Exfil. PzMnPios0D3nOCwu0zomPS4nNjovPS8uOzsnNCstODkjOcwoMwAA.29a.de
Table 7. Examples of a short benign domain name, a long benign domain name, and a data exfiltration domain name (JAhmedTNSM2020).

Countermeasures against data exfiltration via plaintext DNS: Research works on detection of data exfiltration over plaintext DNS have proven to be successful. They generally employed statistical features extracted from query names to train machine learning classifiers (BSabirCS2022) to distinguish benign from malicious queries.

Let us have a look at some of these queries. Table 7 shows three example (benign and exfiltration) domain names, as reported by (JAhmedTNSM2020). It can be seen the exfiltrated query name (the thrid row highlighted in red) contains a fairly long subdomain string with 52 English letters, whereas a typical benign subdomain only contains several English letters (e.g., three for www in the first row). Note that some benign domain names may also have a long subdomain string (the second row highlighted in blue). However, exfiltration strings generated by encoding algorithms look random with a mix of numbers and uppercase/lowercase letters. In contrast, the long benign subdomains often display more meaningful patterns indicative of their service categories/indexes (the first row highlighted in green).

Based on large-scale data analysis of real queries for both benign and suspicious/malicious domains, J. Ahmed et al. (JAhmedTNSM2020) identified eight features of individual domain names to detect anomalous string patterns in exfiltration DNS queries. They used features like the count of uppercase characters and characters in subdomain names. The authors trained a one-class classifier on benign data that achieved an overall detection accuracy of more than 98%.

Using a different approach, work in (BSabirCS2022) focused on other aspects of the DNS traffic, considering features like spatial and temporal statistics of query packets from a given host to detecting DNS exfiltration from malware-infected hosts.

3.2.2. Data Exfiltration via Encrypted DNS

The deployment of DNS encryption techniques and their supporting infrastructures (e.g., encryption-enabled public resolvers) provide a solid basis for data exfiltration over encrypted DNS protocols. Therefore, it is not surprising to witness their occurrence, such as the one described in (CCimpanu2020)

. Oilrig (or APT34), a hacking group, was reported in 2020 as the first known malicious actor that managed to perform data exfiltration over DoH by advancing an open-source exfiltration toolkit

(ExfilDoHTool2). The victim of that DoH-based data exfiltration may include a pharmacy company named Gilead when it announced its commencement of research for the treatment of COVID-19, according to (CCimpanu2020). Many open-source tools (e.g., (ExfilDoHTool)) exist for data exfiltration over DoH on the Internet and hence becomes relatively easy for malicious actors. Therefore, enterprises that host critical data are alarmed (CISCODataExfiltration) to stay vigilant for emerging threats before getting harmed.

Features Plaintext DNS Encrypted DNS
Total count of characters in fully qualified domain names (FQDN) (DHaddonICGS32019; JAhmedTNSM2020) Yes ✓ No ✗
Count of characters in sub-domain names (JAhmedTNSM2020) Yes ✓ No ✗
Count of uppercase characters in domain names (JAhmedTNSM2020) Yes ✓ No ✗
Count of numerical characters in domain names (JAhmedTNSM2020) Yes ✓ No ✗
Entropy of domain names (DHaddonICGS32019; JAhmedTNSM2020) Yes ✓ No ✗
Number of domain name labels (JAhmedTNSM2020) Yes ✓ No ✗
Maximum domain name labels (JAhmedTNSM2020) Yes ✓ No ✗
Average domain name labels (JAhmedTNSM2020) Yes ✓ No ✗
Table 8. Detecting data exfiltration: representative DNS features extracted from domain names and their availability in plaintext and encrypted DNS traffic.

How encryption impacts data exfiltration detection: The use of encrypted DNS in data exfiltration attacks inevitably makes detecting them more difficult than those leveraging plaintext DNS. Methods for detecting C&C over encrypted DNS may still be able to resort to patterns in signaling packets (i.e., malware-infected devices are likely to connect with their C&C servers periodically (XHuDSN2016)). However, current state-of-the-art detection methods for DNS data exfiltration primarily analyze the string patterns in requested domain names unavailable after encryption. For example, Table 8 lists features111The entropy of domain names has already been discussed in §3.1 for C&C detection. extracted (JAhmedTNSM2020; DHaddonICGS32019) from domain names and their availability in plaintext versus encrypted DNS traffic. It can be seen how all of the required features become unavailable for encrypted DNS traffic analysis.

4. Inference Techniques for Encrypted DNS Traffic

As discussed in §3, malware leverages encrypted DNS protocol to bypass inspection-based detection and mitigation techniques used for C&C communications and data exfiltration. Although the current countermeasures against such misuses have not matured, some promising attempts to analyze encrypted DNS traffic for classification (not necessary for security purposes) provide useful lessons and references. In this section, we start by elaborating on the current research works in detecting encrypted DNS packets from HTTPS traffic streams and classifying their types (e.g., benign or malicious) in §4.1. Next, we review the developed methods in fingerprinting user profiles by analyzing encrypted DNS traffic, which can be a useful reference in developing methods to identify malware-infected hosts (§4.2).

4.1. Detecting and Classifying Encrypted DNS Traffic

Plaintext DNS, DoT, and DoQ have their dedicated service port numbers as UDP/53, TCP/853, and UDP/784&8853, respectively, which can be easily detected by inspecting headers. However, DoH encapsulates its DNS content in HTTPS packets, and thus it shares the same service port TCP/443 with other HTTPS-based applications (e.g., web browsing). Unsurprisingly, the detection of DoH packets from HTTPS traffic is a nontrivial problem.

One may label an HTTPS flow as DoH if its source or destination IP address is one of the well-known DoH recursive resolvers. However, such methods inevitably: (a) mislabel non-DoH HTTPS flows towards the IP address of popular resolvers (e.g., Google’s DoH resolver shares the IP address with an HTTPS-based website (GoogleDNS) for manual DNS lookups via a web interface), and (b) will miss DoH flows to unpopular servers. As pointed out in (CPatsakisCS2020), the analysis of traffic patterns seems to be a promising approach to detect and classify DoH packets due to some of their distinct characteristics. In what follows, we discuss the related research efforts in more detail.

4.1.1. Detecting DoH from HTTPS Traffic

In (DVekshinARES2020), the authors pointed out that accurate recognition of DoH is a precursor step for detecting encrypted DNS-based malware activities. They explored the possibility of using machine learning techniques to differentiate DoH from HTTPS traffic.

To this end, the authors analyzed the identifiable flow characteristics of DoH. First, clients often establish a single DoH connection to their recursive resolver and retain it for a number of domain lookups. Therefore, the flow duration of DoH is likely to be longer than that of typical HTTPS connections (e.g.,

web browsing). Although video streaming and large file downloading via HTTPS may also have long durations, their volume and data rate are expected to be higher than DoH flows. Second, the variance of DoH packet sizes is much lower than other HTTPS applications. Third, DoH packets often come in bursts during a connection depending on users’ interactions, but the total number of DNS packets (and the corresponding volume) in each burst is not large. Finally, unlike other applications, a DoH flow often has quite similar (or symmetric) volume in both directions.

Features DNS over HTTPS Web browsing File downloading Video streaming
Flow duration Long Short Long Long
Flow volume Small Medium Large Large
Variance of packet sizes Small Large Medium Large
Ratio of burst (active) and pause (idle) High Small Small High
Number of packets in each burst Medium High High High
Symmetry of requests and responses High Low Low Low
Table 9. Key flow features (summarized from information in (DVekshinARES2020)) and their expected value range for DNS over HTTPS (DoH), web browsing, file downloading, and video streaming.

Observing some of unique characteristics of DoH flows (mentioned above) as well as their temporal behaviors, work in (DVekshinARES2020) identified 19 features capturing identifiable patterns in DoH flows. We summarize and aggregate in Table 9 those key features and show their expected value range for DoH and three typical HTTPS-based applications, including web browsing, file downloading, and video conferencing. With those key flow-level attributes, the authors developed machine learning classifiers to distinguish DoH from generic HTTPS traffic that yields a very high accuracy of more than 99% on their dataset publicly available at (vekshin_dmitrii_2020_3906526). Similarly, the authors of (LCsikorESP2021) built their machine learning models using features of packet sizes and inter-arrival times that can differentiate DoH from website browsing with more than 90% accuracy.

4.1.2. Classifying Benign and Malicious DoH Traffic

With the rising use of DoH in malicious activities such as C&C and data exfiltration & tunneling, classifying benign and malicious DoH traffic becomes increasingly essential.

Work in (CPatsakisCS2020) performed time-series modeling via Hodrick-Prescott (HP) filter on DoT and DoH response sizes from benign and malware-infected hosts. They observed distinct patterns in time-series signals of packet size to identify hosts performing C&C communications and classify their malware families.

In (CKwan2021FOCI), C. Kwan et al. developed a threshold-based method on packet size, packet rate, and throughput to differentiate DoH tunneling from benign DoH communications. Their method achieved a perfect 100% accuracy in detecting DoH tunneling generated by a popular tool called “dnstt” (DNSTTTool). The authors demonstrated that DNS tunneling could only bypass their detection method if its rate is significantly reduced by a factor of 27.

Work in (MMontazeriShatooriDASC2020) detects DoH tunneling by combining time-series (i.e., a sequence of packet size, count, duration, and inter-arrival time), header (i.e., unencrypted handshake information), and statistical features (e.g., mean, median, and variance of packet sizes) of HTTPS traffic. The authors make their dataset “CIRA-CIC-DoHBrw-2020” publicly available (CIRACICDoHBrw2020), containing more than 100M packets of generic HTTPS, benign DoH, and malicious DoH. Their traffic traces are generated by two browsers (Chrome and Firefox), three DoH exfiltration tools (Iodine, DNS2TCP, and DNScat2), and four public DoH resolvers (Adguard, Cloudflare, Google, and Quad9). The authors developed machine-learning models with a hybrid set of features from a rich and diversified dataset that achieved over 99% precision in malicious DoH traffic detection. Using the “CIRA-CIC-DoHBrw-2020” dataset, three follow-up research works (SKSingh3ICT2020; YMBanadakiJCSA2020; MBehnkeAccess2021)

demonstrated the effectiveness of various machine learning algorithms such as Logistic Regression (LR), Random Forest (RF), K-Nearest Neighbors (KNN), XGBoost, Light gradient boosting machine (LGBM) using 34 traffic features originally identified in


4.2. Profiling User Activity by Analyzing Encrypted DNS Traffic

In addition to the detection of encrypted DNS traffic from generic HTTPS traffic, some emerging research works analyze encrypted DNS traffic to profile the behavior of hosts (i.e., users) – insights such as websites they visit and operating systems they use. To the best of our knowledge, there is no such work for detecting malware-infected hosts. That said, current research arts provide valuable references and insights for solving cybersecurity problems. Therefore, we discuss them as follows.

Work in (RHouserCoNEXT2019) fingerprints the history of visited websites by hosts using temporal patterns of DoT packet sequences. The authors identify important features that fall into nine categories, including length of query and response, number of queries and responses, volume of queries and responses, time intervals, total transmission time, sequence of DNS packets of uninterrupted queries and responses, number of DNS messages in each TLS record, query rate, and time to receive the first N bytes from the resolver. By selecting and tuning optimal models, the authors are able to achieve decent performance, false negative and false positive rates of less than 17% and 0.5%, respectively, in identifying the visited website of a host. Moreover, they showed how their techniques work for padded DoT messages (rfcDNSPadding2018) with around 99% true positive rate and 42% true negative rates.

Similarly, S. Siby et al. (SDSibyNDSS2020; siby2018dns)

proposed a machine learning-based method to fingerprint website visits of a host by analyzing DoH traffic. For a DoH flow, they use n-grams (

i.e., a contiguous sequence of n queries and responses) of TLS record lengths and burst-lengths (i.e., the total length of consecutive packets in the same direction) as key features to train a random forest classifier. Evaluation results showed that their approach achieved more than 90% accuracy in fingerprinting website visits. The authors demonstrated that client locations, different DoH resolvers, client operating systems, and browser applications only have a minor impact on the classification performance. However, the use of perfect padding (currently not widely adopted by the stakeholders) deteriorates their model’s prediction, giving a poor accuracy of less than 10%.

Features Unpadded DoH Unpadded DoT Padded DoH Padded DoT
Query and response length (RHouserCoNEXT2019) Applicable Applicable Not effective Not effective
Number of queries and responses (RHouserCoNEXT2019) Applicable Applicable Applicable Applicable
Inter-arrival time (RHouserCoNEXT2019) Applicable Applicable Applicable Applicable
Transmission time (RHouserCoNEXT2019) Applicable Applicable Applicable Applicable
Order of query and response packets (RHouserCoNEXT2019) Applicable Applicable Applicable Applicable
Volume of queries and responses (RHouserCoNEXT2019) Applicable Applicable Not effective Not effective
Number of DNS message in TLS records (RHouserCoNEXT2019) Not applicable Applicable Not applicable Applicable
Query rate (RHouserCoNEXT2019) Applicable Applicable Applicable Applicable
Time to receive the first N bytes (RHouserCoNEXT2019) Not applicable Applicable Not applicable Applicable
N-grams of TLS record lengths (SDSibyNDSS2020) Applicable Not effective Not effective Not effective
N-grams of burst sizes (SDSibyNDSS2020) Applicable Not effective Not effective Not effective
N-grams of DNS sequences (MMuhlhauserARES2021) Applicable Applicable Not effective Not effective
Table 10. Key features and their applicability & effectiveness (reported in (RHouserCoNEXT2019; SDSibyNDSS2020; MMuhlhauserARES2021)) for user profiling when extracted from padded/unpadded DoT/DoH traffic.

Apart from website fingerprinting, Segram, as presented in (MMuhlhauserARES2021), is able to identify Android applications for smartphones and IoT devices used by clients through the analysis of their DoT or DoH traffic. Apart from website fingerprinting, Segram (MMuhlhauserARES2021) is able to identify Android applications for smartphones and IoT devices used by clients through the analysis of their DoT or DoH traffic. The authors used the n-grams of DNS sequences (message sizes and interarrival time) as primary features of their classification model, which outperforms their counterparts (SDSibyNDSS2020) employing other features such as n-grams of TLS record sizes and burst lengths. More specifically, their developed model achieved more than 90% accuracy on the traffic traces (publicly available at (MMulhauser2021)) of 118 Android apps from ten DoT/DoH resolvers. They highlighted that their method is proven to be relatively effective when applied to padded encrypted DNS, giving over 72% classification accuracy.

In addition to profiling the user behaviors by analyzing encrypted DNS traffic on the network, G. Varshney et al. (GVarshneyCOMSNETS2021) showed that how they can obtain DoH lookups before they get encrypted by passively monitoring the RAM usage on the client devices. Although it provides an opportunity for organizations to reinforce their security measures leveraging DNS content inspection, malicious actors can also utilize this method to violate user privacy which is assumed to be well protected by DNS encryption.

In Table 10, we summarize the applicability and efficacy of key features of unpadded DoH, unpadded DoT, padded DoH, and padded DoT traffic in order to profile users online activity as reported by the above research works. For a certain traffic type, a feature is labeled as “applicable” if it can be extracted; otherwise, it is labeled as “not applicable”. In addition, a feature that can be computed but leads to relatively poor classification performance (i.e., accuracy less than 80% as reported by the respective literature) is marked as “not effective” in Table 10. For example, as stated in (MMuhlhauserARES2021), classifications using n-grams of DNS sequences can only achieve 72% accuracy for padded DoH and DoT; thus, they are labeled as “not effective” in the respective cells. We believe that those important characteristics of encrypted DNS traffic are still valuable in future user profiling works for cybersecurity use-cases like detecting malware-infected hosts.

5. Discussion and Future Directions

With the understanding of current development and issues of DNS encryption and some of the risks of malware misuse, we now discuss potential research directions worthwhile to be explored in future works.

5.1. Performance Enhancements

Although DNS encryption promises privacy and security benefits to users and service providers, the overheads of TCP acknowledgments and SSL handshakes (in DoT and DoH) negatively impact the query resolution time, as discussed in §2.2. Such performance degradation is more evident to clients under unstable network conditions in rural areas and/or wireless networks. Thus, it becomes one of the key reasons for the low adoption of DNS encryption. DoQ, which is currently in the draft stage, seems to be a faster DNS encryption protocol due to its zero-RTT feature. Apart from the protocol-level optimization, future research for performance enhancement mechanisms on client applications (e.g., browsers), network equipment (e.g., routers), and resolvers is necessary to boost the public adoption of DNS encryption.

5.2. Managing Security and Privacy Vulnerability

As discussed in §2.4 , there are still privacy issues that remain unresolved or are newly introduced by DNS encryption. We now recap/highlight those issues and outline some potential directions of research to address them.

First, although DNS communications between clients and resolvers are secured against third-party eavesdropping, a compromised (or malicious) resolver could still put user privacy at risk. Furthermore, current DoT/DoH/DoQ resolvers are dominated by a limited number of servers owned and operated by major service providers. Such centralization could lead to data monopolization that ultimately harms clients’ privacy. Therefore, developing privacy-preserving methods against data leakage from the resolver is a valuable direction – ODNS (PSchmittANRW2019) that detaches the proxy function from resolvers is a good example of such methods.

Second, compared with plaintext DNS resolvers, DoH and DoT resolvers become vulnerable to a broader range of attacks such as TCP and TLS-based DDoS attacks in addition to typical DNS query floods given their need for establishing TLS/TCP connections with clients (legitimate or malicious). Undoubtedly, effectively securing the key infrastructure (i.e., encrypted DNS resolvers) from potential DDoS attacks requires more sophisticated protection, mostly related to the management of TCP and TLS connections, than plaintext DNS.

Third, misconfiguring encryption settings on either client (e.g., choice of encryption option) or resolver (e.g., invalid SSL certificate or insecure TLS version) make the privacy protection promised by DNS encryption less effective. Therefore, a systematic way of sanity checking and/or verification on DNS encryption settings for user applications (e.g., browsers and mobile applications) and resolver can be an avenue for research to explore.

Last, third-party observers (or eavesdroppers) may still identify user profiles (e.g., visited websites and used applications) by analyzing the traffic patterns of their encrypted DNS communications. Malicious usage of such techniques may result in leaking clients’ private information. Some potential countermeasures such as privacy-preserving query scheduling techniques (e.g., (OAranaCN2021)) that obfuscate DNS lookup patterns of various applications are worthwhile to be further developed, protecting user privacy.

5.3. Understanding Malicious Encrypted DNS Traffic

As discussed in §3, encrypted DNS has been misused for malware C&C communications and data exfiltration to evade security appliances and middleware that perform payload inspection, looking for malicious signatures. With the increasing growth of DNS encryption, its misuse by malicious actors will likely become more frequent and diversified. Hence, there is a need for advanced methods to characterize malicious encrypted DNS communications, addressing emerging threats.

5.4. Host Profiling Techniques for Malware Detection

As discussed in §4.2, current host profiling techniques that analyze encrypted DNS traffic mainly focus on identifying visited websites and mobile applications. Existing works have shown that hosts display distinguishable patterns of encrypted DNS traffic when they perform certain activities (e.g., visiting different websites). They extract a comprehensive set of features, achieving acceptable accuracy in their respective tasks. We believe such profiling techniques can be employed to detect malware-infected hosts. For example, quantifying deviations from their baseline benign profile (anomaly detection) or employing multi-class classifications to identify specific types of malware misuses (e.g., classes of malware or types of misuse) could be considered.

We note that the features (summarized in Table 10), proven to be effective for other tasks, may also be useful in detecting malware activities via encrypted DNS.

6. Related Surveys on DNS Security

DNS security has been a popular topic, with many published surveys, each focusing on a specific topic ranging from the categorization of DNS attacks to methods for detecting DNS attacks or identifying certain types of DNS attacks. We discuss (in chronological order) some of the contemporary ones published after 2016.

Y. Zhauniarovich et al. (YZhauniarovichCS2018) reviewed data-driven techniques for detecting malicious domains with a focus on aspects of dataset collection (i.e., the sources of DNS data, data enrichment, and ground truth), algorithm design (i.e., feature engineering, detection mechanisms, and outcomes), and evaluation methodologies (i.e., performance metrics and strategies). S. Torabi et al. (STorabiCST2018) surveyed passive systems of DNS traffic analysis for detecting various DNS attacks across the Internet, including DNS protocol attacks (e.g., DNS spoofing), DNS server attacks (e.g., DDoS), and DNS abuse (e.g., C&C communications). The authors looked at various system designs and compared their objectives, scopes, detection approaches, analyzed traffic features, dataset, and evaluation methods. The survey also highlighted the practicality of the studied systems by considering their real-time performance. The authors of (NUAijazDSS2021) studied DNS vulnerabilities, including cache poisoning attack, DDoS attack, spoofing, phishing, identity theft, forgery, eavesdropping, packet sniffing, tampering, and man-in-the-middle attack. In their discussions, they also included the protocol-level security enhancements introduced for DNS (i.e., DNSSEC, SSL certificates, and extended validation certificate). Y. Wang et al. (YWangCN2021) surveyed (plaintext) DNS tunneling detection methods developed during years between 2006 and 2020. They highlight the statistical features (i.e., payload-based and traffic-based) and detection mechanisms (i.e., rule-based and model-based) used in each DNS tunnel detection method.

Our survey focuses on DNS encryption and highlights opportunities (i.e., protecting privacy) and risks (e.g., malware misuse) associated with encrypted DNS traffic. To the best of our knowledge, there is no survey on the topic of DNS encryption to date. We found all existing relevant survey papers only cover the landscape of plaintext DNS.

7. Conclusion

This paper conducted a systematic and comprehensive review of academic research papers and industrial reports on the development and current status of DNS encryption, with a specific focus on its misuse by malware and potential countermeasure techniques. We outlined the development of three DNS encryption protocols (including DoT, DoH, and DoQ), their current state of public adoption, and their performance. We discussed the security benefits and risks of DNS encryption techniques highlighted by the current literature. Among security risks, we particularly focused on the potential malware misuses of encrypted DNS protocols, including C&C and data exfiltration. Although detecting malicious activities over plaintext DNS has proven relatively successful by prior works using inspection DNS payloads, their applicability to encrypted traffic is yet to be determined. Next, we studied existing works on the analysis of encrypted DNS traffic that can detect malware activities over encrypted DNS. The works are classified as either detecting encryption DNS packets from generic HTTPS traffic and classifying their types (e.g., malicious or benign), or fingerprinting user profiles by analyzing encrypted DNS traffic of hosts. Those works provide solid starting points and valuable references for malware detection potentially applicable to encrypted DNS. Inspired by prior works in the literature, we identified directions for future works, including performance enhancement, managing security and privacy issues, understanding the misuse of encrypted DNS by malware, and developing host profiling techniques to detect malware activities over encrypted DNS protocols.