Zero Trust for Federal DNS-over-HTTPS and DNS-over-TLS Enforcement: Architecture, Policy, and Operational Tradeoffs

Encrypted DNS protocols have quietly become one of the more consequential enforcement gaps in federal Zero Trust programs. DNS-over-HTTPS and DNS-over-TLS were designed to protect end users from eavesdropping and tampering on public networks, and they accomplish that goal. The problem for federal security teams is that the same encryption that prevents interception by a hostile third party also prevents inspection by the agency’s own monitoring infrastructure. When a workstation resolves names through an external DoH provider over port 443, the traffic is indistinguishable from normal HTTPS. The query never touches the agency resolver. The SOC never sees it.

This is not a theoretical risk. Browsers, operating systems, and applications have progressively enabled encrypted DNS by default, often without explicit configuration by the endpoint owner. A user on a government-managed laptop running a modern browser may be bypassing the agency resolver entirely, not through any malicious intent, but because the browser’s default settings prefer a hardcoded DoH provider. That single behavior breaks DNS-based policy enforcement, logging, content filtering, and exfiltration detection simultaneously.

Federal Zero Trust architectures depend on DNS telemetry. Resolver logs feed threat detection, support incident response, and provide the query-level visibility that network-based controls rely on when application-layer inspection is unavailable. Losing that telemetry because encrypted DNS bypassed the enterprise resolver is not a minor gap. It is a structural hole in the monitoring fabric that Zero Trust is supposed to close.

The answer is not to block all encrypted DNS. Agencies that operate mobile workforces, remote access programs, or mission systems with privacy requirements may have legitimate reasons to use DoH or DoT. The question is whether the agency controls which resolvers are used, under what conditions, and with what logging. That is a policy and architecture problem, not just a firewall rule.

This article addresses the specific decision points federal security and network teams face when governing encrypted DNS within a Zero Trust program: where to enforce, how to detect unauthorized usage, how to design agency-managed encrypted resolvers, how to handle exceptions, and what the operational tradeoffs look like across different enforcement models.

Why Encrypted DNS Creates Enforcement Gaps in Federal Environments

Traditional DNS operates over UDP or TCP on port 53. It is unencrypted, which means it is visible to every network device between the client and the resolver. That visibility has historically been a security asset. Agencies use resolver logs to detect malware callbacks, identify data exfiltration attempts, enforce content policy, and support forensic investigations. DNS is one of the highest-signal telemetry sources available to a network security team because nearly every application, protocol, and service generates DNS queries.

DoH wraps DNS queries inside HTTPS and sends them to a resolver over port 443. DoT wraps queries in TLS and sends them over port 853. Both protocols were designed to prevent ISPs, coffee shop operators, and hostile network actors from reading or manipulating DNS traffic. They achieve that goal. They also achieve something federal agencies did not ask for: they make DNS traffic opaque to enterprise monitoring tools that rely on plaintext query inspection.

The enforcement gap is not just about encryption. It is about destination. When a browser uses DoH with a hardcoded external provider, the query goes to that provider’s infrastructure, not the agency resolver. The agency’s DNS-based policy controls, including domain blocklists, category filtering, and split-horizon namespace resolution, do not apply. The resolver the agency spent budget and effort configuring is bypassed entirely.

This matters in a Zero Trust context because DNS is a foundational control plane. Zero Trust architectures assume that every access decision is informed by current context, including network behavior. DNS telemetry contributes to that context. When encrypted DNS removes that telemetry, the Zero Trust policy engine operates with less information. Anomaly detection degrades. Exfiltration via DNS tunneling becomes harder to detect. Incident response loses a critical data source.

The distinction between transport-layer encryption and namespace authorization is important here. Split-horizon DNS and namespace authorization control which names resolve to which addresses based on the requester’s identity and location. Those are namespace policy decisions. Encrypted DNS transport policy controls how queries travel between the client and the resolver. Both matter, but they are separate problems with separate enforcement mechanisms. Conflating them leads to incomplete architectures that address one without the other.

Resolver Architecture Decisions: Agency-Managed vs. External Encrypted DNS

