Given the threat posed by DNS tunneling, organizations should implement measures to detect and block such channels. Detection usually involves looking for anomalies in DNS traffic patterns: unusually long domain names, often a giveaway of encoded data, high volumes of DNS queries to domains that aren’t commonly accessed, a lot of TXT record requests, or consistent DNS traffic to an external domain with no associated web traffic. Security teams can use specialized tools or DNS logs to spot these indicators. For example, if a single internal host is making thousands of DNS queries to an obscure domain every hour, that’s a red flag. Some intrusion detection systems and DNS security solutions apply machine learning to identify the statistical footprints of DNS tunneling. Additionally, threat intelligence can help, known domains or signatures of popular tunneling tools can be blacklisted.

Indicators of DNS Tunneling. Behavioral Red Flags

To detect tunneling, look for anomalies that deviate from legitimate DNS usage patterns:
– Excessively Long Domain Names. Encoded data results in very long subdomains suspicious if consistently >100 characters.
– High Query Volume. Thousands of queries per hour from a single host, especially to uncommon domains.
– Frequent TXT Record Lookups. Abnormal reliance on TXT or NULL records often indicates tunneling protocols.
– Repetitive Requests to a Single Domain. Persistent communication to a domain with no corresponding HTTP/S activity.
– Unusual Query Timing. Regular, evenly spaced DNS traffic (e.g., every 3 seconds) may signal automation.

A specific solution in this space is SafeDNS. SafeDNS can act as an organization’s DNS resolver with built-in intelligence to detect malicious usage. For instance, SafeDNS can intercept all DNS queries made by clients and block disallowed or suspicious queries. Essentially, SafeDNS can recognize when DNS is being used as a tunnel and prevent those queries from reaching the attacker’s server. This is performed through a combination of methods: recognizing domain names generated by tools, payload signatures, or unusual query behavior indicative of tunneling.

Detection Techniques

1. DNS Log Analysis
Tools like SIEM or SafeDNS can analyze logs for tunneling patterns. Look for:
– Entropy in subdomain strings
– Uniform query sizes
– Irregular TLD usage
– Persistent use of rare record types

2. Machine Learning & Behavioral Analytics
Advanced DNS firewalls like SafeDNS use ML models to flag tunneling based on:
– Frequency analysis
– Markov chain models for domain randomness
– User/device behavior correlation

3. Threat Intelligence Correlation
Compare against updated threat feeds for:
– Known tunneling domains
– IPs of public C2 servers
– DNS signatures from tools like Sliver, dnstt, or Chisel

It’s worth noting that as of this writing, SafeDNS’s detection capabilities cover many, but not all, known DNS tunneling tools. Our solution currently is able to detect and block 3 out of the 7 common tools we listed earlier, for example, it may successfully catch Iodine, dnscat2, and DNS2TCP traffic based on known patterns. The remaining tools use techniques that evade basic detection or simply haven’t had signatures created yet. However, SafeDNS is actively improving its coverage, full coverage of all 7 listed tools is planned by August. This means our team is developing updates to our filtering algorithms such that by August, it should be able to identify traffic from Iodine, DNSStager, dnscat2, Sliver, dnstt, Heyoka, and Chisel and similar programs. With this enhanced coverage, organizations using SafeDNS will have an extra layer of defense: even if an attacker tries different DNS tunneling utilities, the DNS security service will flag and block those queries, cutting off the channel.

Of course, no single solution is foolproof. Attackers constantly modify their tactics to avoid detection. Some may implement custom tunneling that doesn’t match known signatures, or they may tunnel very slowly to fly under statistical anomaly thresholds. Therefore, a defense-in-depth approach is recommended. Combine DNS-specific protections, like SafeDNS, with network monitoring, endpoint security, and user behavior analytics. Regularly auditing DNS logs can also uncover a dormant tunnel. 

