DNS protection closes an overlooked attack path for internet traffic

At a glance

What this is: This is an analysis of why DNS security and protective DNS matter, with the key finding that DNS is an early control point for blocking phishing, ransomware, and command-and-control traffic.

Why it matters: It matters because IAM, NHI, and broader security teams need visibility and enforcement at the point where connections begin, not only at endpoints or the perimeter.

By the numbers:

• 88% of organizations experienced one or more DNS attacks in 2023, according to an IDC study reported by DNSFilter.

Context

DNS is the naming layer that turns a domain into a destination, and that makes it one of the earliest places an organisation can validate or block a connection. Many security programmes still treat DNS as plumbing rather than policy, which leaves a gap between user intent and enforced access.

That gap matters because threats often begin before an endpoint, identity, or email control has enough context to intervene. Protective DNS moves enforcement closer to the start of the request path, which makes it relevant to Zero Trust programmes and to attack surface management where exposed services and risky destinations need to be seen sooner.

Key questions

Q: How should security teams use DNS filtering in a Zero Trust architecture?

A: Use DNS filtering as an early enforcement point, not as a substitute for identity or endpoint controls. The value is that a request to a malicious destination can be denied before a session is created. That reduces exposure, supports continuous verification, and gives teams a practical way to block risky traffic across hybrid and remote environments.

Q: Why does DNS matter so much for phishing and ransomware defence?

A: Because the malicious destination often appears first as a domain lookup. If the lookup is blocked, the user never reaches the phishing page and malware never reaches its command-and-control path. This shifts defence to the start of the attack chain, where it can stop the connection rather than only respond after compromise.

Q: What are the signs that DNS controls are not giving enough visibility?

A: Common signs include unexplained SaaS usage, lookup spikes to unfamiliar domains, and gaps between endpoint alerts and what the network team sees in logs. If DNS telemetry is not flowing into detection workflows, the organisation loses an early view of risky behaviour and has less context when investigating an incident.

Q: How should security teams treat managed DNS in access governance?

A: Security teams should treat managed DNS as part of the access path, not a separate infrastructure detail. If resolution is slow, unavailable, or redirected, users lose reliable access even when authentication and policy controls still work. Governance should include resolver placement, redundancy, failover behaviour, and hijack resilience alongside service availability controls.

Technical breakdown

How DNS filtering blocks malicious lookups before connection

DNS filtering inspects a domain lookup before the browser or application reaches the target system. If the queried domain is known or suspected to host malware, phishing content, or command-and-control infrastructure, the resolver can block or reroute the request. This is different from endpoint detection because it acts at the naming layer, before the session is established. It also reduces downstream load on perimeter tools by preventing traffic that would otherwise need inspection or cleanup.

Practical implication: Place policy at the resolver layer so malicious destinations are denied before any session, token, or payload transfer begins.

Why protective DNS strengthens Zero Trust and access control

Zero Trust assumes every request must be verified, and DNS is a practical enforcement point because every internet connection begins there. Protective DNS does not replace identity checks, device posture, or application controls; it adds a pre-connect decision layer that can block unauthorized destinations even when a user or workload appears legitimate. That matters for hybrid and remote environments, where network boundaries are less reliable and enforcement must follow the request rather than the location.

Practical implication: Use DNS policy as part of the access decision chain, not as a standalone web filtering tool.

How DNS telemetry improves detection of shadow IT and exfiltration

Every DNS query creates a record of where users, devices, and applications are trying to go. That telemetry can reveal unsanctioned SaaS use, unusual lookup patterns, or data leaving the environment through unexpected destinations. Because DNS is low-friction and high-volume, it often exposes behavioural changes before a full incident appears in endpoint or SIEM data. The value is not only blocking, but also creating a baseline of normal and abnormal resolution behaviour. See the Attack Surface Management Guide.

Practical implication: Feed DNS logs into detection workflows and look for destination changes that indicate unsanctioned tools or possible exfiltration.

NHI Mgmt Group analysis

