DNS filtering myths are obscuring a low-friction control

At a glance

What this is: This article argues that DNS filtering is often misunderstood, and its central claim is that blocking malicious domains at the DNS layer adds early, low-friction protection.

Why it matters: It matters because DNS filtering can reduce exposure before endpoint or perimeter controls engage, but only if teams manage policy precision, update cadence, and user impact carefully.

By the numbers:

• According to CISA, more than 91% of malware leverages DNS for attacks.

👉 Read CyberFOX's analysis of why DNS filtering deserves a place in the prevention stack

Context

DNS filtering is a control that stops devices from resolving or reaching known bad domains, which makes it a prevention layer rather than a detection layer. That distinction matters because many organisations still treat DNS as a plumbing detail instead of a governance point for blocking high-risk destinations before a connection ever forms.

The article frames DNS filtering as a complementary security control, not a replacement for firewalls or antivirus. That is the right lens for practitioners: the main question is how to tune blocklists, exceptions, and intelligence updates so the control reduces risk without creating avoidable business friction. In broader security programmes, this is a cyber control issue rather than an identity control issue.

Key questions

Q: How should security teams implement DNS filtering across remote and office users?

A: Start with a policy that follows the user and device, not the subnet. DNS filtering should remain active on managed laptops, home networks, and third-party Wi-Fi so malicious destinations are blocked before a session starts. That approach reduces exposure from phishing, malware delivery, and covert command channels without relying on the corporate perimeter.

Q: Why does DNS filtering reduce risk before other tools do?

A: Because it acts at the name-resolution stage, before the browser or application reaches the destination. If a malicious domain never resolves, the attacker loses a simple path for phishing delivery, malware staging, or command-and-control traffic.

Q: What are the signs that DNS filtering is too blunt?

A: Frequent help desk tickets, repeated bypass requests, and widespread use of temporary exceptions are strong indicators. Those symptoms usually mean the policy is blocking legitimate work rather than just high-risk destinations, which pushes users toward workarounds.

Q: Should organisations rely on DNS filtering instead of firewalls and antivirus?

A: No. DNS filtering is strongest as an early prevention layer, while firewalls and antivirus address different parts of the attack path. The best result comes from layered controls that reduce exposure at multiple points, not from expecting one mechanism to do everything.

Technical breakdown

How DNS filtering interrupts malicious domain resolution

DNS filtering works by checking a requested domain against category rules, threat intelligence, or allow and deny lists before the resolver returns an answer. If the domain is judged risky, the request is blocked or redirected, preventing the browser, app, or endpoint from establishing the connection. That makes DNS a choke point for malware delivery, phishing, and command-and-control traffic that depends on successful name resolution. Because the control operates early in the network path, it can reduce exposure even when endpoint protections miss the initial signal.

Practical implication: place DNS policy where it can block resolution before a connection is established, not after the payload arrives.

Why static blocklists age badly against new domains

Free or static blocklists are brittle because malicious infrastructure changes constantly. Attackers register new domains, rotate hosting, and repurpose compromised infrastructure faster than manual list maintenance can keep up. Modern DNS filtering depends on continuously refreshed intelligence, reputational scoring, and policy updates so newly observed threats are blocked quickly enough to matter. Without that dynamism, the control becomes a retrospective archive rather than an active defence layer.

Practical implication: verify that threat feeds and policy updates are continuous, not periodic, before relying on DNS filtering for prevention.

Policy granularity is what keeps DNS filtering usable

DNS filtering fails politically before it fails technically when organisations deploy blunt controls that break legitimate work. The operational value comes from category-based rules, per-site exceptions, and role-aware exceptions that let security teams block high-risk destinations while preserving access to needed services. This is why DNS filtering is often easier to adopt than harsher network controls: it can be narrow enough to support recruiting, SaaS workflows, and partner access without forcing a broad allow-all posture.

Practical implication: build exception governance into the DNS policy model so the control stays precise and administratively acceptable.

Threat narrative

Attacker objective: The attacker wants to establish contact with malicious infrastructure and use that channel to deliver payloads, steal data, or sustain command-and-control.