In closing, awareness is key. Many organizations are now waking up to DNS-based threats and are starting to treat DNS traffic with the same vigilance as they treat web or email traffic. Solutions like SafeDNS make it practical to apply that vigilance in real time, shutting down DNS tunnels before they cause harm. By August, with SafeDNS achieving full coverage of known tunneling tools, companies employing it will significantly harden their networks against DNS tunneling attacks. Until then, it’s imperative to use the strategies discussed, monitor DNS, restrict it, and use intelligent DNS security services to keep this covert threat in check.

We continue our series of articles on DNS Tunneling, where in previous pieces we’ve covered the essence of DNS tunneling and data exfiltration, explaining why it’s dangerous, how it works, and how surprisingly easy it is to execute. In this third article, we turn our attention to a critical and often overlooked factor: the Performance Characteristics of DNS Tunneling. Many assume these tunnels are too slow to matter, but the reality paints a different picture.

One might assume that using DNS for data transfer is extremely slow, since DNS is not designed for bulk data, and indeed, many DNS tunnels operate at low bitrates. However, the performance of DNS tunneling can vary widely depending on how it’s implemented and the network conditions. In the worst case, DNS tunneling is quite sluggish, for example, a security study noted a typical bandwidth of around 110 KB/s (0.11 MB/s) for DNS tunnels, which is minor compared to normal network speeds. Many real-world malware samples using DNS tunnels send data sparingly to avoid detection. However, under optimal conditions, DNS tunneling can achieve surprisingly high throughput, even exceeding tens of megabits per second, or more.

Some of the open-source tools have modes or techniques to maximize DNS tunnel bandwidth. For instance, the tool Iodine can operate in what’s called “raw mode,” where it sends DNS packets directly to an authoritative server, bypassing the usual recursive resolver behavior. Before establishing the tunnel, Iodine checks which types of DNS packets are suitable for carrying payloads and automatically tests encoding options to find the most efficient one.

Once a working encoding is found, the tool tests the maximum possible payload size per packet by adjusting the downstream fragment size to ensure optimal throughput without fragmentation or packet loss.

In a controlled test environment, Iodine’s raw mode was shown to push over 50 Mbit/s through a DNS tunnel. In one benchmark, a 10MB file was transferred in just one second, demonstrating that DNS tunnels can achieve speeds rivaling legitimate network traffic under ideal conditions.

This was achieved by using large DNS packets and fast, direct query loops. If multiple parallel queries are used and the attacker controls the entire path, throughput can climb even higher. In theory, with extensions like EDNS0 allowing larger UDP payloads (~4KB per DNS message) and multiple queries in flight, a DNS tunnel could reach hundreds of megabits per second. In fact, security engineers have demonstrated that in ideal lab conditions (e.g., a local network with no DNS resolver in the middle), DNS tunneling can exceed 200 Mb/s of data transfer. That is comparable to or higher than many corporate internet connections, indicating that DNS tunneling is not just a trickle of data, it can be a firehose under the right circumstances.

On the other hand, the moment a DNS tunnel has to go through a typical recursive resolver, as in most real scenarios, performance drops dramatically. Even when all unknown outbound connections are completely blocked at the firewall level, the speed drops significantly, but the tunnel still remains operational.

This illustrates how persistent DNS tunnels can be even in tightly restricted network environments. Continuing the Iodine example, when the tunnel was forced to use a normal DNS server, which breaks data into many small queries and adds latency, the bandwidth plummeted from 50 Mbit/s to around 400 kbit/s (0.4 Mbit/s) . That’s a huge drop, illustrating that real-world tunnels often face overhead. Additionally, many public DNS resolvers and corporate DNS servers will cache responses and rate-limit similar queries, further capping throughput. Attackers must balance speed with stealth, aggressive high-volume DNS tunneling might be faster, but it’s also more likely to be noticed by intrusion detection systems due to unusual traffic patterns. Therefore, in practice, many malicious DNS tunnels operate in the realm of a few kilobits to a few hundred kilobits per second, slow enough to stay under the radar, but still fast enough to gradually siphon significant data, for example, even 100 kbit/s can exfiltrate ~1 MB of data in 80 seconds, which over hours or days can leak gigabytes).

