The essentials in 30 seconds
- DNS exfiltration hides data in queries that almost every network lets through, and that most DLP tools never look at.
- Blocking outbound port 53 is not enough: the internal resolver becomes the relay.
- What to check: resolution, encrypted DNS, filtering, detection tested at low rates and the response chain.
A typical case: an organisation cleanly blocks DNS, FTP and paste sites such as Pastebin, while other, more mundane paths stay open. The posture is not uniformly weak. It is uneven. A well-locked DNS still needs re-checking: a channel closed in March can reopen in June, thanks to a browser update.
DNS exfiltration means getting data out of an information system by hiding it in DNS queries or responses, a protocol that almost every network lets through. What you need to check is whether your resolvers, your egress filtering and your SOC see it go by. Here is the list of controls, with no attack recipe.
Why DNS remains a blind spot in data leak prevention
DNS is a service protocol that every workstation needs in order to function. We rarely see it inspected with the same care as web traffic or email. One more query among thousands of others: nobody notices it.
Most DLP products on the market analyse files, attachments or HTTP flows. They do not read the content of a domain name you request. Your DLP is not badly configured. DNS was simply never part of its job, and this kind of gap only comes to light through testing (see our guide to data exfiltration testing).
MITRE ATT&CK places this behaviour in the Exfiltration tactic, under technique T1048 (Exfiltration Over Alternative Protocol); the use of DNS as an application-layer channel also appears under T1071.004, and protocol tunnelling under T1572. To place DNS among the other techniques, see the Exfiltration tactic (TA0010) explained for defenders.
Three questions to ask before any test
- Who is allowed to resolve to the Internet? If every workstation can query any external DNS server directly, your other controls become secondary.
- Where are the logs? Without resolver logs in your SIEM, you have no after-the-fact detection.
- Is encrypted DNS under control? DNS over HTTPS (DoH, RFC 8484, on port 443) and DNS over TLS (DoT, RFC 7858, on port 853), enabled by Firefox, Chrome or an application, can silently bypass your corporate resolver.
Checklist of controls to validate
1. Resolution architecture
- Your workstations and servers use only the authorised internal resolvers.
- Your firewall blocks outbound port 53 (UDP and TCP) for anything that is not an authorised resolver.
- You block port 853 (DoT), or allow it only to a closed list.
- Well-known public DoH resolvers (Cloudflare’s 1.1.1.1, Google’s 8.8.8.8, 9.9.9.9 and others) are blocked at the proxy, and your browser policies disable unmanaged DoH (DnsOverHttpsMode for Chrome and Edge, DNSOverHTTPS for Firefox).
- Your sensitive segments (databases, production) have no unnecessary external resolution.
2. Filtering and reputation
- Your resolver applies reputation-based filtering (newly registered domains, high-risk categories).
- Domains registered less than 30 days ago are blocked or placed under observation.
- An RPZ-type mechanism (response policy zones) is in place and kept up to date.
All of this falls more broadly under egress filtering.
3. Behavioural detection
- Alert on an abnormal volume of queries to the same parent domain.
- Alert on long subdomains (under RFC 1035, a DNS label can be up to 63 characters and a full name up to 253) or high-entropy subdomains, a sign of encoding.
- Alert on an unusual proportion of uncommon record types (TXT, NULL) from a user workstation.
- Correlation of workstation, user and time, to tell a legitimate service apart from isolated behaviour.
4. Response chain
- The alert actually reaches your SOC, with a consistent priority level.
- Your analysts have a procedure to isolate the workstation and block the domain.
- You measure the time between the event and the action, in minutes.
Table: control, common gap, expected evidence
| Control | Common gap | Evidence to obtain |
|---|---|---|
| Blocking direct DNS | Rule in place but exception too broad (an entire subnet allowed) | A query to an external resolver from a standard workstation is rejected and logged |
| Controlling DoH | Policy applied to a single browser | No unmanaged encrypted resolution from common browsers and applications |
| Reputation filtering | List not updated, or “monitor” mode never switched to blocking | A newly registered test domain is blocked, not just flagged |
| Anomaly detection | Thresholds set to avoid noise, and therefore too high | A low-rate replay triggers an alert |
| Forwarding to the SIEM | DNS logs not collected, or sampled | The test event can be found in the SIEM with workstation and user |
A concrete scenario: a test that wrongly “passes”
A typical scenario, on a Monday, in a local authority that has blocked outbound port 53 and deployed a filtering resolver. In the console, the DNS channel is closed. Picture a replay with synthetic data from a finance department workstation, at a low rate (2 or 3 queries per minute), to a test domain we control.
Result: no alert. The internal resolver forwarded the queries, exactly as it is supposed to. Reputation filtering saw nothing, because the test domain was not categorised. And the entropy rule did exist, with a threshold designed for large volumes.
Diagram · blocked directly, relayed internally
Next step
What does your DNS resolver let through?
A 30-minute demo: a full campaign across the 8 channels we test, on our demo environment. The POC shows, on site, how the solution behaves in your environment, on one simple scenario in a synthetic environment. What actually leaves through your channels is what the pilot shows you.
How to test DNS exfiltration without using any real business data
3 principles guide a defender-side DNS test:
- Synthetic data only. Decoys in a realistic format (fake customer numbers, fake IBANs) are enough to put your rules to the test. See testing exfiltration in production with synthetic data.
- A controlled destination domain, declared in advance to your network teams and to the SOC, depending on how blind you want the test to be.
- Several rates and several segments. A single test from the administrator’s workstation says nothing about a salesperson’s laptop at home or an application server. That is why we place at least one agent per subnet, on Windows or Linux.
Above all, repeat. A DNS configuration moves: a new resolver, a browser update that re-enables DoH, an exception added in a hurry on a Friday evening. A test that passed 6 months ago can fail today. With Enforcis, each DNS campaign produces dated, traceable results; upcoming versions will let you schedule periodic replays, or replays triggered by a change, depending on how critical the scope is and how fresh the evidence needs to be, and will bring SIEM integrations.
FAQ
Does a traditional DLP detect DNS exfiltration?
Rarely. Most DLP tools analyse content (files, messages, web flows), not the domain names being resolved. Detection relies instead on your resolver, DNS filtering and the SIEM.
Is blocking outbound port 53 enough?
No. It closes direct DNS, but the internal resolver remains a legitimate relay to the Internet, and DoH goes through port 443 like any website. Add filtering and behavioural detection.
Does encrypted DNS make control impossible?
Not if it is managed. Disable unmanaged DoH through browser policy, block well-known public DoH resolvers and route your workstations through your own resolver. The real blind spot is the application you have not inventoried that ships with its own DoH.
Which DNS exfiltration signals should you monitor in resolver logs?
We look at 4 signals first. An abnormal volume of queries to the same parent domain. Long or high-entropy subdomains: a label can reach 63 characters under RFC 1035. An unusual share of TXT or NULL records from a user workstation. And domains registered less than 30 days ago. Correlate workstation, user and time in your SIEM, then check with a replay at 2 or 3 queries per minute that your thresholds fire.