The core architectural question for federal agencies is not whether to allow encrypted DNS. It is whether the agency controls the resolver. An agency-managed DoH or DoT resolver provides transport security for DNS queries while keeping query logs, policy enforcement, and namespace control inside the agency boundary. An external DoH provider provides transport security while removing all of those controls.

Agencies that want to preserve visibility while offering encrypted DNS transport should deploy an internal recursive resolver that supports DoH and DoT endpoints. Clients are configured to use those endpoints rather than external providers. The resolver enforces agency DNS policy, logs all queries in a structured format, and forwards to upstream resolvers through agency-controlled paths. The transport between client and resolver is encrypted. The resolver itself remains under agency control.

This architecture requires the resolver to present a valid TLS certificate for the DoH or DoT endpoint. That certificate must be trusted by the clients. In a managed endpoint environment, distributing a certificate through the enterprise PKI is straightforward. In environments with unmanaged or personally owned devices, certificate trust becomes a more complex problem that may require a different enforcement approach.

Resolver centralization is a related decision. Agencies with multiple enclaves, remote sites, or cloud environments need to decide whether to operate a single centralized resolver infrastructure or deploy resolver instances closer to the workload. Centralized resolvers simplify policy management and log aggregation but introduce latency and single-point-of-failure risk. Distributed resolvers reduce latency and improve resilience but require consistent policy synchronization and more complex log collection. Neither model is universally correct. The right answer depends on the agency’s network topology, mission requirements, and operational capacity.

Endpoint and Browser Enforcement: Where Policy Must Start

Network-level controls alone cannot fully govern encrypted DNS. The reason is architectural. DoH traffic exits on port 443, the same port used for all HTTPS traffic. A firewall rule blocking port 853 will stop DoT. It will not stop DoH without also blocking all HTTPS, which is not operationally viable. Effective encrypted DNS governance requires enforcement that begins at the endpoint.

Modern browsers implement DoH independently of the operating system resolver. A workstation may be configured to use the agency resolver at the OS level, but the browser may simultaneously use a hardcoded DoH provider for all DNS queries it initiates. This means OS-level resolver configuration is necessary but not sufficient. Browser policy must be managed separately.

Enterprise browser management policies allow administrators to disable DoH entirely, force a specific DoH endpoint, or configure the browser to use the OS resolver. The specific policy mechanism varies by browser. Chromium-based browsers, Firefox, and Safari each have different policy controls and different default behaviors. Agencies managing a heterogeneous browser environment need to account for each browser’s policy model in their endpoint configuration baseline.

Mobile device management adds another layer. Mobile operating systems on government-managed devices may support encrypted DNS configuration through MDM profiles. Those profiles can specify an approved DoH or DoT resolver and prevent user modification. Unmanaged personally owned devices used for remote access present a harder problem. If the agency cannot push endpoint policy to the device, network-level enforcement and proxy controls become the primary mechanisms.

Detecting Unauthorized Encrypted DNS at the Endpoint

Endpoint detection and response tooling can identify processes making outbound connections to known DoH provider IP addresses or to port 853 destinations that are not the agency resolver. This detection is imperfect because DoH providers share IP space with other HTTPS services, but it provides a signal that can be correlated with other behavioral indicators. Endpoint telemetry is more reliable than network telemetry alone for identifying applications that have implemented their own encrypted DNS stack outside the OS resolver.

Proxy, Firewall, and Inspection Controls for Encrypted DNS

Network enforcement for encrypted DNS operates at two levels. The first is blocking unauthorized encrypted DNS destinations. The second is inspecting or redirecting encrypted DNS traffic that does reach the network perimeter.

Blocking DoT is straightforward. Port 853 is used almost exclusively for DNS-over-TLS. A firewall rule denying outbound traffic on port 853 to destinations other than the agency resolver stops unauthorized DoT with minimal operational impact. Agencies should also block inbound DoT on port 853 unless there is a specific operational requirement for external clients to query agency resolvers directly.