In summary, DNS tunneling performance ranges from very slow to surprisingly fast. With careful optimization (direct authoritative queries, larger DNS messages, parallelism), tunnels can reach tens or even hundreds of Mbps. This means an attacker who isn’t worried about being noisy could transfer substantial data (e.g. streaming stolen data out). Conversely, stealthy attackers will accept lower speeds to avoid detection. From an organizational standpoint, this variability means you cannot assume a DNS tunnel is harmless because “it’s too slow to be useful”, it might not be slow at all. Even a slow tunnel is dangerous if it’s stealing your data, and a fast tunnel is outright alarming because of how much it can take in a short time.

DNS tunneling isn’t just a theoretical risk or an exotic attack seen only in advanced persistent threat scenarios. It’s a real, versatile, and increasingly accessible method used for data exfiltration and command-and-control operations. As we’ve shown, DNS tunnels can range from barely detectable low-bandwidth trickles to high-speed channels capable of transferring hundreds of megabits per second under the right conditions. This variability makes them dangerous: slow enough to slip under the radar, fast enough to cause real damage.

SafeDNS offers advanced Network-layer protection specifically designed to detect and block tunneling attempts in real time. Our DNS Security 2.0 module identifies abnormal query patterns, excessive subdomain usage, and suspicious data encoding behaviors common in tunneling. With automated threat intelligence, encrypted DNS support (DoH/DoT), and integration into SIEM platforms, SafeDNS helps organizations detect both stealthy and aggressive tunnels before damage is done. Whether attackers are dripping out data or opening the floodgates, SafeDNS ensures your DNS is no longer a blind spot, but a proactive defense line.

Secure Connectivity + Smart DNS Protection

Both SafeDNS and Enclave are built on a foundation of proactive defense. With Enclave, you can eliminate network attack surfaces and create encrypted connection that restrict access to only trusted, authenticated users. At the same time, SafeDNS protects your users at the DNS layer – preventing threats before they reach your infrastructure.

Together, these solutions form a powerful security stack: SafeDNS fortifies DNS resolution and content access, while Enclave governs encrypted communications between trusted endpoints. By integrating these layers, organizations can block malicious domains and unauthorized communications in a single motion – whether users are remote, hybrid, or on-prem.

What makes SafeDNS even more aligned with today’s compliance-driven security frameworks is its 3R Concept – Reveal, React, Resist:

– Reveal: Gain full visibility into DNS activity across your network, uncovering hidden threats, suspicious behavior, and usage anomalies in real time.
– React: Instantly apply policies or blocklists to respond to new or emerging threats as they arise.
– Resist: Harden your infrastructure against future attacks through intelligent filtering, dynamic AI-based threat detection, and DNS-layer access control.

This model directly supports compliance with NIST Cybersecurity Framework (CSF) functions: Identify, Protect, Detect, Respond, and Recover, by extending protection and visibility into the foundational layer of internet communication: DNS.

By using SafeDNS as the primary DNS resolver inside the Enclave environment, organizations can align their operations with NIST best practices while benefiting from two solutions that are truly complementary by design.

Joint Value: Why It Matters

The real value emerges in the synergy between SafeDNS and Enclave. Here’s how:

– Zero Trust Meets DNS Security: Enclave creates encrypted overlays and strict access policies, SafeDNS ensures no one in that overlay is reaching out to risky or unknown destinations.
– Seamless Policy Enforcement: With SafeDNS set as the primary DNS resolver inside Enclave, admins can apply DNS filtering, block lists, threat detection, and regulatory compliance rules globally, without complex routing or hardware.
– Visibility & Control Across the Stack: Security teams can enforce and monitor DNS policies even across dynamic Enclave-created overlays. That means granular visibility into both who is connecting and what they’re resolving, which is critical for detecting lateral movement, data exfiltration, or insider threats.

Use Case: Secure, Compliant, and Easy

Imagine a distributed team using Enclave for secure access to internal systems. With SafeDNS embedded as the DNS resolver in their Enclave environment, the same team benefits from:

