How should security teams govern encrypted DNS without losing visibility?

Why This Matters for Security Teams

Encrypted DNS changes the visibility model, not the underlying risk. When queries move into DoH, DoT, or other TLS-protected channels, defenders lose the simple assumption that resolver logs, network taps, or inline proxies will always reveal domain lookups. That matters because DNS still drives command-and-control, phishing, and data exfiltration paths even when payload traffic is otherwise inspected. The practical question is not whether to block encryption everywhere, but where encrypted DNS is permitted and which telemetry survives.

NHI governance research from Top 10 NHI Issues and the Ultimate Guide to NHIs — Key Challenges and Risks shows the same pattern across identity-heavy environments: visibility gaps are usually discovered after security teams have already lost control of the traffic path, not during design. The better reference point is the NIST Cybersecurity Framework 2.0, which pushes teams toward risk-based monitoring rather than blanket assumptions. In practice, many security teams encounter encrypted DNS only after unmanaged resolvers have already become the default path for endpoints, containers, or agents.

How It Works in Practice

Governance starts with resolver policy, not packet inspection. Security teams should define which environments may use encrypted DNS, which resolvers are trusted, and what evidence is required to prove the lookup path. For managed corporate fleets, that often means forcing endpoints to use approved recursive resolvers and blocking direct outbound DoH or DoT to unknown destinations. For less-controlled environments, policy may allow encrypted DNS but require compensating telemetry from resolver logs, EDR, or proxy metadata.

Current guidance suggests treating DNS as an environment-specific control plane. Internal users, branch offices, contractors, server workloads, and cloud workloads do not need the same rules. The most defensible model is to align resolver policy with the asset’s trust level and the monitoring coverage available around it. Where inspection matters, logging must be consistent enough to answer basic questions: which client queried, which resolver answered, when the query occurred, and whether the destination was newly observed. That aligns with the governance emphasis in Ultimate Guide to NHIs — Regulatory and Audit Perspectives and the lifecycle discipline in NHI Lifecycle Management Guide.

• Allow encrypted DNS only on managed assets where resolver policy is enforced.
• Prefer trusted, centrally logged resolvers over arbitrary public endpoints.
• Block or alert on unauthorized DoH and DoT to preserve a visible path.
• Correlate resolver logs with endpoint, identity, and asset context.
• Document exceptions for privacy-sensitive or regulated environments.

For reporting and baseline governance, teams can also use the NIST CSF language around detect and respond outcomes to tie DNS telemetry to measurable security objectives. These controls tend to break down when remote endpoints can bypass the enterprise network entirely because resolver enforcement and logging no longer share a common control boundary.

Common Variations and Edge Cases

Tighter DNS controls often increase operational overhead, requiring organisations to balance visibility against privacy, performance, and user experience. That tradeoff is real, especially in regulated or globally distributed environments where one resolver policy will not fit every segment. Best practice is evolving, and there is no universal standard for encrypted DNS governance yet.

One common edge case is browser-enabled DoH that bypasses enterprise resolvers even when the operating system is configured correctly. Another is containerized or agentic workloads that inherit host settings but still reach out through separate network paths. Those cases often require explicit allowlists, egress enforcement, and separate logging at the workload boundary. The NHI research in The State of Non-Human Identity Security is relevant here because it shows how visibility gaps and weak logging are persistent failure points across identity infrastructure, not isolated DNS issues.

Security teams should also distinguish between privacy-preserving encryption and ungoverned resolution. Encrypted DNS is not inherently risky, but unmanaged encrypted DNS removes context that defenders need for detection and response. Where policy cannot enforce a single resolver path, current guidance suggests compensating controls such as endpoint telemetry, sinkhole monitoring, or selective decryption at other layers. In practice, that balance usually fails first in contractor-heavy, BYOD, or cloud-native environments where resolver control is partial and exceptions accumulate faster than review cycles.

Related resources from NHI Mgmt Group

• How should security teams govern DNS migrations without losing control of delegated access?
• How should security teams govern DNS for identity-dependent applications?
• How should security teams govern DNS when it supports authentication and certificate services?
• How should security teams govern DNS when it supports identity and access flows?