DNS: The Protocol Everyone Allows and Attackers Love

The one protocol nobody restricts

Open any firewall ruleset in any organisation and look for the DNS rules. You will find something like this: allow any internal host to reach any external DNS server on port 53, UDP and TCP. It is there because everything needs DNS. Web browsing, email, application APIs, package managers, OS updates, certificate validation. If DNS stops working, tickets start flying within minutes.

So DNS gets a pass. It is allowed from every segment, every VLAN, every tier. Database servers, payment processing hosts, domain controllers, developer workstations, they all resolve DNS against the internet either directly or through a chain of resolvers that ultimately reaches the public internet. And because DNS is so fundamental, so constant, so high-volume, nobody looks at it closely.

Attackers know this. DNS is the single most reliable protocol for moving data out of a network without triggering alarms. It is the protocol that firewalls almost never block, that security teams almost never inspect, and that monitoring tools almost never flag.

How DNS exfiltration actually works

The mechanics are straightforward once you see them. An attacker who has compromised a host inside your network wants to move data out. They cannot use HTTP because your proxy blocks unknown destinations. They cannot use SMTP because your mail gateway restricts relay. They cannot open a reverse shell because your firewall blocks outbound connections on non-standard ports. But DNS works. It always works.

Here is the process. The attacker registers a domain, say data-collect.example. They configure themselves as the authoritative nameserver for that domain. Now, any DNS query for anything.data-collect.example will eventually reach the attacker's server, because that is how DNS resolution works. The recursive resolver your host queries doesn't have the answer cached, so it walks the delegation chain until it reaches the attacker's authoritative server.

The attacker's malware on the compromised host takes whatever data it wants to steal, say a database credential, and encodes it as a subdomain label. The credential admin:P@ssw0rd123 becomes YWRtaW46UEBzc3cwcmQxMjM.data-collect.example after base64 encoding. The malware issues a DNS query for that hostname. The query travels through your internal resolver, out to the internet, through the DNS hierarchy, and arrives at the attacker's server. The attacker decodes the subdomain label and has the credential.

For larger data sets, the malware splits the data into chunks, each encoded as a separate subdomain query. A 10 KB file becomes roughly 150 DNS queries. Sent at a rate of one query every few seconds, the entire file leaves your network in under ten minutes, hidden in what looks like ordinary DNS traffic.

The response side works too. The attacker's server can send data back in TXT records, which can hold up to 255 bytes per string and multiple strings per record. This creates a bidirectional communication channel, enough for command-and-control instructions, configuration updates, or even downloading small payloads. All of it transiting port 53, all of it looking like DNS.

DNS tunnelling for command and control

Data exfiltration is only half the story. Malware families have used DNS tunnelling for command and control for over a decade. The infected host queries a specially crafted subdomain to check in with the attacker. The response, encoded in TXT or CNAME records, contains the next instruction: scan this subnet, dump these credentials, move laterally to that server.

The bandwidth is low. A typical DNS query maxes out at 253 bytes for the domain name, and responses are bounded by UDP packet size limits (though TCP can extend this). But bandwidth is not the point. An attacker does not need gigabit throughput to exfiltrate an SSH private key (roughly 1,600 bytes, about 25 DNS queries), a set of database credentials (under 200 bytes, a single query), or a list of 500 customer records with names and email addresses (perhaps 40 KB, around 600 queries spread over an afternoon).

From the perspective of your firewall, your IDS, and your SIEM, this looks like a host making DNS queries. That is exactly what every host on your network does, thousands of times a day. The queries are syntactically valid. They use standard ports. They go to your internal resolver. Nothing in a conventional firewall rule can distinguish "look up google.com" from "exfiltrate the customer database one subdomain at a time."

DNS-over-HTTPS breaks your visibility entirely

If standard DNS exfiltration is difficult to detect, DNS-over-HTTPS (DoH) makes it nearly impossible with traditional tools.

DoH wraps DNS queries inside HTTPS connections to well-known resolvers like Cloudflare (1.1.1.1) and Google (8.8.8.8). The traffic is encrypted, so your DNS security tools, your RPZ feeds, your query logging, none of it sees anything. From the network's perspective, the host is making an HTTPS connection to a Cloudflare IP address. That is indistinguishable from millions of other legitimate HTTPS connections.

Modern browsers enable DoH by default in many configurations. Firefox has shipped with DoH enabled for users in several countries. Chrome and Edge support it. This means that even without malware, endpoints in your network may already be bypassing your DNS infrastructure entirely, and doing so by design.

For an attacker, DoH is ideal. They can tunnel exfiltration traffic inside encrypted HTTPS to a major cloud provider's IP address. Your firewall sees an outbound HTTPS connection to 1.1.1.1. Your proxy sees SNI for cloudflare-dns.com. Nothing about this looks unusual. But inside that encrypted stream, the attacker is issuing DNS queries to their own domain, encoding stolen data in subdomains exactly as before, with the added benefit that nobody can inspect the content.

The "any internal host to any external DNS" problem

Most firewall rulesets have a rule, sometimes explicit and sometimes implicit through a broad outbound allow, that permits any internal host to reach external DNS servers. This is the rule that makes everything work, and it is also the rule that makes DNS exfiltration trivially easy.

Think about what this means for your sensitive segments. Your database tier, holding customer payment data, can resolve DNS against the internet. Your PCI cardholder data environment can issue DNS queries to any resolver. Your domain controllers, which hold the keys to your entire Active Directory, can talk to external DNS servers.