– Automatic blocking of malware, phishing, and DNS tunneling attempts
– Protection from dynamic DNS Threats (DNS Spoofing, DNS Hijacking, DNS Injection and more)
– CIPA, ISO, SOC, HIPAA, and KCSIE compliance at the DNS level
– Smart categorization of over 116M domains and 2B+ URLs with real-time updates
– One-click DNS-based content filtering for productivity, legal compliance, and security

Why This Matters to You

Whether you’re an MSP, a security-conscious enterprise, or a growing remote-first company, by implementing Enclave + SafeDNS solutions, you can deploy Zero Trust access and DNS-layer protection as a unified experience. It’s easier, more powerful, and doesn’t require rip-and-replace changes.

To activate SafeDNS within your Enclave network:

1) Select SafeDNS as your primary DNS resolver in the Enclave setup.
2) Apply your DNS filtering policy via the SafeDNS dashboard.
3) Enjoy a clean, threat-resistant, and regulation-compliant DNS layer across your infrastructure.

Still have questions or want to see how it works in your environment? Our team is ready to help, just book a demo using the form below.

While the first part of this series introduced the concept of DNS Tunneling, explaining how attackers exploit the DNS protocol to create covert channels, bypass security controls, and exfiltrate data, this follow-up delves into the underlying risks and practical realities that make DNS Tunneling a persistent and underestimated threat. Despite its technical complexity, executing a DNS Tunnel often requires minimal resources, leveraging widely available tools and overlooked gaps in network monitoring. In this article, we’ll explore why DNS Tunneling remains dangerous, how it contributes to data breaches and unauthorized access, and why many organizations fail to detect it until it’s too late.

Why is DNS Tunneling Dangerous?

DNS tunneling poses a significant security threat to organizations because it provides attackers with a stealthy channel for data and commands that often goes unnoticed. Since DNS traffic is critical for normal operations, network defenders and monitoring tools may not scrutinize it as closely as web or email traffic. This lack of scrutiny allows malicious DNS tunnels to blend in with legitimate DNS queries. The result is a covert avenue to bypass security controls: DNS tunnels can easily slip past firewalls, proxies, and intrusion detection systems by masquerading as routine DNS lookups.

The potential impacts of a successful DNS tunneling attack on a company are severe. Once a tunnel is established, attackers can perform data exfiltration, siphoning off sensitive information (customer data, intellectual property, credentials, etc.) in small encoded chunks via DNS without immediate detection. They can also maintain persistent command-and-control (C2) over compromised systems. Through the DNS tunnel, an attacker can issue commands to malware inside the network, instructing it to propagate, encrypt files for ransomware, and so on, and receive status updates or stolen data in response. Essentially, DNS tunneling can give an adversary a continuous foothold to remotely control infected machines. Furthermore, it can be used to deliver malicious payloads or malware into the network, for example, sending pieces of a malicious code that reassemble on the target, all hidden in DNS responses. According to security analyses, the risks of DNS tunneling include data breaches, unauthorized access to sensitive information, loss of intellectual property, and malware delivery, as well as enabling attackers to move laterally or further exploit the environment.

Another reason DNS tunneling is dangerous is the difficulty of tracing and attribution. The DNS queries used in tunneling often look like queries to obscure domains or subdomains, which might not immediately raise flags. They could be misinterpreted as legitimate, if somewhat unusual, DNS traffic. Detecting a DNS tunnel is non-trivial, it often requires specialized analysis of DNS query patterns, payload sizes, and frequencies that are outside the capability of standard network monitoring tools. BlueCat Networks notes that DNS tunneling “bypasses most filters, firewalls, and packet capture software,” making it especially hard to detect and trace its origin. An attacker using DNS tunneling can therefore quietly operate under the radar for an extended period, increasing the potential damage. In summary, DNS tunneling is dangerous because it turns a trusted protocol into a vehicle for covert malicious activity, often leading to serious breaches that are hard to discover until the damage is done.

Why DNS Tunneling is Relatively Easy to Execute

