Position Paper: The Use of Encrypted DNS

Abstract

Discover the transformative potential of DNS over HTTPS ( DoH), DNS over

TLS (DoT), and DNS over ǪUIC (DoǪ). These cutting- edge protocols promise to revolutionize the security and privacy of DNS queries, shielding your

online activities from prying eyes and malicious actors. However, the

journey to enhanced privacy is not without its hurdles. Our paper delves into the operational and performance challenges that come with these

advancements, offering a balanced perspective on their implementation. Whether you’re a network administrator, cybersecurity enthusiast, or just curious about the future of internet privacy, this paper provides valuable

insights that you won’ t want to miss. Dive in to explore the delicate balance between robust security and efficient network management.

Introduction

Did you know that over a third of all cyber-attacks are deployed via Domain

Name System (DNS)?       The field of cybersecurity has experienced

tremendous growth over the past decade, and with the advent of AI, this growth shows no signs of slowing down.

At recent cybersecurity conferences, I’ve noticed that when I mention DNS

Security, it often feels like I’m speaking a foreign language. DNS is frequently referred to as the “glue” that holds the internet together. It translates human- readable domain names into IP addresses, enabling users to access websites and online services seamlessly.

One of the most famous malwares that utilized DNS directly as a transport

mechanism is DNSChanger. This malware, which was first discovered in 2007, infected millions of computers worldwide. DNSChanger altered the DNS

settings on infected machines, redirecting users to malicious websites and

intercepting their internet traffic. The malware was used to generate fraudulent advertising revenue and steal personal information.

The origins of name services date back to the early days of the internet, with the current DNS protocol being defined in 1987. Since then, DNS has undergone several security enhancements to address deficiencies in the original protocol. Content filtering relies heavily on domain names and IP addresses to categorize websites and identify malicious sites. Unfortunately, the DNS protocol is commonly misused by hackers as a transport for malware and command-and-control operations.

One notable example of malware identified in 2024 that utilizes DNS as a transport mechanism is Spearal. This malware was part of a targeted campaign against Iraqi government infrastructure. Spearal uses DNS tunneling for command-and-control (C2) communication, encoding data in the subdomains of DNS queries using a custom Base32 scheme.

Another example is Veaty, which also emerged in 2024. Veaty uses a combination of DNS tunneling and email-based C2 channels. This malware was used in attacks attributed to the Iranian threat actor group APT34.

Despite its critical role, DNS security is often overlooked as a attack vector to close in the cybersecurity industry. The reason will become apparent later in this article. Any DNS expert will tell you that we are the plumbers of the industry—nobody thinks about us until something breaks, and the toilet backs up!

The problem with DNS

While DNS is essential for navigating the internet, traditional DNS queries are sent in plaintext, making them vulnerable to various security threats like eavesdropping, manipulation, and censorship. This lack of encryption means that malicious actors or intermediaries can intercept and monitor DNS queries, tracking your browsing habits or redirecting you to malicious sites.

Transmitting DNS in plaintext poses several issues:

Privacy Concerns

• Data Leakage: Plaintext DNS queries can expose your online activities to anyone with access to the network, such as ISPs, network administrators, or cybercriminals. This exposure can lead to unauthorized access to your personal data and browsing history.

• Profiling: By analyzing plaintext DNS queries, ISPs and other intermediaries can build extensive profiles of your online behavior. This profiling can be used for targeted advertising, surveillance, or even sold to third parties without your consent.

Security Risks

• Interception and Tampering: Without encryption, DNS queries and responses are vulnerable to interception and modification by attackers. This can result in DNS spoofing, where you are directed to malicious websites that appear legitimate, increasing the risk of phishing attacks and malware infections.

• Redirection Attacks: Attackers can exploit the lack of encryption in DNS queries to manipulate responses, redirecting you to fraudulent websites. This compromises both your security and privacy, as you may unknowingly provide sensitive information to malicious actors.

Data Integrity

• Corruption of Data: Plaintext DNS traffic is susceptible to tampering, which can result in corrupted or incorrect DNS responses. This can disrupt your access to legitimate websites and services, causing significant inconvenience and potential security risks.

Benefits of Plaintext DNS

But it’s not all bad news! There are some benefits to sending DNS queries in plaintext. For instance, in certain regions, governments can monitor and control DNS traffic to restrict access to specific websites, effectively blocking or redirecting users to government- sanctioned content. The transparency of plaintext DNS makes it easier for authorities to implement such measures.