1. Entry begins when a user or endpoint attempts to resolve a malicious domain used for phishing, malware delivery, or command-and-control.
2. Escalation follows if the request is allowed, because the attacker can deliver payloads or maintain callback traffic through the resolved connection.
3. Impact occurs when malware executes, credentials are stolen, or a compromised host continues to beacon to attacker infrastructure.

NHI Mgmt Group analysis

DNS-layer prevention is still underused because many teams misread visibility as value. Security programmes often reward controls that generate dramatic alerts, but prevention at the name-resolution layer can remove entire attack paths before they become incidents. That changes the control conversation from detection theatre to exposure reduction, which is a healthier security outcome for most environments.

Policy precision is the real governance test for DNS filtering. A control that blocks too much will be bypassed, while a control that blocks too little becomes symbolic. The practical standard is whether teams can enforce categories, exceptions, and reviewable change processes without turning the policy into a manual exception queue.

DNS filtering belongs in layered defence, not as a substitute control. Firewalls, endpoint protection, and secure web controls each cover different points in the attack path, and DNS filtering is strongest where attackers depend on domain resolution. The right posture is to use it as an early denial layer that reduces how often downstream tools must deal with preventable traffic.

Low-friction controls matter because user acceptance determines whether prevention survives contact with operations. If a security measure is visible only when it breaks work, it will be treated as an obstacle. DNS filtering can work well precisely because it is usually invisible, which makes it a practical example of security that scales when governance is careful.

What this signals

DNS filtering is a useful reminder that not every control needs to be noisy to matter. For most programmes, the real question is whether early-stage prevention is actually reducing attack surface, or whether the organisation is overvaluing post-compromise visibility.

Policy drift at the DNS layer: over time, exceptions and category changes can turn a precise control into a weak one. Teams should review allow-lists, test resolution outcomes, and tie policy ownership to operational change management so the control does not degrade quietly.

For practitioners

• Map DNS filtering to your prevention stack Place DNS filtering alongside endpoint and perimeter controls so it blocks known bad domains before connection establishment, not as a replacement for other controls.
• Replace static lists with continuously refreshed intelligence Validate that threat feeds, category updates, and policy changes are automatic and timely, because attacker domains change faster than manual maintenance cycles.
• Design an exception workflow before rollout Define who can approve site exceptions, how long they last, and how they are reviewed so granular control does not collapse into an unmanaged allow-list.
• Measure blocked resolutions and user impact together Track blocked domain attempts, false positives, and help desk tickets so you can prove the control is reducing risk without creating avoidable disruption.

Key takeaways

• DNS filtering is valuable because it blocks risky destinations before other security tools have to react.
• The control only stays effective when policy updates are continuous and exceptions are tightly governed.
• Layered defence still matters, but DNS filtering can remove a large share of preventable exposure early in the attack path.

Key terms

• DNS Filtering: DNS filtering is a control that blocks, allows, redirects, or reroutes traffic based on domain resolution requests. It reduces exposure to phishing, malware, and unwanted destinations by applying policy at the point where devices attempt to resolve names into reachable internet endpoints.
• Threat Intelligence: Threat intelligence is contextualised information about adversaries, techniques, and signals that helps teams decide what matters and what to do next. In practice, it becomes useful when it is tied to detection, identity scope, and response actions rather than remaining a feed of indicators.
• Allow-List Exception: An allow-list exception is a scoped rule that permits access to a domain or category that would otherwise be blocked. Good exception governance requires clear ownership, expiration, and review, because unmanaged exceptions can quietly erode the security value of a precise filtering policy.

What's in the full article

CyberFOX's full blog post covers the practical detail this post intentionally leaves for the source:

• Examples of category-based DNS policies and allow-list handling for common business exceptions
• Guidance on how to tune DNS filtering so it complements firewall and antivirus controls
• Operational arguments for using DNS filtering to reduce incident response load
• The article's own framing of why misperceptions about DNS filtering slow adoption

👉 CyberFOX's full article expands on the policy choices and operational trade-offs behind DNS filtering

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course, the industry's only accredited NHI security programme. It is built for practitioners who need governance depth across identity and access programmes.