DoH / DoT

Reading time: 11 minute Word count: 2136

Network DNS DoH DoT

The same domain can produce different answers in a browser and on the command line. A local DNS server that was configured correctly in the company network may suddenly stop behaving the way it used to after a system update. You may still be looking up standard A, AAAA, or MX records, but packet capture no longer shows the familiar UDP 53 traffic. DoH and DoT are not simply “encrypted DNS”. They change the path DNS takes after it leaves the client, who can see it, and who can control it.

DoH and DoT do not change DNS resolution semantics. They change how DNS queries leave the client, how they cross the network, and what the trust boundary and control point on that path look like

Boundary

DNS defines the resolution semantics from names to data records
DoT defines how standard DNS queries run over a TLS connection
DoH defines how standard DNS queries travel through HTTPS
DNSSEC defines whether DNS data can be validated as unmodified and authentic
HTTPDNS is an application-control model in which the application decides who to ask and what result to accept

DoH and DoT still carry standard DNS semantics. They do not replace the authority system, delegation relationships, record types, or caching model with something else. example.com is still the same namespace, and the recursive resolver is still asking the root, the TLD, and the authoritative server. The change is only in the hop between the client and the recursive resolver.

Why the Classic DNS Path Becomes a Problem

The classic DNS path looks like this:

App -> Stub Resolver -> Recursive Resolver -> Authoritative Servers

On the hop from client to recursive resolver, classic DNS has long relied mainly on UDP 53, with TCP 53 as the fallback when needed. That was a reasonable design in the early Internet:

Requests and responses were usually small
No connection had to be established first
Resolvers could handle high query concurrency
Most queries cared more about very low overhead than about strong privacy

But today that path has some obvious problems.

Query contents are too easy to see

When classic DNS is sent in clear text, the middle of the network can very easily see which domain the user is asking for. Even if the actual business traffic later runs over HTTPS, the DNS lookup still exposes the access intent first.

Query results are too easy to interfere with

As long as someone on the path can see and forge these clear-text queries, there is room for pollution, hijacking, policy inspection, or enterprise filtering. Those actions are not always malicious, but the premise is the same: the middle of the network can easily read and manipulate that DNS hop.

Local policy and system policy have become much more complex

Modern endpoints are no longer in a simple world where “the NIC gets one DNS server address and the whole system uses it”. Browsers, mobile systems, enterprise proxies, VPNs, parental controls, and security products may all want to take over the resolution path. The old default DNS behavior is not always enough to express that complexity.

What They Actually Change

DoT and DoH have a shared goal: put the client-to-recursive-resolver hop into a protected transport.

The DoT main path can be simplified as:

App / OS
  -> TLS connection to resolver:853
  -> standard DNS query / response

The DoH main path is:

App / Browser
  -> HTTPS request to resolver
  -> DNS message in HTTP payload
  -> HTTPS response carrying DNS answer

Compared with classic DNS, two things matter.

First, the question being asked is still a standard DNS question. The client is still asking for A, AAAA, MX, TXT, and similar records, and the response still has standard DNS semantics. It is not a business-defined custom address policy.

Second, only one hop is protected. Protecting the transport between the client and the recursive resolver does not automatically make the resolver-to-authoritative path safe, and it does not mean the data itself has DNSSEC-style source verification.

Why DoT and DoH Split into Two Paths

If the goal is simply “stop DNS from going out in clear text”, one solution might sound enough. In reality, the space split into DoT and DoH because they make different engineering tradeoffs.

DoT: put a secure transport around DNS

DoT simply moves DNS from clear text 53 to a dedicated TLS channel for DNS.

The advantages are:

The layering is clean. It is still evolution along the DNS protocol line
Resolver implementation and operations feel natural. Logs, policies, and debugging objects are still DNS services
Compared with DoH, it relies less on extra HTTP-layer semantics

The tradeoff is also clear:

The port is obvious. The default is 853
The network can more easily tell that encrypted DNS is running here
If policy explicitly blocks or interferes with DoT, the path is not hidden

So DoT is a cleaner, more standard secure channel that still stays close to DNS’s own layering.

DoH: carry DNS inside the HTTP ecosystem

DoH takes a different approach. Since modern networks already accept HTTPS widely, DNS queries can be placed inside HTTP requests and sent through the existing web transport ecosystem.

This is not only “also encrypted”. It inherits practical advantages from HTTP:

It is easier to pass through environments that only allow web traffic
It is easier to reuse existing HTTPS proxies, connection pools, and infrastructure
Browsers and applications can control the resolution target more granularly

The tradeoff is not small:

DNS resolution gets more deeply entangled with the application layer and browser layer
The relationship with system DNS, enterprise proxies, and local policy becomes more complicated
During debugging, you are no longer just looking at a DNS service; you are looking at DNS requests inside an HTTP stack

So DoH places DNS queries into the web transport environment that is easiest to deploy today.

How a Single Query Behaves Differently