Ironically, one of the reasons DNS tunneling is so prevalent is that it’s relatively easy for attackers to pull off, especially compared to other covert channels. There are a few factors that contribute to this:

• Pervasive DNS Access: DNS is required for almost all internet communications, so networks tend to permit DNS queries out to the internet by default. Port 53 (DNS) is “nearly always open on systems, firewalls, and clients” . Many organizations do not strictly limit what DNS servers can be queried or don’t inspect the contents of DNS packets. This means an attacker has a high chance that DNS traffic will be allowed egress from a target environment without being blocked. Even when an organization uses an internal DNS server, that server usually forwards queries it cannot resolve (like external domains) to upstream resolvers on the internet. Attackers can abuse this by querying their malicious domain – the query will traverse the internal DNS and go out to the attacker’s server. Unless specific egress rules or DNS filtering are in place, firewalls often treat DNS as an exception and let it pass uninspected, effectively punching a hole that attackers exploit.
• Lack of DNS Monitoring: DNS traffic is often considered benign infrastructure traffic and may not be monitored by intrusion detection systems or endpoint security agents. Security teams focus heavily on web, email, and lateral movement traffic, while DNS may get overlooked. Adversaries favor DNS because it is an “always-open, overlooked and underestimated protocol” for communications . This common oversight in network defense makes DNS an attractive avenue, attackers know their DNS-based communications have a lower chance of triggering alerts.
• Readily Available Tools: Perhaps most importantly, there is an abundance of open-source tools and frameworks that make setting up a DNS tunnel trivial. One doesn’t need to write custom code to leverage DNS tunneling; many publicly available projects can encapsulate traffic or messages into DNS queries. In fact, using these tools has become a common tactic for penetration testers and attackers alike. Unit 42 researchers point out that numerous tools available on GitHub allow attackers to create covert DNS channels “for the purposes of hiding communication or bypassing policies,” and these tools are not only freely available but also easy to use . In other words, an attacker with basic knowledge can download a DNS tunneling toolkit and get a working tunnel running in a short time, without needing to invent their own method. We will discuss some of these tools in the next section.
• Misconfigurations and Weak Policies: Many organizations inadvertently make DNS tunneling easier by not enforcing strict DNS usage policies. For example, if endpoint computers are allowed to query any external DNS server (like 8.8.8.8) instead of being forced through the company’s DNS resolver, an attacker’s malware can directly query the attacker’s DNS server, completely bypassing internal controls. Even if internal DNS is used, if it is not configured to filter out suspicious domains or very long query names, it will dutifully forward along the attacker’s queries. Common firewall configurations may allow DNS to any destination, or lack advanced DNS protocol inspection. Such misconfigurations (or rather, default configurations) create an environment where implementing a DNS tunnel is as easy as sending out DNS queries to a domain, and there is little to impede the malicious traffic.

In summary, DNS tunneling is facilitated by the necessity and ubiquity of DNS itself. Attackers are basically piggybacking on a service that must be open and functional. Combine that with the wealth of easy-to-use tunneling tools available and often insufficient DNS oversight, and you have a recipe for a simple but effective attack technique. Even junior attackers can find tutorials and tools online to exfiltrate data via DNS.

Understanding the dangers and simplicity of DNS Tunneling is the first step in recognizing just how vulnerable many networks remain. The protocol’s trust-based nature, combined with its ubiquity and poor visibility in traditional security stacks, creates an ideal vector for covert communication and data exfiltration. As we’ve seen, even basic tunneling tools can bypass firewalls and proxies if DNS traffic isn’t properly inspected.

This is where SafeDNS provides a critical layer of defense. Our Protective DNS solution is equipped with advanced detection capabilities to identify and block DNS tunneling attempts in real time. By leveraging behavior-based analytics, anomaly detection, and continuously updated threat intelligence, SafeDNS helps organizations detect covert channels, stop data exfiltration, and enforce security policies at the DNS layer—long before threats reach endpoints. With full support for DNS encryption (DoH/DoT), SIEM integration, and policy-based filtering, SafeDNS enables secure DNS resolution while maintaining full visibility and control over DNS traffic.

