Encrypted DNS in 2026: Why Your Lookups Still Announce Every Site You Visit, What DoH, DoT and Encrypted Client Hello Actually Hide, and How to Turn It On Without Blinding Your Network
- Equipo de Internet Pros
- September 20, 2026
- Redes y Seguridad
Este artículo está disponible solo en inglés.
Every encrypted connection on the internet begins with an unencrypted question. Before a browser can open a private session with a bank, a supplier portal or a rival website, it first has to ask the network which address that name belongs to. For most of the history of the internet that question travelled as plain text, readable and editable by every device between the laptop and the resolver. In 2026 the fix is finally switched on by default in browsers and operating systems — and plenty of businesses are discovering it the hard way, by losing visibility they assumed they had.
What a Plain DNS Lookup Gives Away
DNS carries no passwords and no documents, which is why it was ignored for so long. What it carries is names, and a stream of names is a behavioural record. Anyone sitting on the path — the café access point, the hotel gateway, the internet provider, a compromised switch — can reconstruct a surprising amount from lookups alone, without breaking a single TLS session.
What an Observer Learns From Unencrypted DNS
- Every domain a device contacts. Including the ones a user never typed: update servers, analytics endpoints, licence checks and the internal hostnames of business systems.
- Timing and frequency. When staff start work, which supplier portals get used before a deal closes, how often a backup job runs.
- Your vendor stack. Mail, payroll, CRM and remote access lookups are exactly the reconnaissance a targeted phishing campaign needs.
- An opportunity to interfere. Plain DNS over UDP is trivially forged. An injected reply arrives first, wins, and sends the connection elsewhere.
That last point matters more than the privacy argument for most companies. Eavesdropping is embarrassing. Redirection is an incident.
DNSSEC Is Not Encryption
This trips up otherwise careful teams. DNSSEC signs answers so a resolver can prove one really came from the zone owner and was not modified in transit. It does nothing to hide the question. A signed lookup is a postcard with a tamper-proof seal: nobody can alter it, everybody can read it. Encrypted transport is the envelope, and a properly configured resolver does both.
The Three Encrypted Transports
Three standards now compete for the same job, and the difference between them is mostly about which port they use and who controls the choice.
| Transport | Port and shape | Where it fits | Trade-off |
|---|---|---|---|
| DoT DNS over TLS |
TCP 853, a dedicated port | Device and network-wide resolver settings, common on Android and router firmware | Easy to identify, so easy to permit, monitor or block deliberately |
| DoH DNS over HTTPS |
TCP 443, indistinguishable from ordinary web traffic | Browsers and applications, which set their own resolver regardless of the operating system | Blends into normal HTTPS so well a network cannot separate it, which is the point and also the problem |
| DoQ DNS over QUIC |
UDP 853, built on QUIC | Mobile networks and high-latency links, and increasingly between resolvers | Newest of the three, so appliance and logging support lags |
The practical distinction is authority. DoT is usually a decision the network makes; DoH is often a decision an application makes, and it may not be the one you would have made.
The Leak Everyone Forgets: SNI
Encrypting DNS closes one channel and leaves another wide open. When a browser opens a TLS connection to a server hosting many sites, it announces which hostname it wants in a field called Server Name Indication — and historically that field is sent before encryption begins, in clear text, on the very first packet. Encrypt every lookup you like: the connection itself still says the name out loud.
Encrypted Client Hello is the repair. The server publishes a public key in a DNS record, the client uses it to encrypt the sensitive part of the handshake, and an observer sees only a generic outer name shared by everything behind that provider. There is a neat circularity here worth understanding: ECH depends on fetching that key over DNS, so ECH is only meaningful if the DNS lookup is itself encrypted. The two technologies are not alternatives. Each one is what makes the other worth deploying, and browsers now use ECH wherever a site offers it.
Why This Breaks Things on a Business Network
Almost every control that works on names rather than addresses assumes it can see DNS. When lookups move inside HTTPS to a resolver you do not run, those controls fail silently rather than loudly.
What Stops Working
- Protective DNS and content filtering. Malware blocklists, phishing domain feeds and acceptable-use policies enforced at the resolver are bypassed the moment a browser uses its own.
- Internal name resolution. Split-horizon setups serve private addresses for internal hostnames. A public resolver has never heard of them, so the intranet becomes unreachable in a way that looks like a server fault.
- Threat hunting and forensics. Resolver logs are the cheapest detection signal most networks have. Beaconing to a command and control domain is obvious in DNS and nearly invisible in a firewall log full of HTTPS to shared addresses.
- Captive portals and guest networks. Hotel and airport sign-in pages depend on intercepting a lookup, which is precisely what the new transports prevent.
The wrong reaction is to block encrypted DNS outright. Port 853 is easy to close; DoH means chasing a moving list of HTTPS endpoints that look like ordinary web traffic, and every failed attempt pushes users toward tooling you control even less.
The Approach That Actually Works
Stop treating encrypted DNS as something to prevent, and make your own resolver the most attractive option on the network.
- Run an encrypted resolver you control. On premises or a managed protective DNS service, terminate DoH and DoT yourself. You keep the logs, the filtering and the split-horizon answers, and the wire stays encrypted.
- Push it by policy, not by hope. Windows supports DoH templates through Group Policy, Chrome and Edge accept an enterprise secure DNS policy, Firefox honours a managed configuration, and Apple devices take a DNS settings profile through mobile device management.
- Use the canary domain where interception is required. Firefox disables automatic DoH when use-application-dns.net returns NXDOMAIN. It affects only one browser, but on a guest network with a captive portal it saves support calls.
- Close the side doors. Block outbound 853 except to your own resolver and redirect plain port 53 to it, stopping the easy bypasses without an unwinnable fight against DoH.
- Keep DNSSEC validation on. Encrypted transport protects the hop to your resolver; validation protects the answer all the way from the zone.
- Test split-horizon before the rollout, not after. The first casualty of a resolver change is always an internal hostname nobody documented.
What This Means for a Smaller Business
A company with thirty staff does not need a DNS strategy document. It needs three things: one resolver that speaks an encrypted transport and filters known-bad domains, which a managed protective DNS service provides for a few dollars per user per month; that setting pushed through existing device management rather than asked of users; and a monthly glance at the resolver logs, because a workstation quietly querying a domain registered last week is the earliest warning of compromise most small networks will ever get.
The broader shift is that privacy features designed for individuals now arrive on business networks by default, switched on by a browser update nobody approved. Encrypted DNS and ECH are genuinely good for security. They are only good for your business if the resolver at the far end of the tunnel is one you chose.
If your DNS is still whatever your internet provider handed you, or you are not sure what your devices are resolving against, talk to Internet Pros. We design and manage business networks, protective DNS and endpoint policy for companies that would rather find this out in a review than in an incident.
