DoH setup: where DNS queries go out in cleartext
Name resolution is the most inconspicuous leak channel in a corporate network. By default, a workstation sends a query in cleartext to port 53 — it leaves the perimeter before a secure session with a site is established.
Inside an encrypted connection, an observer sees only the domain, while cleartext DNS traffic gives away the entire list of names the employee accessed.
What exactly goes to an observer on the channel: the ISP, a transit operator, an access point in a coworking space or hotel. From the sequence of queries, an infrastructure map is reconstructed — internal services, monitoring systems, file storage, contractor services.
The time and frequency of queries reveal work schedules, distribution across departments, and moments of project activity.
A separate class is interception of name resolution responses. An observer manages to spoof the resolution response before the legitimate one, and the resolver puts the forged record into the cache. Then the employee lands on a copy of the login page or on an empty response.
Zone signing (DNSSEC) covers part of the cases, but does not work where the zone does not publish it.
DoH setup starts not with the client, but with outbound traffic policy. Port 53 is closed for everyone except internal resolvers, and workstations and servers go outward only through a fixed set of DoH and DoT addresses.
Then the DNS query leak is closed, responses come only from a trusted resolver, and the channel itself becomes manageable and observable. We'll break down how this is deployed in practice.
What DNS encryption provides: privacy, control, resilience
Without encryption, every name resolution query goes out in cleartext: an intermediary on the route sees both the name itself and the source address, and from the sequence of queries reconstructs the behavior of the device and its owner.
DoH packages the query into a regular secure web session, DoT — into a dedicated channel on a separate port, and for an external observer only the resolver address and traffic volume remain. Privacy of name resolution stops being a declaration and becomes a property of the transport.
The second effect is the share of spoofed responses. An intercepted query is cheap to return from a fake address, and before encryption appeared this happened unnoticed by the client.
Transport encryption combined with signature verification on the resolver removes this class of attacks entirely: the query cannot be read and spoofed en route, and a response without a valid signature is discarded.
Attempts at interference remain in the resolver logs, and the share of responses that fail verification drops to zero.
Control over outbound queries emerges as a side effect, but the most practical result. As long as a client can contact any public resolver — for example, Cloudflare — corporate filtering is bypassed with a single switch in the network settings on the device.
A perimeter rule closes this: direct DNS to the outside is prohibited, only corporate DoH/DoT endpoints are allowed, and then all names are visible in a single log, and policies are applied centrally, rather than on the principle of “whatever each person has configured.”
Resilience of the name channel is the third measurable effect. Changing the resolver stops being an edit on every device: it is a change to the endpoint address in the configuration that propagates across fleets in one update cycle.
Persistent sessions and cache on the client and on the resolver keep resolution latency at the same level, and switching between several endpoints when one fails happens without user involvement.
The result is measured by three indicators: name visibility to an external observer, the share of spoofed responses, and the share of queries that passed corporate policies.
Comparison of modes: DoH, DoT, local resolver, and hybrid
The choice of mode is determined not by the level of “security,” but by which channels are available to clients, where internal zones live, and how quickly it is necessary to return to a working state after a failure.
In one enterprise, all four schemes usually coexist: the office fleet, remote employees, guest access, and internal service records behave differently, and a single policy for everyone breaks at the first limitation.
Below is a working matrix: option, applicability conditions, and what it constrains in terms of maintenance.
| Mode | When it fits | Limitations |
|---|---|---|
| Encryption over the web protocol | Public and guest networks where only regular web traffic is allowed; browsers and mobile devices | Traffic is indistinguishable from regular traffic, so perimeter filtering and inspection are configured separately; some applications ignore system settings |
| Dedicated encrypted name channel | Managed fleet where a predictable channel and a clear failure point are needed | A separate port is easily blocked in partner and guest networks; open outbound access is required |
| Local resolver | Internal zones, service records, latency-sensitive queries; when a single node goes outward | The “client — resolver” segment remains open; fault tolerance and scaling fall on the infrastructure |
| Hybrid scheme | Mixed fleet: office, remote employees, guests, individual applications with their own settings | Two policies and two monitoring contours; the rollback procedure has to be described in advance, otherwise configuration drift accumulates |
Practical conclusion: the default mode is fixed for the majority of clients, while the remaining schemes are enabled selectively — for specific zones or device groups.
Before switching, we check compatibility with current filters, internal zones, and the scenario for returning to previous settings, so that a failure of a single node does not leave the fleet without name resolution.
DoH setup: implementation stages in a corporate network
The order of work here is set not by ease of configuration, but by the fact that encryption moves the point where query contents are visible.
If DoH is enabled on clients first, the network loses visibility of name resolution, and filtering and logs stop reconciling with each other. Therefore the stages go from inventory to handover to operations, and each has its own readiness criterion.
- Audit of the resolution scheme. We collect a list of resolvers, local zones, static records in configurations, and applications that already use encrypted queries bypassing the corporate path. The result is a query map indicating the initiator and which segment contacts where.
- Scheme design. We determine where a single egress point remains and where the backup path goes. For managed devices, DoT is usually suitable; for roaming, DoH over the standard secure port, which almost all guest networks allow.
- Configuring the encrypted channel. Profiles on resolvers and clients, trusted certificates, server name verification, disabling the unencrypted fallback query, or an explicit rule for when it is allowed.
- Closing bypasses. We block third-party encrypted endpoints at the perimeter — otherwise the filtering policy is bypassed by changing one setting in the browser.
- Post-implementation verification. Name resolution in all segments, added latency, behavior when the resolver is unavailable, completeness of logs, and event correlation.
- Handover to operations. Certificate renewal procedure, notifications, instructions for rolling back to the previous scheme, and training for the on-call shift.
Configurations, schemes, and procedures: what remains in your hands
The point of handover is that a day after completion of work, the scheme can be changed without us.
Therefore the package includes not only configured nodes, but also everything that describes their behavior: configuration files in the repository, topology, rules, and the procedure for approving changes. Below is a list of artifacts that remain with your team.
- Node configurations — working profiles of resolvers and DoH/DoT gateways, templates for different sites, cache parameters, and certificate issuance rules with automatic renewal.
- Network diagram — topology with interception and query egress points, listener addressing, routes to upstream resolvers, and the degradation procedure when one of them fails.
- Change procedure — who edits the configuration and how, mandatory run of checks, maintenance windows, procedure for returning to the previous revision, and criteria for a successful change.
- Access policies — which teams and services contact the nodes, by what attributes internal and external clients are distinguished, and how credentials are issued and revoked.
- Infrastructure documentation — description of components, dependencies, and failure points; instructions for typical operations: adding a site, changing a certificate, decommissioning a node.
- Monitoring and alerts — metrics for response latency, failure rate, and cache hits, trigger thresholds, and a list of signals requiring on-call intervention.
- Staged rollback procedure — how to return clients to the previous name resolution method within minutes, without losing availability and without distributing a corrupted cache.
Case study: migrating an office network to encrypted DNS
What was in place before the project
Name queries from the office network went outward in cleartext: they were read by any node on the path, and the response could be spoofed unnoticed.
Over a quarter, several confirmed cases were recorded — employees landed on fake authorization pages, and investigating each incident took hours: first to prove the spoofing itself, then to find the affected segments.
The share of unencrypted queries was 100%, and recovery after a name resolution failure took up to several hours with the on-call shift.
What was changed
Encryption was deployed in two layers: on workstations — via system policies and browser settings, on departmental resolvers — at the transport level. Cloudflare was made the primary, the backup resolver independent, with automatic switching when the primary is unavailable.
Rollout proceeded in stages: a pilot segment, a week of observing metrics, then the remaining offices — so a failure in one area did not become a general one.
Result
The share of cleartext queries fell from 100% to 2-3% — devices without encryption support remained, moved to a separate segment with limited access.
There have been no confirmed incidents with response spoofing after the migration, and an unencrypted query is now automatically considered a reason for investigation, not background noise.
Recovery time when the primary node fails was reduced from several hours to minutes: switching occurs without on-call involvement, and old records continue to be served from the local cache until the backup resolver comes into operation.
How DoH differs from DoT and when one is enough
The difference is not in the strength of encryption, but in how traffic looks to someone watching the perimeter.
DoH packages queries inside a regular secure web session, so externally they are indistinguishable from page loading — they are hard to block selectively, but equally hard to account for in rules.
DoT goes over a separate secure channel on its own port: traffic is visible as a separate service, but it is predictably allowed, restricted by addresses, and appears in logs as an independent flow. Hence the practical rule for choosing an encryption mode — by scenario, not by “better/worse.”
On workstations, what matters is not the protocol, but who controls the setting. Modern browsers can enable DoH themselves, and then queries bypass the corporate resolver: internal names stop resolving, and the picture of requests falls apart.
The working scheme is to disable the built-in mode by policy and direct machines to your own node, which already encrypts traffic outward.
In the server segment, DoT is usually sufficient. Connections there are long-lived, the load is predictable, and it is important for the administrator to see which node contacts where: a separate channel is easier to bind to the internal resolver and close at the perimeter.
DoH here is justified if the service goes outward through a reverse proxy and you do not want to open an extra port.
Mobile devices and guest networks give the opposite picture.
Phones and laptops support both modes through standard profiles, but when moving between networks the secure session is re-established, and DoT endures this harder — pauses are noticeable on the first query after switching.
In guest networks, DoH is more logical: it does not require publishing a separate port outward, and guest traffic remains in the common web flow.
In practice it almost always ends up a hybrid: DoT inside the perimeter, DoH for browsers and guest segments, and an explicit policy prohibiting clients from choosing a resolver on their own.
Compatibility, rollback, and verification: technical concerns
Before enabling encryption across the entire fleet, technical teams check three things: how it coexists with filtering, what happens during rollback, and how to make sure traffic is actually encrypted. Below are answers to the concerns that most often come up during approval.
Will DoH break existing traffic filtering?
No, as long as the policy remains on the internal resolver: the client encrypts only the segment up to it, and categories and blacklists work as before.
The scheme breaks where applications bypass the corporate resolver and go to an external one — such cases we close with perimeter rules.
What to do with internal zones?
Internal names must resolve only through the corporate resolver, otherwise some services will simply stop opening. We check this with a separate set of tests before rolling out to everyone.
How are changes rolled back?
The rollback procedure is fixed in advance: client profiles return to the previous resolver addresses, perimeter rules are removed, and the configuration rolls back to the previous version. We rehearse the same scenario on the pilot group.
Can partial encryption be enabled?
Yes, rollout proceeds by device groups and sites — we start with the department where feedback is easier to collect. If problems arise, the group returns to the previous mode, while the rest continue to work.
How to verify that encryption actually works?
We look at outbound traffic: unencrypted queries outward should disappear, and responses should come from the corporate resolver. Additionally, we cross-check resolver logs and test domains.
Let's discuss the task: what data is needed for an assessment and plan
So that an estimate and work plan appear after one conversation, rather than three iterations of clarification, we need a snapshot of the infrastructure.
The more accurate the initial data, the fewer assumptions in the project and the more predictable the timeline for rolling out query encryption.
- List of segments and sites: offices, branches, employee remote connections, guest networks, server rooms — for each, it is important to understand who goes online and how.
- Current resolution scheme: which resolvers are used internally, where client devices send requests, whether there are local caching servers, and how they receive responses.
- Logging requirements: what needs to be recorded (source, time, domain, policy verdict), how long to store it, and who has access to exports.
- Current filtering rules: lists and categories, who maintains them, how often they change, and what must be preserved after the migration.
- Client inventory for rollout: operating systems, mobile devices, branch equipment, automated systems, and service accounts.
- Access management procedure: how rights to change network settings are issued, whether there is a separate contour, and who approves changes.
- Constraints and maintenance windows: internal security requirements, industry regulations, and periods when it is permissible to change the query route.
This set is enough for us to return with an estimate and plan: pilot segment, rollout sequence, rollback points, and metrics by which we will verify the result. If some data is unavailable, describe what you have, and we will gather the rest together.