Blocking unauthorized DoH is harder. The approach most commonly used is maintaining a blocklist of known DoH provider IP addresses and domains and denying outbound HTTPS connections to those destinations. This requires ongoing maintenance as providers add infrastructure. It also creates a cat-and-mouse dynamic where determined users or applications can find DoH endpoints not yet on the blocklist. The blocklist approach is a useful layer but should not be treated as a complete solution.

TLS inspection at the proxy layer can intercept DoH traffic and expose the DNS queries for policy enforcement and logging. This requires the proxy to present a certificate trusted by the client, which in turn requires the agency’s inspection CA to be installed in the client’s trust store. For managed endpoints, this is a standard enterprise configuration. The operational tradeoff is that TLS inspection introduces latency, increases proxy processing load, and creates certificate management dependencies. It also raises questions about what happens when the proxy is unavailable. If the proxy is the only path for DoH traffic and it fails, DNS resolution may fail for clients that have been configured to use DoH exclusively.

Exception Handling for Mission and Legacy Systems

Not every system in a federal environment can be reconfigured to use an agency-managed encrypted resolver. Mission systems, embedded devices, operational technology, and legacy applications may have hardcoded DNS configurations that cannot be changed without vendor involvement, requalification, or significant operational risk. Blanket enforcement of encrypted DNS policy without an exception workflow creates a situation where security teams either break mission-critical systems or create informal workarounds that are never documented.

Exception workflows should require the system owner to document the system’s DNS behavior, the reason the standard policy cannot be applied, the compensating controls in place, and the plan for eventual remediation. Exceptions should be time-bounded and reviewed on a regular cycle. Systems that cannot meet the standard should be isolated where possible so their non-compliant DNS behavior does not create a pathway for other systems to bypass controls.

Logging, Telemetry, and SOC Integration

An agency-managed encrypted resolver restores DNS visibility, but only if the resolver is configured to produce logs that the SOC can actually use. This sounds obvious, but it is a common gap. Resolver software that supports DoH or DoT may log queries in a format that differs from the plaintext resolver logs the SIEM was configured to parse. If the log format changes and the SIEM parsing rules are not updated, the queries are collected but not indexed. The SOC loses visibility not because the resolver stopped logging, but because the pipeline was not validated end to end.

DNS logs should capture the source IP, the queried name, the query type, the response code, the response data, the timestamp, and the resolver that handled the query. For encrypted DNS, the log should also capture whether the query arrived via DoH or DoT, which matters for policy enforcement reporting and anomaly detection. Logs should be forwarded to the SIEM in near-real time. Batch collection introduces detection latency that matters when DNS is being used for command-and-control or exfiltration.

Detection logic for unauthorized encrypted DNS should look for outbound connections to known DoH provider infrastructure, outbound port 853 traffic to non-agency destinations, and DNS query volumes that are inconsistent with normal baseline behavior. The last indicator is relevant for DNS tunneling detection regardless of whether the tunnel uses plaintext or encrypted DNS. High query rates, unusually long domain names, and high entropy in query strings are behavioral signals that apply across transport protocols.

SOC teams should understand the difference between a client that is using an unauthorized external DoH provider and a client that is using the agency DoH resolver correctly. Both generate HTTPS traffic to port 443. The distinction is the destination. SOC runbooks should include procedures for investigating DoH-related alerts that account for this distinction and avoid treating all DoH traffic as malicious.

Common Mistakes

The most common mistake is treating encrypted DNS as a network perimeter problem when it is primarily an endpoint policy problem. Teams that focus on firewall rules and IP blocklists without addressing browser and application-level DoH defaults will find that their network controls are incomplete. A managed endpoint with an unmanaged browser can bypass every network-level control while appearing fully compliant at the perimeter.

A related mistake is deploying an agency-managed DoH or DoT resolver without validating the logging pipeline. The resolver may be operational and correctly handling queries, but if the logs are not reaching the SIEM in a parseable format, the visibility benefit of the agency-managed resolver is not realized. This is a configuration and integration problem that is easy to miss during deployment and easy to overlook during routine operations until an incident exposes the gap.

