DNS Resolver

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.

Expanded Definition

A DNS resolver is the system that receives a query for a domain name, looks up the matching IP address, and returns the result so traffic can proceed. In security operations, the resolver matters because it is not only a lookup service but also a policy choke point that can log, block, redirect, or sinkhole requests before a connection is made.

For NHI and agentic AI environments, DNS resolution becomes part of the control plane around machine-to-machine traffic. Service accounts, API-driven workloads, and autonomous agents often rely on DNS for discovery, callback paths, dependency access, and command-and-control style reachability. Definitions vary across vendors on how much enforcement should sit in the resolver versus adjacent network layers, so the practical question is usually where visibility and control are strongest without breaking normal application behavior. The NIST Cybersecurity Framework 2.0 is useful here because it frames identity and network control as part of a broader risk management program, not just a name lookup function.

The most common misapplication is treating every DNS server as a resolver, which occurs when teams ignore whether the system is recursive, authoritative, or merely forwarding queries.

Examples and Use Cases

Implementing DNS resolver controls rigorously often introduces latency and logging overhead, requiring organisations to weigh inspection depth against service reliability and user experience.

• A security team configures resolver-based sinkholing so requests for known malicious domains are redirected to an internal analysis endpoint before outbound connections occur.
• An agent platform uses a controlled recursive resolver to log outbound lookups from autonomous workloads, helping separate legitimate dependency calls from suspicious beaconing.
• A zero trust program routes service account traffic through approved resolvers to make domain access auditable instead of leaving resolution to unmanaged local settings.
• An incident response team reviews DNS query logs to identify which non-human identities reached a compromised domain after a secrets leak.
• For NHI governance, resolver telemetry is paired with the Ultimate Guide to NHIs to connect domain activity with broader lifecycle and access risks.

Resolver choice also affects whether defenders can observe internal-only lookups that never touch public infrastructure, which is often where machine identities reveal their real communication patterns.

Why It Matters in NHI Security

DNS resolvers matter in NHI security because they can expose shadow service behavior, reveal hard-coded dependencies, and provide an enforcement point when secrets or tokens are used to reach external infrastructure. When resolver logs are absent or fragmented, teams lose a practical way to connect an API key, service account, or agent action to the domains it contacted. That makes it harder to prove whether a workload is behaving as designed or participating in lateral movement, data exfiltration, or malicious callback traffic.

NHIMG research shows that 79% of organisations have experienced secrets leaks, and 77% of those incidents resulted in tangible damage. In that context, DNS evidence is often one of the few early signals that helps investigators trace where leaked credentials were used and what they touched next. It also supports governance decisions such as resolver placement, log retention, and isolation of high-risk workloads. The most important insight is that DNS becomes operationally unavoidable after suspicious traffic or a secrets incident has already occurred, when defenders need a reliable record of what non-human identities tried to reach.

Related resources from NHI Mgmt Group

• What breaks when DNS resolver bugs affect an identity-aware proxy?
• Secure DNS Resolver
• What breaks when internal DNS names are preserved but access governance is not updated?
• Why do DNS and edge configuration changes create IAM and security risk?