DNS tunnelling attacks explained

What DNS tunnelling is

DNS tunnelling (also spelled DNS tunneling) is a technique that carries non-DNS traffic inside DNS messages. It works because of how DNS is designed: when a device looks up a name, its resolver passes the question along until it reaches the authoritative server for that domain. If an attacker owns the domain, they own that server, so anything written into the name being looked up reaches them, and anything they put in the answer comes back.

A tunnel has two ends:

• A client on the inside: a piece of malware, or a tunnelling tool someone has installed, that encodes outgoing data into the labels of a domain name, such as a long string of letters and numbers in front of the attacker's domain.
• A server on the outside: the authoritative name server for the attacker's domain, which decodes each query and sends data back in the response, usually in TXT, CNAME, MX or NULL records.

The result is a slow but working two-way channel that passes through firewalls, proxies and captive portals that allow DNS but nothing else. It is used for DNS exfiltration of stolen data and for command and control, where an infected device asks for instructions and receives them in DNS answers. It is one of the DNS attacks that a plain resolver will happily forward.

A simple example

Imagine malware on a laptop that wants to tell its operator it is running, and receive a command back. Using the reserved example domain attacker.example:

1. The malware encodes a short message, such as the machine's name, into text that is valid in a domain name, for example 7a3f9c1e2b.attacker.example.
2. It asks the laptop's normal resolver to look that name up, as it would any other.
3. The resolver does not know the name, so it asks the authoritative server for attacker.example, which belongs to the attacker.
4. The attacker's server decodes 7a3f9c1e2b, records that the laptop is online, and replies with a TXT record containing an encoded instruction.
5. The malware decodes the reply and acts on it, then repeats the cycle with new lookups.

Nothing in this exchange breaks the DNS standards. Each lookup on its own looks harmless; the giveaway is the pattern of many of them.

Why other controls miss it

DNS tunnelling is popular with attackers because it slips between the controls most organisations already have:

• Firewalls allow outbound DNS from internal DNS servers, and often from every device, because nothing works without it. A tunnel through your own DNS server looks like ordinary forwarded lookups.
• Web proxies and secure web gateways inspect web traffic, not DNS lookups, unless they are part of a platform that also handles DNS.
• Email security does not see it, because no email is involved.
• Endpoint protection may not flag a process that only makes DNS lookups, especially if the tunnelling code lives inside a legitimate-looking program.

That leaves the resolver as the one place every lookup passes through, if you make sure it does. It is also why tunnelling tools are often used to get round networks that block everything except DNS, such as some guest Wi-Fi portals.

Legitimate and malicious uses

Not every DNS tunnel is an attack. DNS has been used to carry data for legitimate reasons, and some security and monitoring products encode lookups or status information in DNS queries to their own domains. Open-source tunnelling tools also exist and are used for research, testing and, less legitimately, to get round paid Wi-Fi portals.

On a business network, though, the question is simple: is there a good reason for this device to send a stream of encoded data to an unknown domain? Usually there is not. Treat unexpected tunnelling as suspicious until you can explain it, and add genuine, known services to an allow list rather than tolerating the pattern in general.

How DNS tunnelling is detected

Detection relies on the fact that tunnelled DNS looks different from normal lookups, even if each query is valid. The common signals are:

Rules based on length and volume catch crude tunnels; better services combine several signals with machine learning. Cisco says its Secure Access DNS Defense adds AI-based detection of DNS tunnelling and domain generation algorithm (DGA) domains, one of the differences covered in DNS Defense vs Umbrella. Network detection and response (NDR) tools can also flag unusual DNS behaviour from traffic data.

How to prevent DNS tunnelling

Detection only works if the lookups pass through something that can see them. The most important controls are about making sure they do:

1. Send every lookup to a protective resolver. Point networks and internal DNS servers at a protective DNS service. Lookups for domains the service knows are malicious, or flags as tunnelling, are blocked rather than forwarded to the attacker's server, so the tunnel cannot form through your resolver.
2. Block outbound DNS that skips your resolver. Malware can send DNS straight to the attacker's server on port 53, or to a public resolver. The NCSC advises blocking outbound DNS on ports 53 and 853 unless it goes through your resolver.
3. Control DNS over HTTPS. Tunnelling tools can use public DoH services on port 443 to hide from network rules. Disable DoH or point it at your protective resolver through device policy, and block known DoH services where your provider offers a category for them. See should you block DNS over HTTPS?
4. Cover devices off site with a DNS roaming client, so the same controls apply on home broadband.
5. Analyse and alert. Send DNS logs to your SIEM and alert on the signals above, or choose a service that detects tunnelling for you.
6. Block newly seen or unknown domains where appropriate, starting in monitor-only mode to see what would be affected.

What DNS security can and cannot do here

A protective resolver is the natural place to stop DNS tunnelling, because it sees every lookup before it leaves your control. But be realistic about its limits:

• A tunnel to a domain that is not yet known as malicious is only stopped if the service detects the pattern, not just the reputation.
• A device that reaches the internet without using your resolver, through a personal VPN or hard-coded DNS, is invisible unless firewall rules and device policy close those routes.
• Very slow, low-volume tunnels are harder to tell apart from normal traffic.

That is why we recommend combining protective DNS with egress control and endpoint protection, and testing the result. Our DNS security test guide includes checks for the bypass routes.

How we can help

We can review where DNS leaves your network today, close the routes that let tunnels bypass your resolver, and recommend a DNS security service with the detection you need. The options we supply include Cisco Secure Access DNS Defense, Cisco Umbrella and the alternatives on our DNS security solutions page. Scope and pricing are confirmed at quote; contact us to start.