A DNS resolver is the system that answers name resolution requests and translates domain names into IP addresses. In sinkholing, the resolver is often the enforcement point, because it can intercept requests for malicious domains before traffic reaches the destination. Resolver location affects how much malicious activity can be observed.
How DNS Resolvers Shape Name Resolution
A DNS resolver sits on the path between users, applications, and the wider DNS hierarchy. It turns human-readable names into routable IP addresses, and that lookup step is often where policy, caching, forwarding, and filtering decisions first take effect. Because it influences what gets answered, it also influences what traffic can be seen, blocked, or redirected.
Why Resolver Placement Matters for Security
Resolver design is not just a performance choice. A local enterprise resolver can enforce protective DNS policy close to the endpoint, while a public or remote resolver may limit the organisation’s ability to apply consistent controls, observe queries, or stop known-bad destinations. That is why resolver placement affects both enforcement and visibility. When sinkholing is used, the resolver becomes the control point that can deny or reroute requests before a connection is made. For implementation guidance on protective DNS and resolver forwarding patterns, see the Protective DNS Guide.
Resolver Functions in Filtering and Sinkholing
A resolver can do more than answer queries. In a defensive setup, it may return a block page, a sinkhole address, or a null response for domains associated with malware, phishing, command-and-control, or other unwanted activity. That makes resolver behaviour a practical enforcement layer for response policy zones, denylisting, and domain-blocking rules. The same mechanism can also support investigation, because blocked lookups reveal what hosts tried to resolve even when the traffic never left the network. The broader DNS control set, including DNSSEC, DNS logging, DoH and DoT considerations, and tunnelling detection, is covered in NHIMG’s DNS Security Guide.
Operational Considerations for Trust and Visibility
The security value of a resolver depends on where it sits, who operates it, and whether clients are forced to use it. If endpoints can bypass it through hard-coded resolvers, encrypted DNS over an unmanaged path, or direct outbound DNS, policy enforcement weakens quickly. If the resolver is logging well, it becomes a useful visibility source for investigations, threat hunting, and correlation with other telemetry. If it is poorly managed, it can become a blind spot or a point of inconsistent policy application. For authoritative registry context on the DNS ecosystem and protocol identifiers, see IANA.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-9 — Email and Web Browser Protections | DNS resolvers underpin defensive DNS filtering and blocking of malicious destinations. |
| Recommendation — Use protective DNS to block known-malicious domains before connections are made. | ||
| NIST SP 800-53 Rev 5 | SC-7 — Boundary Protection | Resolvers enforce policy at a network boundary by permitting, blocking, or redirecting name lookups. |
| AU-2 — Event Logging | Resolver logs provide security telemetry for investigations and exposure analysis. | |
| Recommendation — Enforce resolver-based boundary controls to intercept and restrict unwanted DNS destinations. Log resolver activity to preserve query visibility for monitoring and incident review. | ||
| ISO/IEC 27001:2022 | A.8.20 — Network security | Resolver placement and control are part of network security architecture and traffic governance. |
| Recommendation — Apply network security controls so resolver traffic is governed and observable. | ||
| NIST CSF 2.0 | PR.DS-02 — Data-in-Transit is Protected | DNS transport choices and resolver paths affect how lookup traffic is protected in transit. |
| Recommendation — Protect DNS transport and resolver paths to reduce interception and manipulation risk. | ||
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 31, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org