A way to send DNS lookups inside encrypted HTTPS requests instead of standard DNS traffic. It improves privacy in normal use, but it also gives malware a way to hide command resolution and domain lookups from defenders who only inspect classic DNS logs.
Expanded Definition
DNS over HTTPS, or DoH, is a transport method for DNS queries that wraps name resolution inside standard HTTPS traffic. In NHI environments, that matters because service accounts, agents, and automation pipelines often resolve APIs, callback domains, package hosts, and identity endpoints continuously. DoH can reduce passive interception and make DNS traffic harder to profile, but the same property also reduces the visibility defenders rely on for domain-based detection.
Definitions vary across vendors on whether DoH is a privacy control, an evasion channel, or both. From an NHI governance perspective, the practical question is not whether DoH is allowed in theory, but whether it is approved, logged, and bounded by policy. NIST guidance on detection and response emphasizes monitoring that preserves investigative value, and the NIST Cybersecurity Framework 2.0 reinforces the need for visibility and anomaly handling across network activity. The most common misapplication is allowing unmanaged DoH use by agents and workloads, which occurs when teams whitelist encrypted web traffic without separately governing resolver destinations or telemetry retention.
Examples and Use Cases
Implementing DoH rigorously often introduces a visibility tradeoff, requiring organisations to weigh user privacy and transport encryption against the loss of straightforward DNS logging and filtering.
- An agent running in CI/CD resolves package repositories through a corporate-approved DoH resolver so lookups remain encrypted while still being attributable.
- A security team blocks arbitrary DoH endpoints but allows a small list of sanctioned resolvers, reducing the chance that malware can hide command resolution.
- A cloud workload uses DoH to protect DNS queries across shared networks, while the organization preserves flow logs and resolver audit trails for incident review.
- A defender investigates suspicious outbound HTTPS sessions that mask repeated lookups to newly registered domains, a pattern often associated with covert C2 behavior.
- An NHI governance team references the Ultimate Guide to NHIs when defining which service accounts may use encrypted resolution and which must remain on monitored resolvers.
Operationally, DoH is best treated as a controlled network capability, not a default right for every workload. It should be paired with resolver allowlists, endpoint policy, and detective controls that can distinguish legitimate encrypted lookup behavior from concealment. The broader Ultimate Guide to NHIs is useful here because DNS control is only one part of managing service-account visibility, rotation, and offboarding.
Why It Matters in NHI Security
DoH becomes an NHI issue when defenders lose sight of how machine identities discover dependencies and external services. That loss of visibility can hide credential exfiltration, command-and-control lookups, and policy violations inside ordinary encrypted web traffic. Because NHI abuse often starts with quiet reconnaissance rather than obvious authentication failure, encrypted DNS can delay detection long enough for an attacker to move from foothold to persistence.
NHI Mgmt Group notes that only 5.7% of organisations have full visibility into their service accounts, and that gap is especially dangerous when name resolution is opaque. If a compromised agent can reach arbitrary resolvers, the organisation may not notice until unusual outbound patterns or downstream service abuse appear. This is why DNS policy must sit alongside identity governance, not outside it. The most important point is that DNS over HTTPS is rarely investigated first in a healthy environment; organisations typically encounter it as a complicating factor only after suspicious agent behavior, at which point it becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Encrypted DNS can obscure NHI command resolution and domain control paths. |
| NIST CSF 2.0 | DE.CM-1 | DoH affects monitoring of network activity and detection of suspicious resolution patterns. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero Trust requires controlled egress paths, including name-resolution channels. |
| NIST AI RMF | AI systems and agents need traceable network behavior to manage operational risk. | |
| OWASP Agentic AI Top 10 | A3 | Agentic systems can misuse encrypted channels to hide tool access and outbound discovery. |
Preserve DNS visibility through approved resolvers and correlate HTTPS traffic with workload identity.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
