Resolver

A resolver is the service that receives a domain lookup and returns the matching IP address or other DNS record. It sits at a critical control point because it can shape what users and workloads can reach, what gets logged, and which traffic paths are trusted.

Expanded Definition

In DNS operations, a resolver is the lookup service that translates a domain name into the record a client needs to continue a connection. In NHI security, that makes the resolver more than plumbing: it becomes a policy and visibility choke point for service-to-service communication, telemetry, and trust decisions.

Definitions vary across vendors when resolver capabilities are bundled with recursive DNS, secure web gateways, or enterprise filtering. In practice, the term should be read narrowly as the component that answers queries, not the broader stack that inspects, blocks, or rewrites traffic. That distinction matters because the resolver may expose query logs, enforce internal name resolution rules, and determine whether workloads reach public or private endpoints. For governance, this is closely related to the control intent in the NIST Cybersecurity Framework 2.0, especially where asset visibility and access control depend on accurate name resolution.

Resolvers are often discussed alongside split-horizon DNS, private DNS zones, and service discovery, but those are adjacent patterns, not synonyms. The most common misapplication is treating any DNS forwarder as a trusted control point, which occurs when teams ignore whether the resolver is authoritative for internal names, logs sensitive queries, or can be bypassed by alternate paths.

Examples and Use Cases

Implementing resolvers rigorously often introduces latency, policy, and operational overhead, requiring organisations to weigh tighter control over name resolution against the complexity of maintaining availability and low query response times.

• A workload in a restricted subnet uses an internal resolver so private service names never leave the enterprise network boundary.
• An enterprise security team reviews resolver logs to detect unusual lookups for newly registered domains or exfiltration-style DNS patterns.
• A platform team points container workloads at a resolver that returns internal service addresses, while external names still resolve through approved recursive paths.
• A red team finds that bypassing the intended resolver exposes public DNS answers that differ from the organisation’s private namespace, revealing a split-horizon gap.
• Security architects align resolver placement with NHI governance because the same service account, API key, or agent may depend on DNS to reach secrets managers and tool endpoints, as discussed in the Ultimate Guide to NHIs.

Resolver design also affects service discovery patterns used by agents and automation. The operational question is not only whether the name resolves, but whether the resolution path is the one that policy intended. Guidance remains uneven across the industry, so organisations should document which resolver is authoritative for which namespace and how exceptions are handled.

Why It Matters in NHI Security

Resolvers matter because NHIs depend on them to reach APIs, vaults, internal services, and model tooling. When resolution is misconfigured, the failure is not just connectivity loss. It can expose credentials in logs, route automation to the wrong endpoint, or silently weaken controls around private infrastructure. NHIMG data shows that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, which makes resolver-driven access paths especially sensitive when those workflows are under-logged or over-trusted. The same Ultimate Guide to NHIs also reports that 97% of NHIs carry excessive privileges, which means a compromised lookup path can become a broad blast-radius problem very quickly.

For defenders, the resolver is a practical enforcement point for zero trust, segmentation, and observability. For attackers, it is an opportunity to redirect requests, hide exfiltration, or exploit inconsistent naming between environments. The security value comes from treating resolution as part of identity-aware access, not as a passive utility service. Organisaties typically encounter resolver risk only after a service account failure, suspicious DNS telemetry, or a misroute to an external endpoint, at which point resolver governance becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• What breaks when DNS resolver bugs affect an identity-aware proxy?
• Recursive resolver
• Resolver Integrity
• Resolver Cache