Organizations also utilize plaintext DNS queries to restrict content that is deemed inappropriate for the workplace or considered distracting. This allows end users to concentrate on the task at hand and protects the organization. Additionally, plaintext DNS can help organizations meet regulatory requirements related to content filtering.

Parents use plaintext DNS to restrict content that is inappropriate for children. This protects children from accessing sites with objectionable or non-age-appropriate content and helps protect them from online predators.

This is one driver that has lead cybersecurity to take advantage of the DNS queries being sent in plain text.

How Encrypted DNS (DoH, DoT and DoQ) fix the problem

The Domain Name System (DNS) functions as the internet’s phonebook, translating domain names into IP addresses so browsers can load internet resources. When a user types a web address into their browser, a DNS query is initiated to find the corresponding IP address. DNS was originally defined in RFC 1034 and RFC 1035 in 1987, making it one of the earliest defined protocols on the internet. It has been further refined over the years to enhance and secure the protocol (e.g., RFC 2181, RFC 2308, RFC 2671, RFC 4033, RFC 4034, RFC 4035,

RFC 5155, RFC 6891). I’m not going to go into those changes here as they do not relate to the subject at hand.

Over the past eight years there have been several RFC’s published to fix the problem of sending DNS in plaintext. They are as follows:

• DNS over TLS (DoT): RFC 7858 published in May of 2016
• DNS over HTTPS (DoH): RFC 8484 published October 2018
• DNS over ǪUIC (DoǪ): RFC 9250 published May 2022
• Oblivious DNS over HTTPS (Oblivious DoH): RFC 9230 Published June 2022 The Table below shows a comparison of DNS protocols and how they work:

Table 1 – DNS Protocol Comparison

To compare the flow of these protocols, we must first understand how traditional DNS works. The Diagram Below outlines a traditional DNS query of www.example.com. I’ve left out TCP and other nuances to just provide a basic query resolution. We will use this to compare how the same DNS conversations for DoT, DoH and DoǪ to show the difference. Oblivious DoH will be discussed later in this document. The GREEN lines represent the conversations in plaintext.

This process involves several steps (See Figure 1):

1. The user’s computer sends a DNS query www.example.com to a DNS resolver over UDP port 53. (plaintext)
2. The resolver checks its cache for the IP address. If not found, it queries a root nameserver over UDP port 53. (plaintext)
3. The root nameserver directs the resolver to a top-level domain (TLD) nameserver (e.g., .com, .org) In this case the .com nameserver (plaintext)
4. The resolver queries the .com TLD nameserver for example.com over UDP port 53. (plaintext)

• The TLD nameserver points the resolver to the authoritative nameserver for the specific domain example.com over UDP port 53. (plaintext)
• The resolver queries the authoritative name server for example.com over UDP port (plaintext)

• The authoritative nameserver returns the IP address 10.100.0.45 to the resolver. (plaintext)

• The resolver then responds back to the user’s computer with 10.100.0.45, allowing the browser to load the website. (Plaintext)

Let us compare Original DNS to how DoH, DoT and DoǪ work:

DNS over HTTPS (DoH), DNS over TLS (DoT), and DNS over ǪUIC (DoǪ) enhance DNS security by encrypting DNS queries and responses.

The conversation flows are essentially the same (other than protocol and port), so we will use one diagram to show the DNS flow for all three protocols using the same www.example.com request from above. The BLUE lines represent encrypted communications.

This process involves several steps (See Figure 2):

1. The user’s computer sends a DNS query www.example.com to a DNS resolver over DoH, DoT or DoǪ. (encrypted)
2. The resolver checks its cache for the IP address. If not found, it queries a root nameserver over UDP port 53. (plaintext)
3. The root nameserver directs the resolver to a top-level domain (TLD) nameserver (e.g., .com, .org) In this case the .com nameserver (plaintext)
4. The resolver queries the .com TLD nameserver for example.com over UDP port 53. (plaintext)

• The TLD nameserver points the resolver to the authoritative nameserver for the specific domain example.com over UDP port 53. (plaintext)
• The resolver queries the authoritative name server for example.com over UDP port (plaintext)

• The authoritative nameserver returns the IP address to the resolver. (plaintext)
• The resolver then responds back to the user’s computer, allowing the browser to load the website. (encrypted)

Are you a little letdown? Did you have a false sense of security?

Benefits of Encrypted DNS