In the next article, we’ll take a closer look at the performance characteristics of DNS Tunneling, how attackers balance speed, stealth, and reliability to maintain persistent access, and what that means for defenders monitoring DNS traffic.

Start your free trial of SafeDNS today and see how Protective DNS can help you close one of the most overlooked gaps in your cybersecurity stack.

What is DNS Tunneling and How Does It Work?

DNS is often called the “phonebook of the internet,” translating human-friendly domain names into IP addresses. Under normal conditions, a DNS query contains only the information needed to resolve a hostname to an IP address. DNS tunneling exploits this protocol by inserting arbitrary data into DNS queries and responses, effectively encoding other communications within the DNS traffic . In a typical DNS tunnel, an attacker sets up a malicious domain and an authoritative DNS server for that domain. Malware or a compromised device inside the target network will then encode data (e.g. stolen information or command-and-control messages) into DNS queries for subdomains of the attacker’s domain . These queries travel as normal DNS requests through the organization’s DNS servers and resolvers, eventually reaching the attacker’s authoritative DNS server, which decodes the hidden data. The attacker’s server can likewise encode responses to send commands or data back to the compromised system. In essence, DNS tunneling establishes a covert, bidirectional channel over DNS, a channel that most network defenses don’t inspect closely, since DNS is usually viewed as benign name resolution traffic.

DNS tunneling represents a critical, yet often underestimated, vulnerability within the DNS protocol. In this first part of our series, we explored what DNS tunneling is, how it operates by exploiting legitimate DNS requests, and the differences between normal DNS traffic flows and tunneled traffic. We also reviewed some of the open-source tools commonly used to facilitate DNS tunneling, highlighting how accessible and adaptable these methods have become.

From a technical standpoint, DNS tunneling works by encoding data from other protocols or applications into DNS messages . For example, an infected client might take a chunk of payload, say part of a file or a command, base32 or base64 encode it, and append it as a subdomain in a DNS query (e.g. <encoded-data>.malicious-domain.com). When the organization’s DNS resolver receives this query, it thinks it’s a normal lookup for an external domain and forwards it to a public DNS resolver, which in turn asks the attacker’s authoritative name server. The authoritative server, controlled by the attacker, receives the query, decodes the data from the subdomain, and may respond with a DNS answer that also contains encoded data in a TXT record or in the field of an A record. The compromised client then decodes that data from the DNS answer. In this way, the attacker and malware establish a two-way communication tunnel hidden inside DNS traffic. Practically any type of data can be tunneled, attackers can exfiltrate sensitive files in small chunks, or send commands to a backdoor implant, all obscured as DNS queries and replies.

Because DNS is such a fundamental service, it is almost always allowed to operate freely. Most DNS queries use UDP on port 53 with fallback to TCP for large responses, and this port is typically open through firewalls and allowed on almost every network . Attackers leverage this by sending their malicious traffic over DNS, knowing that it will bypass many restrictions that would stop other channels. In summary, DNS tunneling repurposes a ubiquitous infrastructure protocol for covert communication. Next, we’ll examine why this technique is so dangerous for companies.

Open-Source DNS Tunneling Tools and Their Capabilities

There are several open-source tools that implement DNS tunneling, each with its own features and use-cases. These tools are often used by penetration testers to bypass captive portals or by attackers to establish C2 channels. Below is a list of some well-known DNS tunneling tools and a comparison of their functionality:

Each of the DNS tunneling-specific tools above can be used maliciously to bypass network defenses. Notably, they are all freely available, lowering the barrier for attackers. Next, we will visualize how normal DNS traffic flows in a network versus how a DNS tunneling attack leverages that flow for illegitimate purposes.

Normal DNS Traffic Flow vs. DNS Tunneling

To better understand DNS tunneling, it’s helpful to contrast it with normal DNS resolution. Figure 1 shows a simplified normal DNS query flow within an organization, while Figure 2 illustrates a DNS tunneling scenario (malicious flow). We will describe each in turn:

