Traditional DNS has a privacy problem: every query you make travels across the network in plaintext. When you look up a website, anyone positioned between you and your DNS resolver, your ISP, a network operator, or an attacker on public WiFi, can see exactly which domains you're visiting. They can also potentially tamper with the responses, redirecting you to malicious destinations.
Two protocols were developed to fix this by encrypting DNS queries: DNS over HTTPS (DoH) and DNS over TLS (DoT). Both encrypt the connection between you and your resolver, hiding your queries from network observers and preventing tampering. But they work differently, and the differences have real implications for privacy, network management, and security.
This guide explains both protocols, how they differ, their tradeoffs, and where each fits.
The Problem: Plaintext DNS
Classic DNS sends queries and responses in plaintext over UDP (or sometimes TCP) on port 53. This design dates back to the early internet, when privacy and tampering weren't primary concerns. The consequences today:
- Surveillance: Your ISP and any network operator between you and your resolver can log every domain you query, building a detailed picture of your browsing habits.
- Tampering: An attacker on the network path can inject forged responses, redirecting you to malicious servers (a form of the cache poisoning and spoofing attacks we covered in our cache poisoning guide).
- Censorship: Networks can block access to specific domains by intercepting DNS queries and returning false "not found" responses.
DoH and DoT both solve the surveillance and tampering problems by encrypting the query between you and your resolver. Note that this is different from DNSSEC, which authenticates the data but doesn't encrypt it. DoH and DoT provide confidentiality; DNSSEC provides authenticity. They're complementary.
DNS over TLS (DoT)
DNS over TLS wraps DNS queries in a TLS-encrypted connection, the same encryption technology that secures HTTPS websites. It was standardized in RFC 7858.
How DoT Works
DoT establishes a TLS connection between your device and the resolver, then sends standard DNS queries through that encrypted tunnel. The key characteristic: DoT uses a dedicated port, port 853, specifically designated for encrypted DNS.
Because DoT runs on its own dedicated port, it's identifiable as DNS traffic on the network, even though the contents are encrypted. A network observer can see that you're making DNS queries (because the traffic is on port 853) but cannot see which domains you're querying.
Implications of a Dedicated Port
The dedicated port is both a strength and a weakness depending on your perspective:
- For network administrators: DoT is easy to identify and manage. They can allow it, block it, or monitor that it's happening, even though they can't see the contents. This makes DoT friendlier to enterprise network policies.
- For privacy: The fact that DoT is identifiable means a network can choose to block port 853 entirely, forcing you back to plaintext DNS or no DNS. It also reveals that you're using encrypted DNS, even if not what you're querying.
DNS over HTTPS (DoH)
DNS over HTTPS sends DNS queries inside regular HTTPS requests, the same protocol used for secure web browsing. It was standardized in RFC 8484.
How DoH Works
DoH encodes DNS queries into HTTPS requests and sends them to a resolver's HTTPS endpoint. The critical characteristic: DoH uses port 443, the same port as all other HTTPS web traffic.
Because DoH traffic looks identical to normal HTTPS web traffic, it's extremely difficult for a network observer to distinguish DNS queries from regular web browsing. Your DNS queries blend in with the enormous volume of HTTPS traffic flowing across the network.
Implications of Using Port 443
Running on the same port as web traffic has significant consequences:
- For privacy: DoH is much harder to block or even detect. A network can't block DoH without blocking all HTTPS traffic (which would break the internet). This makes DoH resistant to censorship and surveillance.
- For network administrators: DoH is difficult to manage. Because DNS queries are indistinguishable from web traffic, administrators lose visibility into DNS, which complicates security monitoring, content filtering, and threat detection that rely on observing DNS queries.
The Key Differences
| Property | DNS over TLS (DoT) | DNS over HTTPS (DoH) |
|---|---|---|
| Port | 853 (dedicated) | 443 (shared with HTTPS) |
| Identifiable on network | Yes (as DNS) | No (looks like web traffic) |
| Encryption | TLS | TLS (via HTTPS) |
| Easy to block | Yes (block port 853) | No (without blocking all HTTPS) |
| Network admin visibility | Can see DNS is happening | DNS hidden in web traffic |
| Standard | RFC 7858 | RFC 8484 |
| Best for | Managed networks, enterprises | Maximum privacy, censorship resistance |
The Privacy vs Control Tension
The core difference between DoH and DoT comes down to a tension between individual privacy and network control.
DoH prioritizes individual privacy. By hiding DNS in web traffic, it prevents anyone, including the network operator, from seeing or controlling DNS. This is excellent for users in restrictive environments (censorship, surveillance) but challenging for legitimate network management.
DoT balances privacy with manageability. It encrypts queries (privacy) while remaining identifiable (manageability). Network operators can enforce policies about encrypted DNS while still being unable to see the actual queries.
This tension has made DoH controversial in enterprise and network management circles. Many security tools rely on monitoring DNS queries to detect malware, data exfiltration (like DNS tunneling), and policy violations. When DoH hides DNS inside web traffic, these tools lose visibility. Some organizations block DoH to maintain their security monitoring, while privacy advocates argue DoH protects users from surveillance.
Where Each Is Used
DoH in Practice
- Built into major browsers (Firefox, Chrome, Edge) where it can be enabled per-browser, sometimes bypassing the operating system's DNS settings entirely
- Supported by public resolvers like Cloudflare (1.1.1.1), Google (8.8.8.8), and Quad9
- Popular for personal privacy, especially on untrusted networks
- Used in environments where censorship circumvention is important
DoT in Practice
- Common at the operating system level, particularly Android, which supports DoT as "Private DNS"
- Preferred in managed network environments where administrators want encrypted DNS but also need to enforce network policies
- Supported by the same major public resolvers (Cloudflare, Google, Quad9)
- Easier to deploy network-wide because it's identifiable and manageable
What Encrypted DNS Doesn't Solve
Both DoH and DoT have important limitations to understand:
Your Resolver Still Sees Everything
Encrypting the connection to your resolver hides your queries from the network path, but the resolver itself still sees every query you make. You're shifting trust from your ISP and network to your DNS resolver provider. If you use Cloudflare or Google's resolver, you're trusting them with your DNS queries instead of your ISP. Choose a resolver with a privacy policy you trust.
It Doesn't Authenticate Data
DoH and DoT encrypt the connection but don't cryptographically verify that the DNS data is authentic the way DNSSEC does. A malicious resolver could still return false answers over an encrypted connection. For full protection, encrypted transport (DoH/DoT) and authenticated data (DNSSEC) work together.
SNI and Other Leaks
Even with encrypted DNS, other parts of your connection can reveal which sites you visit. The Server Name Indication (SNI) field in TLS handshakes has historically exposed the destination hostname in plaintext. Encrypted Client Hello (ECH) addresses this, but adoption is ongoing. Encrypted DNS is one piece of browsing privacy, not the whole picture.
It Doesn't Protect Your Own Domains
DoH and DoT protect the privacy of people making queries. They don't protect the security of your domain's authoritative DNS. Securing your own domains requires DNSSEC, proper configuration, monitoring for unauthorized changes, and the other controls we cover throughout this blog.
Which Should You Use?
For personal privacy on untrusted networks: DoH offers the strongest privacy because it's hardest to detect and block. Enabling it in your browser is straightforward.
For managed or enterprise networks: DoT is often preferred because it provides encryption while remaining compatible with network security monitoring and policy enforcement.
For the strongest overall protection: Combine encrypted transport (DoH or DoT) with DNSSEC validation. Transport encryption protects your queries from observers; DNSSEC protects you from forged answers. Together they address both confidentiality and authenticity.
The Bigger Picture for Domain Owners
DoH and DoT are about protecting the people querying DNS. If you operate domains, your responsibility is the other side: ensuring your authoritative DNS is secure, correctly configured, and monitored. This means enabling DNSSEC so resolvers can verify your records are authentic, maintaining correct records, and detecting unauthorized changes quickly.
DNS Assistant focuses on this domain-owner side of DNS security:
- DNSSEC validation ensures the authenticity protection that complements encrypted transport
- Record monitoring catches unauthorized changes to your DNS
- Dangling DNS detection finds subdomains vulnerable to takeover
- Email authentication tracking monitors SPF, DKIM, and DMARC
- Multi-channel alerting via email, Slack, Microsoft Teams, webhooks, and SMS
Get Started
Check your domain's DNSSEC status and configuration with the DNS lookup tool at dnsassistant.com/tools, or run a Free Domain Risk Report for a comprehensive view.
For continuous monitoring of your domains with real-time alerting, sign up at dnsassistant.com.
Start Monitoring Your DNS Today
Get real-time alerts, track record changes, and keep your domains secure with DNS Assistant.
Sign Up Free