Doh And Dot

DoH and DoT are encrypted DNS transport methods. DoH hides DNS inside regular HTTPS traffic, while DoT uses a dedicated TLS channel for queries. Both improve privacy, but each changes how defenders inspect, block, and govern resolution traffic.

Expanded Definition

DoH and DoT are encrypted DNS transport methods that protect query confidentiality in transit, but they are not equivalent in operational impact. DoH sends DNS over HTTPS, typically on port 443, which can blend into ordinary web traffic. DoT carries DNS over a dedicated TLS session, usually on port 853, making it easier to distinguish at the network layer while still hiding query content.

In NHI security, the distinction matters because service-to-service resolution often drives token retrieval, endpoint discovery, callback validation, and policy enforcement. No single standard governs how enterprises should govern encrypted DNS across agentic systems, so usage in the industry is still evolving. Organisations often evaluate these transports alongside NIST Cybersecurity Framework 2.0 and Zero Trust controls, while also considering where visibility is needed for NHI detection and incident response. The most common misapplication is assuming encrypted DNS is automatically safer, which occurs when teams enable DoH or DoT without updating inspection, logging, and allow-listing policies.

Examples and Use Cases

Implementing DoH or DoT rigorously often introduces a visibility tradeoff, requiring organisations to weigh privacy gains against the cost of reduced inspection and more complex policy enforcement.

• An AI agent resolves SaaS API endpoints over DoH to reduce passive DNS leakage, but the security team must preserve logging at the resolver boundary.
• A privileged automation host uses DoT for internal name resolution so query contents remain confidential while the network team still distinguishes DNS from web traffic.
• A defender studies the patterns described in the Schneider Electric credentials breach to understand how resolution paths can support lateral movement and infrastructure discovery.
• A SOC team allows only approved resolvers for service accounts while blocking unmanaged encrypted DNS that could bypass egress policy.
• An engineering group compares DoH behavior with guidance from the NIST Cybersecurity Framework 2.0 to align availability, monitoring, and access control requirements.

These use cases show that encrypted DNS is a governance decision, not just a transport preference. The right design depends on whether the organisation needs strong privacy, strict inspection, or both.

Why It Matters in NHI Security

Encrypted DNS affects how defenders observe the first step in many NHI workflows: name resolution. When DoH and DoT are unmanaged, service accounts, API clients, and agents can reach malicious infrastructure without triggering the same controls applied to plain DNS. That creates blind spots for exfiltration, command-and-control, and policy evasion. The risk is not theoretical: NHI Mgmt Group reports that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, and 79% of organisations have experienced secrets leaks, with 77% of those incidents causing tangible damage, according to Ultimate Guide to NHIs.

For NHI governance, the practical question is whether encrypted DNS is approved, monitored, and constrained by identity-aware policy. Teams should know which resolvers agents may use, what telemetry remains available, and how to respond when a workload unexpectedly switches transports. Organisations typically encounter the operational cost of DoH and DoT only after a suspicious lookup or breach investigation, at which point the term becomes operationally unavoidable to address.