DoT, DoH, and DoǪ partially remediate all the problems described above with traditional DNS protocol between the user and the DNS resolver with encryption. It prevents man-in- the-middle attacks between the user and the DNS resolver. It ensures privacy is maintained. It eliminates security concerns and ensures data integrity between the user and the DNS resolver.

Problems of Encrypted DNS (DoH, DoT and DoQ)

Initially, communications between the user and the resolver are encrypted, but all intermediate messages are sent in plain text. This means that if someone performs a spoofing attack later in the conversation, it can still compromise the user’s communication and affect others, giving a false sense of security.

In many cases, encrypted DNS traffic might not even leave the corporate network if the user is using the organization’s DNS resolver. In such scenarios, the encrypted traffic stays within the controlled corporate intranet, where security risks are typically mitigated, especially for organizations with regulatory requirements or government entities. This situation complicates the work of operational support teams and raises potential regulatory issues. Tools like Wireshark can capture traffic flows but cannot decrypt the data. For instance, with DoH, it is challenging to identify DNS traffic among other HTTP traffic, and even if found, the content remains encrypted. Support engineers using tools like nslookup or dig will only see normal DNS resolutions, not the encrypted ones, which can confuse them and increase the Mean Time to Resolution (MTTR).

Home users might assume their DNS traffic is encrypted and unmonitorable. However, many use common DoH services like Google’s 8.8.4.4 or Cloudflare’s 1.1.1.1. These vendors provide free DNS services for a reason, possibly capturing the sites you visit. So, is it really private?

Encrypted DNS can also bypass content filters required by government policies, organizational policies, or parental controls. For example, in 2008, my 11-year-old son bypassed content filters on our family computer using the browser on his PlayStation. This experience highlights the challenges of content filtering, which is now typically included in home routers. However, is that solution truly effective?

Browsers have become complex, akin to virtual computers, with built-in DoH configurations that can bypass the operating system’s DNS settings. This capability can put parents and organizations in the same predicament I faced years ago with my son bypassing content filters. All popular browsers support DoH, and Firefox has enabled it by default.

Most organizations use enterprise proxy services for content filtering. Modern proxy appliances and services support encrypted DNS, enhancing privacy and security by encrypting DNS queries. However, this encryption can hinder traditional content filtering mechanisms, making it difficult for proxies to see which websites are being accessed, potentially bypassing content filtering policies.

To address this, some solutions involve configuring proxies to block or manage encrypted DNS traffic. For example, Cisco Umbrella includes known DoH servers in its “Proxy / Anonymizer” content category to prevent circumvention of content filtering. Similarly, Palo Alto Networks firewalls are designed to prohibit or secure the usage of DoT and DoH.

All popular operating systems support encrypted DNS, either natively (Windows, Mac, Android, iOS) or through third-party applications (Linux). However, none of these OSs enable encrypted DNS by default; OS’s must be configured to support these protocols. However, the tools like nslookup or ping that are deployed in the Operating Systems. Do not support DNS queries via any encrypted protocols. They will only send DNS queries through plaintext. Thus, the use of those tools in troubleshooting can cause confusion and lead to increased MTTR.

DNS Tunneling Concerns

Those of you who know me or have been in conversations with me in the past, expected there to be a section on DNS Tunneling. Well, here it is! The DNS protocol is abused and misused by malware, hackers and vendors alike. Encrypted DNS is no exception.

Encrypted DNS do not eliminate the ability for DNS tunneling to occur. DNS Tunneling is a method used by malware, hackers and even a few infrastructure vendors to exfiltrate data or communicate with command-and-control (C2) servers by encoding data within DNS queries and responses. Encrypted DNS only aids DNS Tunneling by making it more difficult for network security tools to detect and analyze malicious traffic. This increased difficulty in detection goes beyond normal domain filtering and posing a significant challenge for network security operations.

Detecting DNS tunneling, especially when encrypted DNS is challenging and DNS Tunneling using encrypted DNS is even more challenging. In my research I found three vendors have developed solutions to address this issue. Here are the vendors that support DNS tunneling detection with encrypted DNS:

• Cisco Umbrella: Cisco Umbrella includes known DoH servers in its “Proxy / Anonymizer” content category to prevent circumvention of content filtering. This helps in managing encrypted DNS traffic and detecting potential DNS tunneling attempts.
• Infoblox: Infoblox provides DNS security solutions in their BloxOne product that include DNS tunneling detection. Infoblox BloxOne solutions are designed to identify and block DNS tunneling attempts, even when DNS traffic is encrypted.
• BlueCat: BlueCat offers DNS security solutions that can detect and mitigate DNS tunneling. BlueCat’s solutions can analyze DNS traffic patterns to identify suspicious activities, including encrypted DNS tunneling.

