DNS is the protocol every device on your network uses, every time it connects to anything. It is also the protocol most security teams spend the least time thinking about. Firewalls inspect HTTP traffic. Endpoint agents scan files. But DNS queries pass through largely unchecked, and attackers know it.
According to a Forrester Consulting study commissioned by EfficientIP, 95% of organisations experienced DNS-related cyberattacks or vulnerabilities in the past year alone. A separate report from DNSFilter found that DNS threats grew 30% between October 2024 and September 2025, with the average internet user encountering 66 threats per day, up from 29 the year before. These are not abstract numbers. They represent phishing pages that loaded, malware that called home, and data that left the network without anyone noticing.
This guide explains why traditional DNS handling creates a dangerous gap in your security architecture, how modern attacks exploit it, and what a Zero Trust architecture looks like when DNS is treated as a first-class enforcement point.
How to close the DNS blind spot in your network
- Treat every DNS query as an access decision, not a background utility.
- Route all DNS traffic through a controlled resolver with policy enforcement.
- Apply identity and device context to DNS filtering rules.
- Monitor for tunnelling indicators such as abnormal query volume and encoded subdomains.
- Block newly observed domains by default and use allowlists for legitimate services.
- Centralise DNS logging and stream events to your SIEM for NIS2-ready audit trails.
Why DNS became such a large attack surface
The Domain Name System was built in the 1980s for openness and speed, not security. Every device needs DNS to function, so firewalls almost always allow it through. That design assumption has become the problem.
Traditional DNS operates on UDP port 53 in plaintext. Most organisations log the IP addresses of DNS requests but rarely analyse the content of the queries themselves. This gives attackers a protocol that is universally permitted, lightly monitored, and easy to abuse.
Three developments have made this worse in recent years.
Hybrid work dissolved the perimeter. Users resolve DNS queries from home networks, hotel Wi-Fi, and mobile connections. The corporate DNS resolver, if one exists, only sees a fraction of the traffic. Applications live in multiple clouds, and SaaS access generates DNS queries that never touch the internal network at all.
Encrypted DNS created new blind spots. DNS over HTTPS (DoH) and DNS over TLS (DoT) were designed to protect user privacy. They achieve that goal. They also hide DNS queries inside regular HTTPS traffic on port 443, making it impossible for traditional network security tools to inspect them. Modern browsers can bypass operating system DNS settings entirely and send queries directly to public resolvers, without any corporate policy applied.
Domain generation accelerated. Infoblox’s 2025 DNS Threat Landscape Report identified 100.8 million newly observed domains in a single year, with over 25% classified as malicious or suspicious. Attackers use algorithms to generate thousands of short-lived domains daily, rendering traditional blocklists ineffective. By the time a domain is catalogued, the attacker has already moved on.
How attackers exploit DNS today
DNS abuse goes far beyond visiting a dodgy website. Attackers use the protocol itself as an infrastructure layer for their operations.
DNS tunnelling and data exfiltration
DNS tunnelling encodes non-DNS data inside DNS queries and responses. Because DNS traffic is almost never blocked, attackers use this technique to exfiltrate sensitive data or maintain command-and-control (C2) channels with compromised devices. The data is encoded into subdomains of attacker-controlled domains, making it look like ordinary name resolution to basic inspection tools.
According to research compiled from multiple industry reports, roughly one in three organisations has experienced a DNS tunnelling incident. BlackFog reported in early 2026 that 96% of ransomware attacks in Q3 2025 attempted data exfiltration, with DNS tunnelling being one of the quieter methods available to attackers.
The danger of low-throughput exfiltration is particularly acute for mid-market teams. An infected device sending one DNS query per hour will not trigger volume-based alerts. The data leaves slowly, steadily, and silently.
AI-driven domain generation
Threat actors use AI to generate domain names algorithmically, producing thousands of unique domains that are active for hours or days at most. Traditional reputation-based DNS filtering relies on known-bad lists. When a domain exists for less than 72 hours, it is often gone before any blocklist picks it up. Infoblox reported that between August and November 2025, over 7.6 million new threat-related domains were discovered, a 20% increase over the previous quarter.
Phishing and fast-flux techniques
Phishing campaigns increasingly use fast-flux DNS, where the IP address behind a malicious domain changes rapidly to evade takedown efforts. Combined with AI-generated personalised lures, these campaigns achieve higher success rates than the broad phishing of previous years. DNS is the delivery mechanism: resolve the domain, load the page, capture the credentials. Without DNS-level controls, the phishing page loads successfully every time.
DNS hijacking and cache poisoning
Attackers can modify DNS records at the registrar level or inject false records into resolver caches. Both techniques redirect legitimate traffic to attacker-controlled servers. The user types the correct URL, but their device connects to a fake server. Without DNSSEC validation or continuous monitoring, these attacks can persist for hours before detection.
What Zero Trust DNS actually means
In a traditional network, DNS queries from internal devices are trusted implicitly. The device sends a query, the resolver returns an answer, and the connection proceeds. Zero Trust removes that implicit trust.
In a Zero Trust DNS model, every query is evaluated against policy before it resolves. The policy considers who is making the request (user identity), what device they are on (device posture), and whether the destination is permitted for their role. This turns DNS from a passive utility into an active enforcement point.
| Aspect | Traditional DNS | Zero Trust DNS |
|---|---|---|
| Trust model | Implicit trust for internal queries | Every query verified against policy |
| Visibility | IP-level logging only | Full context: identity, device, application |
| Filtering approach | Static blocklists | Dynamic, identity-aware policy with behavioural analysis |
| Encryption handling | Often plaintext or uncontrolled DoH | Controlled resolution through managed resolvers |
| Enforcement | Network-level, static rules | Dynamic, per-user and per-device |
The practical implication is that DNS policy becomes part of your access control framework, not a separate tool managed by a different team. When you enforce identity-based network access alongside DNS policy, you close two gaps simultaneously: the user can only reach approved applications, and their device can only resolve approved destinations.
Why mid-market teams struggle with DNS security
Large enterprises deploy dedicated DNS security platforms, threat intelligence feeds, and 24/7 SOC teams to monitor query patterns. Mid-market organisations rarely have that luxury.
The typical mid-market setup involves a firewall that handles DNS resolution as a secondary function. The firewall may offer basic category filtering, but it lacks the query-level analysis needed to detect tunnelling or DGA-generated domains. DNS logs, if they exist, sit in a format that is difficult to correlate with identity or device data. When the IT team has three people managing everything from endpoint patching to user support, DNS analytics falls off the priority list entirely.
This creates a paradox. Mid-market organisations face the same DNS-based threats as enterprises, without the resources to detect or respond to them. The answer is not to build a SOC. The answer is to choose a security architecture where DNS policy enforcement is built in, not bolted on.
How a SASE architecture closes the DNS gap
A Secure Access Service Edge (SASE) architecture converges networking and security into a single cloud-managed platform. DNS security fits naturally into this model because all traffic, including DNS, passes through policy enforcement points before reaching its destination.
DNS filtering as part of the Secure Web Gateway
A Secure Web Gateway (SWG) inspects and filters web traffic based on category, threat intelligence, and policy. When DNS resolution is integrated into the SWG, every query is evaluated before the connection is established. Malicious domains are blocked at the DNS layer, before any payload is downloaded or any phishing page is rendered. This “prevention before connection” approach stops threats earlier in the kill chain than endpoint-level detection.
Identity-based DNS policy
In a Zero Trust architecture, DNS policy is tied to identity and device posture, not network location. A finance team member on a managed, encrypted laptop gets access to financial application domains. A contractor on an unmanaged device gets a more restrictive DNS policy. The same user switching from a compliant device to a personal phone sees their permitted destinations adjust automatically. This is the same identity-driven model that governs application-level access, extended to name resolution.
Containing lateral movement through microsegmentation
Even if an attacker establishes a C2 channel through DNS tunnelling, the damage they can do depends on what the compromised device can reach. Microsegmentation limits each device to only its approved communication paths. A compromised workstation that can only reach one application and its update server gives the attacker almost nowhere to move. DNS tunnelling becomes a channel to a dead end.
Securing agentless devices
Printers, IoT sensors, and industrial equipment generate DNS queries but cannot run security agents. These devices are frequent targets for DNS amplification attacks and can serve as beachheads for lateral movement. NIAC hardware provides inline isolation for agentless devices, restricting their DNS resolution and network communication to explicitly permitted flows. This creates a secure bridge between IT and OT environments without disrupting production operations.
Centralised logging for compliance evidence
NIS2 requires organisations to demonstrate access governance, incident containment, and continuous monitoring. When DNS logs are unified with access logs, device posture records, and policy change history in a single console, producing audit evidence becomes a standard reporting task rather than an emergency data-gathering exercise. Streaming these events to a SIEM further strengthens your incident detection and response capabilities.
A practical DNS security checklist for your team
Use this checklist to assess your current DNS security posture and identify immediate improvements.
| Area | Question | Action if the answer is no |
|---|---|---|
| Resolution control | Do all devices resolve DNS through a managed, policy-enforcing resolver? | Route DNS through your SWG or a controlled resolver with filtering enabled |
| Encrypted DNS handling | Can you inspect or control DoH/DoT traffic from endpoints? | Enforce managed resolver use and block direct DoH to public resolvers |
| Tunnelling detection | Do you monitor for abnormal query volume, encoded subdomains, or unusual TXT record activity? | Enable DNS analytics or stream DNS logs to a SIEM with anomaly detection |
| New domain blocking | Do you block or flag queries to domains registered in the past 72 hours? | Apply a newly observed domain policy in your DNS filtering |
| Identity integration | Are DNS policies tied to user identity and device posture? | Move to an architecture where DNS filtering is part of identity-based access |
| Agentless devices | Are IoT, OT, and printer DNS queries restricted to approved destinations? | Deploy inline isolation to control DNS and network flows for unmanaged devices |
| Logging and evidence | Are DNS query logs retained, correlated with identity, and available for audit? | Centralise logging in your management console and configure SIEM streaming |
Practical examples in European mid-market environments
Local government with distributed sites. A Belgian municipality routes all DNS traffic from branch offices through a cloud-managed SWG. DNS filtering blocks categories including malware, phishing, and newly observed domains. SD-WAN ensures each site connects through the same policy enforcement point. When an employee clicks a link in a spoofed email, the DNS query resolves to a domain registered two days ago and is blocked before the page loads. Central IT sees the blocked query in a single dashboard alongside access logs from all sites.
Manufacturing plant with IT and OT convergence. A production environment uses NIAC hardware to isolate PLCs and HMIs from the corporate network. These devices can only resolve DNS for their update server and the historian. When a compromised USB introduces malware that attempts to contact a C2 domain, the DNS query is blocked by the inline isolation policy. The ransomware never reaches the command server, and the production line continues operating.
Professional services firm with remote workers. Consultants work from client sites, home offices, and co-working spaces. Their devices resolve DNS through the Jimber agent, which enforces the same filtering policy regardless of network. A consultant connecting from an airport lounge receives the same DNS protection as a colleague in the head office. TLS inspection on managed devices catches attempts to reach domains associated with credential phishing. The firm’s compliance team exports monthly DNS activity reports as part of their NIS2 evidence package.
How Jimber makes DNS security part of a unified Zero Trust platform
Jimber delivers Real SASE through a single cloud-managed platform that treats DNS as an integral part of the security architecture, not an afterthought. The Secure Web Gateway enforces DNS filtering with category-based controls, threat intelligence, and policy tied to user identity and device posture. Zero Trust Network Access ensures that even if a DNS query resolves successfully, the user can only reach the specific application their role permits.
For organisations managing multiple sites, SD-WAN routes all traffic through consistent policy enforcement. For environments with agentless devices, NIAC hardware restricts DNS resolution and network communication to approved flows, closing the gap that traditional approaches leave open.
Everything is managed from one console. Policies, logs, DNS activity, access events, and device posture data live in one place. For service partners managing multiple customers, the multi-tenant architecture means consistent DNS policy across every client without juggling separate tools.
Frequently asked questions
Is DNS filtering the same as a firewall?
No. A firewall controls traffic based on ports, protocols, and IP addresses. DNS filtering evaluates the domain being requested before any connection is established. It operates earlier in the kill chain and catches threats that firewalls cannot see, such as queries to newly generated malicious domains.
Can encrypted DNS (DoH/DoT) bypass our security controls?
Yes, if your architecture does not account for it. Modern browsers can send DNS queries directly to public resolvers over HTTPS, bypassing your corporate DNS settings entirely. The solution is to enforce resolution through a managed resolver and block direct DoH connections to external providers.
How does DNS security support NIS2 compliance?
NIS2 requires proportionate access controls, logging, and incident containment. DNS filtering provides a documented policy layer that blocks known threats before connection. Centralised DNS logs, correlated with identity and device data, produce the audit evidence that regulators expect.
What about devices that cannot run a security agent?
Printers, IoT sensors, and industrial equipment need DNS to function but cannot run agents. Inline isolation hardware restricts their DNS resolution to approved destinations only. This brings agentless devices under Zero Trust controls without requiring changes to the devices themselves.
Does DNS security replace endpoint protection?
No. DNS security and endpoint protection address different phases of the attack chain. DNS filtering blocks threats before connections are made. Endpoint protection handles threats that arrive through other vectors or bypass DNS controls. Both layers are stronger together.
How quickly can a mid-market team implement DNS-level controls?
With a cloud-managed SASE platform, basic DNS filtering can be active within days. Start by routing DNS through a managed resolver with category and threat filtering enabled, then progressively add identity-based policies and anomaly monitoring.
Ready to close the DNS blind spot in your network? Book a demo and see how DNS filtering, Zero Trust access, and centralised policy work together in one console.