From the angle of “it eventually returns an IP address”, DoH, DoT, and classic DNS can look similar. The important differences show up much earlier, in the query path.

Classic DNS

Stub -> UDP/TCP 53 -> Recursive Resolver

The middle of the network can easily tell that this is a DNS query, and it can also process it based on the port and packet contents.

DoT

Stub / OS -> TLS:853 -> Recursive Resolver

The middle of the network can see that you are connecting to some resolver, but it cannot see the query contents themselves. It can still usually identify the connection as DoT.

DoH

Browser / App -> HTTPS:443 -> Resolver endpoint

The middle of the network generally cannot tell just from the port that this must be DNS. What it sees looks more like normal HTTPS traffic, although deeper policy systems may still identify it by hostname, certificate, IP, or traffic shape.

Both can protect query contents, but they do not affect how easy it is for the middle of the network to apply policy in the same way.

What They Protect, and What They Do Not

This is where people most often get the boundary wrong. DoH and DoT do not put a generic “security” label on DNS. They protect one specific segment and leave the rest unchanged.

They protect the hop from the client to the resolver

On that path, the middle of the network has a much harder time seeing:

Which domain the user is querying
Which records were returned
Whether someone on the path forged a classic DNS response

That changes the difficulty of monitoring, auditing, hijacking, and pollution.

They do not automatically make the resolver trustworthy

If the client sends all queries to a third-party DoH or DoT resolver, you have not removed trust. You have moved the trust center to the operator of that resolver. Privacy does not disappear, but the trust point changes.

So the question is not just “is it encrypted?” It is also:

Who are you sending the query to
What policy does that resolver use to record and process data
Does it return neutral recursive results, or does it apply its own filtering and rewriting

They are not DNSSEC

DoH and DoT mainly protect the transport. DNSSEC mainly protects answer verifiability. The two can coexist, but they are not substitutes.

Without DNSSEC, even if the client-to-resolver hop is protected with TLS, the client still mostly trusts “the recursive resolver told me this answer”. With DNSSEC, the validation chain extends further to the authenticity of the authoritative data itself.

Why Browsers and Operating Systems Make This Complicated

In the classic model, applications mostly trust the system resolver by default. After DoH became popular, that boundary became less stable.

A browser may embed a DoH client and decide for itself which resolver to ask. An operating system may provide global DoT or DoH configuration. An enterprise network may require traffic to follow local DNS policy. Now several parties want to decide “who gets the domain query first”, and conflicts appear.

That leads to a few common symptoms:

Browser resolution and command-line resolution disagree
A VPN takes over system DNS, but the browser still uses its own DoH
An enterprise network depends on local DNS policy, but DoH bypasses that local control path

These symptoms are not protocol chaos. They are the result of multiple control points competing. DoH in particular can move “who owns DNS decisions” away from the operating system and back into the application layer.

Why They Are Not the Same as HTTPDNS

DoH is easy to mistake for the standard version of HTTPDNS. They may both send requests over HTTPS, but they aim at different things.

DoH still carries standard DNS queries and responses. Its focus is to place classic DNS inside HTTPS. HTTPDNS usually means an application-defined HTTP API where the client asks a business-controlled service for resolution results that may also carry scheduling, canarying, regional policy, and business authentication.

The difference can be summarized like this:

DoH mainly changes how DNS queries are transported
HTTPDNS mainly changes who the application asks for address decisions

They can even be layered. An HTTPDNS service can use DoH or DoT internally when talking to upstream resolvers.

How to Choose Today

When choosing, first decide what problem you are really solving. Do not start by asking which one sounds more advanced.

When DoT is the better fit

You want a clear, standard transport dedicated to DNS
You mainly control system-level or network-level resolver configuration
You do not want DNS handling to be deeply entangled with the HTTP stack

When DoH is the better fit

Your environment is more likely to allow HTTPS than a dedicated DNS transport
You need the browser or application to control its own resolution path more granularly
You want to reuse existing web connection management and infrastructure

First confirm the control point

Do you actually know which resolver is ultimately trusted
Among the system, browser, VPN, and enterprise network, who has final priority
Can you tell during troubleshooting whether the request is using system DNS, DoT, or browser-native DoH

Many production issues are not caused by the protocol itself. They come from multiple resolution control paths existing at the same time and nobody being able to say which one is active.

What to Watch in Implementation, Packet Capture, and Troubleshooting

First confirm which path the client really enabled: system DNS, DoT, browser DoH, or application-private resolution
First confirm who the resolver is, rather than only looking at which IP the domain finally resolved to
First separate transport-protection problems from answer-trust problems: the former points to DoH / DoT, while the latter often still needs DNSSEC or resolver policy
First look for policy conflicts: who overrides whom among the browser, operating system, VPN, enterprise proxy, local hosts file, and security software
First look at cache layers: browser cache, system cache, and recursive cache can all make different observation points disagree

Once these judgments are clear, DoH and DoT are no longer just abbreviations for “DNS over something”. They are about rewriting the transport method, trust boundary, and control distribution of the first DNS hop.