None of these systems need to resolve DNS directly against the internet. They need to resolve internal hostnames and perhaps a handful of external services. But the firewall rule does not make that distinction. It says: any host, any external DNS server, port 53, allow.

This is a segmentation failure. You can have perfect microsegmentation between your application tiers, strict east-west controls, zero trust between every workload, and still have a wide-open DNS path from your most sensitive systems directly to the internet. An attacker who compromises a database server can immediately begin exfiltrating data through DNS without needing to pivot through any other segment.

What your DNS policy should look like

Fixing DNS security is not about blocking DNS. Everything still needs name resolution. It is about controlling how DNS flows through your network, the same way you control how HTTP or database traffic flows.

Centralised internal resolvers. Every host in your network should resolve DNS through a small set of internal resolvers that you control. No endpoint, no server, no container should be issuing DNS queries directly to the internet. Your internal resolvers handle recursion and caching on behalf of the entire network. This gives you a single point of visibility and control.

Block direct external DNS from internal segments. Once you have centralised resolvers, block port 53 (both UDP and TCP) outbound from all internal segments except the resolver subnet. If a compromised host tries to query an external DNS server directly, the firewall drops the traffic. The host must use your internal resolvers, where you can log, filter, and inspect every query.

DNS filtering and response policy zones (RPZ). Your internal resolvers should run RPZ feeds that block known malicious domains, newly registered domains, and domains associated with DNS tunnelling infrastructure. This is not foolproof, attackers register new domains constantly, but it raises the bar significantly. Combine RPZ with threat intelligence feeds and you catch a meaningful percentage of commodity malware C2 channels.

Block known DoH providers by IP. Maintain a list of IP addresses for major DoH providers (Cloudflare, Google, Quad9, and others) and block direct HTTPS access to them from internal segments. This prevents both malware and misconfigured browsers from bypassing your DNS infrastructure. Yes, this is a game of whack-a-mole as new DoH providers appear, but the major ones account for the vast majority of DoH traffic.

DNS query logging and anomaly detection. Log every query that hits your internal resolvers. Look for anomalies: unusually long subdomain labels (a hallmark of base64-encoded data), high query volumes to a single domain, queries for domains with high entropy in the labels, TXT record queries to unusual domains, and queries from hosts that historically make very few DNS requests suddenly issuing hundreds.

Segment your resolver access. Your database tier does not need the same DNS access as your developer workstations. Consider running separate resolver instances for sensitive segments, with stricter filtering and lower thresholds for anomaly alerts. A PCI cardholder data environment should have a resolver that only resolves the specific external domains those systems actually need, with everything else blocked.

Mapping this to compliance frameworks

If you are working under PCI DSS, CIS Controls, or NIST frameworks, DNS security is not optional. These frameworks explicitly address the risks described above, even if they do not always spell out "DNS exfiltration" in those exact words.

When you run your firewall rules through netbobr, several rules flag DNS-related risks directly. PCI-NET-033 detects DNS traffic patterns consistent with covert channels from internal segments to external destinations. If your database tier can reach external DNS directly, this rule will flag it. CIS-NET-051 identifies traffic to known DoH provider IP addresses, catching both intentional DoH usage and malware that leverages DoH for encrypted exfiltration. CIS-NET-052 looks specifically at DNS covert channel patterns originating from sensitive network segments where DNS exfiltration would be most damaging.

On the NIST side, NIST-NET-061 covers DoH traffic, and NIST-NET-062 addresses DNS covert channel detection more broadly. Together, these rules give you a structured way to identify exactly where your DNS policy has gaps, mapped directly to the compliance framework your auditors care about.

The point is not to generate a report for the sake of compliance. It is to find the specific firewall rules that allow DNS traffic flows you did not intend and probably did not know existed.

Why this matters more than most teams think

DNS is infrastructure. It is invisible when it works and catastrophic when it doesn't. That combination makes it politically difficult to restrict. Nobody wants to be the person whose DNS policy change broke email or stopped deployments.

But the cost of leaving DNS uncontrolled is real. Every segment that can reach external DNS directly is a potential exfiltration path. Every host that can use DoH is invisible to your DNS security stack. Every firewall ruleset that allows "any to any" on port 53 is a segmentation policy that stops at DNS and goes no further.

The fixes are not exotic. Centralised resolvers, outbound DNS blocking, RPZ, DoH restrictions, query logging. These are well-understood, widely deployed capabilities. The gap is not technology. The gap is that DNS gets treated as a utility rather than a security-relevant protocol.

Start by answering one question: can your database servers resolve DNS against the internet directly? If the answer is yes, your segmentation has a hole in it, and DNS is the path through.

Tools like netbobr can help you find those paths systematically across your entire ruleset, rather than manually auditing rules one at a time. But even without automation, the exercise of mapping DNS flows through your firewall policy is worth doing. You will almost certainly find paths you did not intend to allow.

The protocol that deserves more scrutiny

DNS is the last protocol standing in many hardened environments. After you lock down HTTP, restrict database ports, segment east-west traffic, and deploy zero trust controls, DNS often remains the one protocol that flows freely everywhere. Attackers know this. The tooling for DNS exfiltration is mature, widely available, and effective against conventional security stacks.

The organisations that treat DNS as a first-class security concern, that restrict it, monitor it, and segment it with the same rigour they apply to every other protocol, close one of the most reliable exfiltration paths available to attackers. The ones that don't leave a door open that no amount of east-west segmentation can shut.