In a typical corporate network, clients (user workstations or devices) send DNS queries to a local DNS server (often an internal DNS or one provided by the organization). This DNS server is within the company’s network perimeter, protected by the firewall, and will resolve names on behalf of clients. If the local DNS server doesn’t know the answer (the domain is external), it will forward the query out through the firewall to a public DNS resolver (such as an ISP’s resolver or a service like Google DNS). The firewall permits these DNS requests (UDP/53) to pass because DNS is necessary for connectivity. The public resolver then performs the recursive resolution: it contacts the appropriate authoritative DNS servers for the domain in question. For example, if the client is resolving example.com, the resolver will query the root servers, then the .com TLD servers, and finally the authoritative server for example.com to get the IP address. The answer (the resolved IP) comes back from the authoritative DNS server to the public resolver, and then back through the firewall to the company’s DNS server, and finally to the client. All of this happens in the background within milliseconds, enabling the client to connect to the desired host. In the normal flow, all DNS queries are for legitimate hostnames and the responses are IP addresses or other genuine DNS records. The key point is that the authoritative servers involved belong to the real owners of the domains being queried (e.g., the authoritative server for google.com is Google’s DNS server). The DNS traffic contents are just domain names and IP addresses, no hidden messages.

Now consider a scenario where malware inside the network is performing DNS tunneling. The setup looks similar on the surface, the client still queries the internal DNS server, which forwards the query out to a public resolver, and an authoritative server eventually provides an answer. The crucial difference is the query itself and the ownership of the authoritative server. In a DNS tunneling attack, the attacker has registered a domain, say, attacker-domain.com, and set up an authoritative name server (NS) for it under their control (red server in the diagram). The malware doesn’t ask for something like login.microsoft.com; instead it queries a subdomain that encodes data, such as abcd1234.attacker-domain.com, where abcd1234 is encoded stolen data or a command. This query goes to the company DNS server, then out to the public resolver. The public resolver sees that the query is for attacker-domain.com and thus needs to go to that domain’s name server, which is the attacker’s malicious DNS server. The query reaches the attacker’s DNS server, which recognizes the encoded data (the abcd1234 subdomain) as part of the secret communications. It then formulates a DNS answer. For example, it might return a TXT record for abcd1234.attacker-domain.com with some encoded content, perhaps the next chunk of exfiltrated data, or the instruction “OK” for the malware to proceed. That answer travels back to the public resolver, through the firewall, into the company DNS, and back to the malware client. To any intermediate observer, this was just a DNS lookup for an external domain. However, in reality the DNS query/response carried hidden information. The authoritative server in this case is the attacker’s server (not a legitimate one), so the attacker can respond with anything. Essentially, the firewall and public DNS see a query to an innocuously named domain and allow it, not realizing it’s a Trojan horse carrying data out. Over time, the malware will keep sending these queries to carry chunks of data or to poll for commands. The attacker’s name server will keep responding with the necessary info encoded in DNS responses. This covert communication can continue as long as the DNS traffic is not detected as abnormal. A few characteristics of malicious DNS tunneling traffic (as in Figure 2) contrast with normal DNS (Figure 1): the queries often contain long, random-looking subdomains (since they carry binary data encoded as text), the queried domain is often one that nobody in the organization would normally use, and the frequency of queries might be high (to send more data) or at odd intervals. These anomalies can be used to detect tunneling, which we’ll discuss next. But without specific DNS monitoring, those differences can easily be missed, allowing the tunneling to run unhindered.

In the following parts of this series, we will dive deeper into why DNS tunneling is so dangerous for businesses and organizations, and why it remains relatively easy to execute even today. Understanding these risks is crucial for building a comprehensive cybersecurity defense.

To stay ahead of these threats, we invite you to start a free trial of SafeDNS today. Our advanced Protective DNS solution helps detect and block DNS tunneling activities, safeguarding your network and devices from covert attacks. Don’t wait until it’s too late. Secure your infrastructure with SafeDNS now.