DNS is no longer a plumbing control, it is a policy control. Organisations that leave DNS at the margins create a blind spot at the first point of external contact. That blind spot matters because many attacks begin with a simple lookup, and once the destination resolves, downstream controls are already behind the curve. The governance lesson is to treat resolution as an access decision, not just a network service.

DNS visibility is a control-plane problem, not just a logging problem. Query data becomes useful only when it is tied to enforcement, anomaly detection, and response logic. Without that connection, DNS logs explain what happened after the fact but do little to prevent shadow IT, risky SaaS use, or early-stage exfiltration. Practitioners should align DNS telemetry with the same operational accountability they expect from identity and endpoint controls.

Protective DNS complements, but does not replace, identity controls. Authentication proves who or what is requesting access; DNS policy helps decide whether the destination should be reachable at all. That distinction matters in hybrid environments where trusted identities can still reach malicious infrastructure. Teams that understand both layers can reduce exposure without overloading endpoint or perimeter tooling.

Zero Trust becomes more credible when the first trust decision happens at DNS. Continuous verification is difficult if the environment only checks users after the request is already in motion. DNS filtering shifts part of the trust decision earlier in the path, which is especially useful for remote users, unmanaged devices, and workloads that can reach the internet directly. The practitioner takeaway is simple: if the lookup is untrusted, the session should never start.

What this signals

DNS enforcement will increasingly sit closer to policy than to network plumbing. As organisations move toward distributed access models, the first trust decision has to happen earlier in the request path. That shifts DNS from a utility function into a control that can reduce exposure before identity, endpoint, or cloud layers need to react.

Destination trust will become a governance question. Teams will need to decide not only which identities are allowed, but which external destinations are allowed to resolve under normal business conditions. That makes DNS policy part of broader access governance, especially where unmanaged devices, remote work, and direct-to-internet application traffic are common.

DNS telemetry will matter more for detecting identity-adjacent risk. When a legitimate user, service, or application starts resolving unfamiliar domains, that behaviour can indicate phishing follow-through, malware callback attempts, or unsanctioned SaaS use. Practitioners should prepare to correlate DNS activity with identity and endpoint signals so suspicious traffic is not analysed in isolation.

For practitioners

• Define DNS as an enforcement layer Set policy for malicious, suspicious, and high-risk domains at the resolver or recursive DNS layer so blocked lookups fail before the session starts.
• Integrate DNS logs into detection workflows Send query telemetry into SIEM and threat hunting pipelines so analysts can spot unusual destinations, shadow IT, and exfiltration patterns early.
• Map DNS policy to Zero Trust decisions Use DNS controls alongside identity and device checks so destination trust is evaluated as part of the access path, not after connection establishment.
• Block known risky categories with clear governance Document acceptable-use categories such as gambling, adult content, and streaming under a formal policy so enforcement is consistent across users and sites.

Key takeaways

• DNS security belongs closer to the start of the access path than many programmes currently place it, because threats often begin with a lookup.
• The strongest value of protective DNS is early blocking plus telemetry, which helps stop phishing, ransomware callbacks, and suspicious destinations before they reach the endpoint.
• For practitioners, the main shift is governance: DNS policy should be treated as part of access control and detection, not as a standalone filtering utility.

Related NHI Mgmt Group resources: Attack Surface Management Guide · DNS Security Guide · Agentic AI Security Guide

Key terms

• Protective DNS: Protective DNS is the use of DNS policy and intelligence to prevent access to harmful or non-compliant destinations. It combines domain resolution with security controls such as threat blocking, category filtering, and reporting, giving organisations an early checkpoint that works across devices, locations, and work models.
• Command and control infrastructure: The systems an attacker uses to send instructions to compromised hosts and receive data back. In malware operations, C2 is often built to survive takedowns, rotate domains, and hide inside normal network traffic so defenders cannot easily separate malicious from legitimate communication.
• DNS Telemetry: DNS telemetry is the collection of query, resolution, transport, and validation signals used to understand how name resolution behaves in production. In identity-heavy environments, it helps teams separate access issues from infrastructure issues and gives incident responders evidence about where a service path failed.

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. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.