These vendors provide robust solutions to help organizations detect and mitigate DNS tunneling, ensuring better security and compliance. I am familiar with these vendors and their offerings in this area. I suggest discussing their capabilities and validating the sales pitch in a lab environment before purchasing.

In my research I also came across information from Palo Alto Networks that, on the surface, indicates they can detect DNS Tunnels on encrypted DNS traffic, but without being a DNS resolver. I am not sure how thorough this detection can occur on encrypted DNS. In full disclosure, I also had a major DNS outage due to a bug with their application classification for DNS. For those reasons I did not include them in the above list. If Palo Alto Networks would like to discuss this further, I would be more than interested and will agree to update this list provided they can meet the criteria. If there are other vendors with products that I should also include, I would be happy to hear from them as well.

Network/Security Operations and Support

Implementing encrypted DNS requires network administrators to configure DNS resolvers and clients to support these protocols, which may require additional training and resources. Organizations must develop policies to manage encrypted DNS traffic and ensure compliance with security and regulatory requirements. Encrypted DNS traffic reduces visibility into DNS queries, making it harder to detect and mitigate DNS-based attacks and even finding root cause of application issues. New tools and techniques are needed to monitor and analyze encrypted DNS traffic without compromising privacy. Some tools are

included in the vendors above to aid Network and Security operational support groups to take on the challenge of supporting encrypted DNS. However significant training in the tools and encrypted DNS as well as playbook development in conjunction with vendors is required before encrypted DNS can be truly supported.

What about Oblivious DNS (ODoH)?

ODNS/ODoH aims to decouple client IP information from DNS queries, ensuring that no single entity can see both the DNS query and the client’s IP address simultaneously. This is achieved through a combination of public key encryption and a network proxy. ODoH does conform to RFC standard 9230, which outlines the technical specifications and implementation details for Oblivious DNS over HTTPS. This RFC was developed by the Internet Engineering Task Force (IETF) and co-authored by engineers from Cloudflare, Apple, and Fastly.

In documentation, I have seen ODoH referred to as “testing” or “project” and nothing about any type of real-world production deployment. Without significant global vendor support, I would avoid ODoH for the foreseeable future.

Conclusion

Encrypted DNS (DoT, DoH, and DoǪ) offer significant benefits in terms of privacy, security, and obfuscation for DNS queries. However, they also introduce challenges related to performance, network/security operations, and security perceptions. Organizations must carefully consider these factors when implementing encrypted DNS to ensure they achieve the desired outcomes without compromising network operations.

Specific examples of when DoH, DoT, and DoǪ should not be implemented include:

• Highly Controlled Environments: In environments where strict control over network traffic is required, such as in certain corporate or government networks, the use of encrypted DNS might complicate monitoring and compliance efforts. Traditional DNS allows for easier inspection and filtering of DNS traffic, which can be crucial for maintaining security policies.
• Performance-Sensitive Applications: Applications that require low latency and high performance might suffer from the additional overhead introduced by encryption. In such cases, the performance impact of DoH, DoT, and DoǪ might outweigh the privacy benefits.

• Legacy Systems: Networks with legacy systems that do not support encrypted DNS protocols might face compatibility issues. Implementing DoH, DoT, or DoǪ in such environments could lead to disruptions in service or require significant infrastructure upgrades.
• Security Operations: In scenarios where network security relies heavily on DNS traffic analysis, the use of encrypted DNS can hinder the effectiveness of security tools. For example, intrusion detection systems (IDS) and other monitoring tools might struggle to analyze encrypted DNS traffic, reducing their ability to detect and respond to threats.

Organizations and even home network users must weigh the benefits of enhanced privacy and security against these potential drawbacks to make informed decisions about implementing or allowing DoH, DoT, and DoǪ.

My personal recommendation, in most cases, is not to use these protocols, especially if your organization has their own DNS resolver. There are better and more secure ways to provide privacy, even for the home user.

If anyone would like to discuss this in more detail or if there are another DNS Security subjects you would like more information on. Please reach out and contact me at mfisher@bigfishcns.com. I will do my best to answer all requests.

Written By Michael Fisher, Distinguished Engineer, Big Fish Core Network Services.