Agencies sometimes block port 853 and declare DoT resolved without addressing DoH. The two protocols require different enforcement mechanisms. Blocking one without addressing the other leaves a significant gap. The gap is particularly consequential because DoH is the protocol that browsers prefer by default, making it the more common source of unauthorized encrypted DNS in managed endpoint environments.

Exception management is frequently informal. Systems that cannot comply with encrypted DNS policy are granted verbal exceptions or simply left out of scope without documentation. When those systems are later assessed, the undocumented exceptions create findings that could have been avoided with a formal exception process. More importantly, undocumented exceptions cannot be tracked for remediation, so they tend to persist indefinitely.

Capacity planning for TLS inspection is consistently underestimated when DNS query volume is not factored in. Proxy infrastructure sized for web traffic may not handle the connection rate generated by DNS queries at enterprise scale. Teams that discover this problem after deployment face a choice between accepting degraded performance and procuring additional capacity outside the original acquisition plan.

Finally, agencies sometimes conflate encrypted DNS enforcement with broader DNS security. DNSSEC, split-horizon resolution, and namespace authorization are separate capabilities. Implementing DoH/DoT controls does not provide DNSSEC validation, and DNSSEC does not address the visibility and policy enforcement problems created by unauthorized encrypted DNS. These are complementary but distinct controls that require separate planning.

Recommended Federal Approach

Start with a current-state assessment that answers three questions: What DNS resolvers are endpoints actually using? Are any endpoints generating DoH or DoT traffic to external providers? Does the agency operate a resolver that supports encrypted DNS transport? Network flow data, endpoint telemetry, and proxy logs can answer these questions without requiring a full architecture review. The assessment should cover managed endpoints, mobile devices, remote access clients, and any cloud workloads that generate DNS queries.

Based on the assessment, define the target state. For most federal environments, the target state is an agency-managed resolver that supports DoH and DoT, with all managed endpoints configured to use it, external encrypted DNS destinations blocked or intercepted, and resolver logs feeding the SIEM. The target state should be documented as a policy position, not just a technical configuration, so that it can be referenced during RMF assessments and system authorization activities.

Deploy or upgrade the agency resolver to support DoH and DoT before pushing endpoint policy changes. Changing endpoint DNS configuration before the resolver is ready creates a window where endpoints have no functional resolver. The resolver should be validated for performance, redundancy, and log output before it is designated as the production endpoint for encrypted DNS.

Push endpoint policy in phases. Start with a pilot group that includes a representative sample of endpoint types, browsers, and applications. Validate that the policy correctly disables unauthorized DoH, redirects queries to the agency resolver, and does not break application functionality. Pay particular attention to applications that implement their own DNS stack, including some collaboration tools, VPN clients, and security agents. These applications may require individual configuration or exception handling.

Implement network enforcement in parallel. Block outbound port 853 to non-agency destinations. Build and maintain a blocklist of known DoH provider infrastructure. Configure TLS inspection for DoH traffic if the proxy infrastructure supports it and has been sized appropriately. Document the enforcement architecture so that future changes to network topology or proxy infrastructure account for encrypted DNS controls.

Establish a formal exception process before enforcement goes into production. The process should include a standard request form, a review workflow that includes the ISSO or ISSM, a compensating controls requirement, and a defined review cycle. Systems granted exceptions should be tracked in the configuration management system, not managed through informal agreements.

Validate the full telemetry pipeline from resolver to SIEM before declaring the implementation complete. Run test queries through the DoH and DoT endpoints and confirm that the resulting log entries appear in the SIEM with correct field mapping. Activate detection rules for unauthorized encrypted DNS and confirm that they fire correctly against test traffic. Brief the SOC on the new resolver architecture, the expected traffic patterns, and the runbooks for encrypted DNS-related alerts.

Sustainment planning should address certificate lifecycle management for the resolver’s TLS certificate, resolver software updates, blocklist maintenance, and periodic review of exception status. Encrypted DNS enforcement is not a one-time configuration. It requires ongoing operational attention to remain effective as browsers update their defaults, new DoH providers emerge, and the agency’s endpoint population changes.