DNS Privacy: DoH and DoT Explained - Encrypting Your Internet's Address Book

The DNS Privacy Problem

Every time you visit a website, stream a video, or open an app, your device asks a question: "What is the IP address for this domain name?" This question - a DNS query - is sent in plain text across the network. Your ISP can see it. Your corporate network administrator can see it. Anyone monitoring the network between you and the DNS resolver can see it. The WiFi operator at the coffee shop can see it.

DNS is the internet's address book. It translates human-readable domain names (like infishark.com) into IP addresses (like 23.227.38.65) that computers use to route traffic. Without DNS, you would need to memorize IP addresses for every service you use. DNS is fundamental infrastructure - every internet-connected device uses it constantly.

The problem is that DNS was designed in 1983 when the internet was a small academic network and privacy was not a concern. DNS queries are sent as unencrypted UDP packets on port 53. There is no authentication, no encryption, and no integrity protection. This means anyone in a position to observe network traffic can see every domain name you query, and anyone in a position to modify network traffic can alter DNS responses to redirect you to malicious servers.

For decades, this was accepted as a normal part of how the internet works. The push for DNS privacy gained momentum in the 2010s as awareness of mass surveillance programs grew, as ISPs began monetizing DNS data for advertising, and as the technical community recognized that encrypting everything except the DNS lookup was leaving a significant privacy gap.

How Standard DNS Works

Understanding the privacy problem requires understanding the DNS resolution process.

sequenceDiagram
    participant Client as Your Device
    participant Resolver as Recursive Resolver
    participant Root as Root DNS Server
    participant TLD as TLD Server (.com)
    participant Auth as Authoritative Server
    participant ISP as ISP/Network Observer
    
    Client->>Resolver: Query: infishark.com? (UDP port 53, plaintext)
    Note over ISP: ISP sees: "User queried infishark.com"
    
    Resolver->>Root: Query: infishark.com?
    Root->>Resolver: Refer to .com TLD servers
    
    Resolver->>TLD: Query: infishark.com?
    TLD->>Resolver: Refer to infishark.com nameservers
    
    Resolver->>Auth: Query: infishark.com?
    Auth->>Resolver: Answer: 23.227.38.65
    
    Resolver->>Client: Answer: 23.227.38.65 (plaintext)
    Note over ISP: ISP sees: "Response: infishark.com = 23.227.38.65"
    
    Client->>Client: Connect to 23.227.38.65 via HTTPS
    Note over ISP: ISP sees: encrypted HTTPS traffic
    Note over ISP: But already knows the destination from DNS

Standard DNS resolution - every query and response is visible to network observers in plaintext.

When you type a URL into your browser, your device sends a DNS query to a recursive resolver. By default, this is usually your ISP's DNS server (assigned automatically via DHCP when you connect to the network). The query travels as an unencrypted UDP packet.

The recursive resolver performs the actual lookup by querying the DNS hierarchy: root servers, then TLD (Top-Level Domain) servers, then the authoritative servers for the specific domain. It caches the results to speed up future queries and returns the answer to your device.

The entire exchange between your device and the resolver is unencrypted. The query includes the full domain name being requested. The response includes the IP address and potentially other records. Both are visible to anyone who can observe the network path between your device and the resolver.

Even if you manually configure a third-party resolver (like Cloudflare's 1.1.1.1 or Google's 8.8.8.8), the queries still travel in plaintext. Changing the resolver changes who sees the query data, but it does not encrypt the path between your device and the resolver. Your ISP can still see every DNS query because the traffic passes through their network.

What DNS Queries Reveal

DNS queries reveal a remarkably detailed picture of your internet activity.

Browsing history: Every website you visit requires at least one DNS lookup. The sequence of DNS queries creates a chronological record of your web browsing: infishark.com at 9:00 AM, gmail.com at 9:05, reddit.com at 9:10. This is functionally equivalent to a browsing history, reconstructed entirely from DNS data.

App usage: Mobile apps make DNS queries for their backend services. api.instagram.com reveals Instagram usage. play.spotify.com reveals Spotify streaming. The query patterns can even reveal in-app behavior - querying different subdomains for different app features.

Interests and activities: The domains you query reveal your interests, health concerns, political leanings, and personal circumstances. webmd.com/diabetes suggests a health concern. lawyer.com/divorce suggests a legal matter. Indeed.com suggests job searching. These inferences, drawn entirely from DNS data, can be deeply personal.

Device and service inventory: DNS queries from IoT devices reveal what smart home devices you own. update.ring.com means a Ring doorbell. dns.nest.com means a Nest thermostat. ntp.roku.com means a Roku streaming device. The DNS query log from a home network is effectively an inventory of every internet-connected device in the household.

Timing and patterns: The timing of DNS queries reveals daily routines. A burst of queries at 7 AM suggests waking up. A shift from work domains to entertainment domains around 6 PM suggests the end of the work day. Regular queries to a dating app at specific times suggest scheduled activity. DNS metadata tells a story about the user's life even without inspecting the content of any website visited.

DNS over TLS (DoT)

DNS over TLS, defined in RFC 7858 (2016), encrypts DNS queries by wrapping them in a TLS session. The concept is straightforward: establish a TLS connection to the resolver (the same encryption protocol that protects HTTPS traffic), then send DNS queries through that encrypted tunnel.

DoT uses a dedicated port: TCP port 853. This is distinct from standard DNS (UDP port 53) and from HTTPS (TCP port 443). The use of a dedicated port has both advantages and disadvantages for privacy.

The TLS layer provides three protections:

Confidentiality: The DNS query and response are encrypted. A network observer can see that you are communicating with a DoT resolver on port 853, but cannot see the content of the queries - which domain names you are looking up.

Integrity: The TLS layer ensures that queries and responses are not modified in transit. A man-in-the-middle cannot alter DNS responses to redirect you to a malicious server (DNS spoofing), which is a common attack against standard DNS.

Authentication: The resolver's TLS certificate verifies its identity. Your device can confirm that it is actually communicating with the intended resolver and not an impersonator. This prevents DNS hijacking attacks where a local network operator redirects DNS traffic to their own server.

The performance impact of DoT is minimal for most use cases. The TLS handshake adds latency to the first query (typically 50-100ms additional), but subsequent queries reuse the TLS session and add negligible overhead. Connection reuse and TCP keep-alive minimize the impact of the TCP overhead compared to UDP-based standard DNS.

DNS over HTTPS (DoH)

DNS over HTTPS, defined in RFC 8484 (2018), encrypts DNS queries by sending them as HTTPS requests to the resolver. The DNS query is encoded as either a URL parameter (using the GET method) or an HTTP message body (using the POST method) and sent to a standard HTTPS endpoint on port 443.

The key difference from DoT is the port: DoH uses port 443, the same port as all other HTTPS traffic. This makes DoH traffic indistinguishable from regular HTTPS web browsing. A network observer can see that you are communicating with a server on port 443, but cannot easily determine whether the traffic is a DNS query or a regular web request.

DoH provides the same three protections as DoT (confidentiality, integrity, authentication) but adds a fourth: unblockability. Because DoH traffic looks like regular HTTPS traffic, it is extremely difficult to selectively block DoH without blocking all HTTPS traffic. A network administrator who wants to force users to use the local DNS resolver (for filtering or monitoring purposes) can easily block port 853 (DoT) but cannot easily block DoH without inspecting every HTTPS connection.

DoH also benefits from existing HTTP infrastructure. It can use HTTP/2 multiplexing to send multiple DNS queries over a single connection efficiently. It can traverse HTTP proxies. It integrates naturally with existing HTTPS connection pools in web browsers, which may already have a connection to the resolver's server for other purposes.

graph TD
    subgraph Standard["Standard DNS - Port 53"]
        C1[Client] -->|Plaintext UDP| R1[Resolver]
        OBS1["Network Observer"] -.->|Sees everything| C1
        OBS1 -.->|Domain names visible| R1
    end
    
    subgraph DoT_Protocol["DNS over TLS - Port 853"]
        C2[Client] -->|TLS Encrypted TCP| R2[Resolver]
        OBS2["Network Observer"] -.->|Sees: encrypted traffic on port 853| C2
        OBS2 -.->|Knows it is DNS, but not which domains| R2
    end
    
    subgraph DoH_Protocol["DNS over HTTPS - Port 443"]
        C3[Client] -->|HTTPS Request| R3[Resolver]
        OBS3["Network Observer"] -.->|Sees: HTTPS traffic on port 443| C3
        OBS3 -.->|Cannot distinguish DNS from web browsing| R3
    end
    
    subgraph Privacy["Privacy Comparison"]
        P1["Standard: Zero privacy"]
        P2["DoT: Encrypted but identifiable as DNS"]
        P3["DoH: Encrypted and indistinguishable"]
    end

Comparison of standard DNS, DoT, and DoH - privacy protection levels and network observer visibility.

DoT vs. DoH: Key Differences

The choice between DoT and DoH involves trade-offs that depend on your threat model and priorities.

Visibility: DoT is identifiable on the network because it uses a dedicated port (853). A network administrator can see that you are using encrypted DNS, even though they cannot see the query content. DoH is hidden among regular HTTPS traffic on port 443, making it difficult to detect or block. If your goal is to prevent network operators from knowing you are encrypting DNS, DoH is the better choice.

Blockability: DoT can be blocked by simply dropping traffic on port 853. Some corporate networks and restrictive regimes do this to force users onto local DNS resolvers. DoH is much harder to block because you would need to block all HTTPS traffic or implement deep packet inspection to identify DoH connections among billions of HTTPS flows. If you are in an environment that tries to control DNS resolution, DoH is more likely to work.

Network administration: From a network administrator's perspective, DoT is preferable because it is identifiable. An admin can see that encrypted DNS is being used, monitor that it is working correctly, and distinguish it from other traffic types. DoH is problematic for administrators because it bypasses network-level DNS filtering (used for security policies, parental controls, and compliance) without any indication.

Performance: Both protocols add similar overhead for the encryption itself. DoT may have a slight edge in raw performance because it does not carry HTTP header overhead. DoH may have an edge in practice because it can reuse existing HTTPS connections and benefit from HTTP/2 features. In most real-world scenarios, the performance difference is negligible.

Application integration: DoH is easier to integrate into applications because it uses standard HTTPS libraries that every programming language supports. Browsers like Firefox and Chrome have built-in DoH support. DoT requires TLS implementation at the OS or system resolver level, which is more complex and less commonly supported by applications directly.

Choosing a Trusted Resolver

Encrypted DNS shifts trust from your local network operator to the resolver you choose. This is a trade-off, not an elimination of trust. The resolver still sees all your DNS queries in plaintext (it has to, in order to resolve them). You are choosing to trust the resolver operator instead of your ISP or local network.

Major public DoH/DoT resolvers include:

Cloudflare (1.1.1.1): Promises not to log DNS queries, subject to annual third-party audits (conducted by KPMG). Supports both DoH (https://cloudflare-dns.com/dns-query) and DoT. Generally considered fast, with global anycast deployment providing low latency from most locations.

Google Public DNS (8.8.8.8): Supports both DoH and DoT. Google logs DNS query data and retains it for 24-48 hours in full, then stores anonymized data longer. Google's privacy policy governs how this data is used. The concern with Google is the amount of data they already collect about users - adding DNS data to the profile increases their visibility into user behavior.

Quad9 (9.9.9.9): A non-profit resolver operated by the Global Cyber Alliance. Includes threat intelligence blocking (known malicious domains are blocked). Promises minimal logging. Supports both DoH and DoT.

NextDNS: A configurable resolver that supports custom filtering, logging, and analytics. Users can choose their privacy level - from full logging to zero logging. Supports DoH and DoT with configurable block lists for ads, trackers, and malware.

Self-hosted resolvers: Running your own resolver (using software like Unbound, Pi-hole, or AdGuard Home) with upstream DoH/DoT connections provides the most control. You do not need to trust any third party with your query data. The trade-off is operational complexity and the loss of the performance benefits of large resolvers' extensive caches.

When evaluating resolvers, consider their privacy policy (what they log and for how long), their jurisdiction (which laws govern their data handling), their business model (are they selling your data or funded by other means), and their technical practices (do they support QNAME minimization, DNSSEC validation, and other privacy/security features).

Deployment Options

There are several ways to enable encrypted DNS, each with different coverage and complexity.

Browser-level DoH is the easiest to deploy. Firefox and Chrome both support DoH in their settings. Firefox has a dedicated DNS settings panel where you can select a DoH provider. Chrome follows the system resolver by default but will automatically upgrade to DoH if the configured resolver supports it. Browser-level DoH only protects DNS queries from the browser - other applications on the system still use standard DNS.

Operating system-level encrypted DNS protects all DNS queries from the device. iOS 14+ and macOS Big Sur+ support encrypted DNS profiles that configure DoH or DoT system-wide. Android 9+ supports "Private DNS" (DoT) in the network settings. Windows 11 supports DoH for configured resolvers. System-level configuration protects all apps, not just the browser.

Router-level encrypted DNS protects all devices on the network. Routers running firmware like OpenWrt, pfSense, or OPNsense can be configured to forward DNS queries over DoH or DoT to an upstream resolver. This protects every device on the network - including IoT devices that cannot be individually configured. The trade-off is that the DNS traffic between devices and the router is still standard DNS on the local network.

VPN with integrated DNS routes all DNS queries through the VPN tunnel to the VPN provider's resolver. This provides encryption for DNS along with all other traffic. Most reputable VPN providers operate their own DNS resolvers to prevent DNS leaks (where DNS queries bypass the VPN and go directly to the ISP).

Limitations and What Encrypted DNS Does Not Fix

Encrypted DNS is an important privacy improvement, but it has significant limitations.

The resolver still sees everything. Encryption protects the path between your device and the resolver. The resolver itself sees all your queries in plaintext. If you do not trust the resolver operator, encryption merely redirects your data from one observer (your ISP) to another (the resolver operator).

IP addresses are still visible. After DNS resolution, your device connects to the destination IP address. This connection is visible to your ISP regardless of whether the DNS query was encrypted. In many cases, the IP address alone reveals the destination - major websites use distinctive IP ranges, and reverse DNS lookups can map IPs to domain names. Encrypted DNS hides the precise domain queried but does not hide the fact that you connected to a specific server.

SNI leaks the hostname. When connecting via HTTPS, the TLS Client Hello message includes the Server Name Indication (SNI) field, which contains the hostname in plaintext. This allows a network observer to see which website you are connecting to, even if the DNS query was encrypted. Encrypted Client Hello (ECH), a draft standard, addresses this by encrypting the SNI field, but adoption is still in progress.

Traffic analysis can infer destinations. Even with encrypted DNS and encrypted SNI, the size, timing, and pattern of encrypted traffic can reveal what you are doing. Loading a specific webpage produces a distinctive traffic pattern (the sizes and timing of the HTML, CSS, JavaScript, and image requests). Streaming video from Netflix produces a different pattern than streaming from YouTube. These patterns can be matched against known profiles to infer activity.

Local network queries are not protected. DNS queries for local network resources (mDNS, LLMNR, NetBIOS name resolution) use different protocols that are not covered by DoH or DoT. These local queries remain in plaintext on the local network.

DNSSEC and encrypted DNS are different things. DNSSEC (DNS Security Extensions) provides authentication and integrity for DNS responses but does not provide confidentiality. DoH/DoT provides confidentiality but does not validate the authenticity of DNS data. For complete DNS security, both should be used together - DNSSEC to ensure responses are authentic, and DoH/DoT to ensure queries and responses are not observed.

Network Security Trade-offs

Encrypted DNS creates tension between individual privacy and network security. Organizations and network operators have legitimate reasons to monitor and filter DNS traffic.

Malware protection: Many organizations use DNS-based filtering to block known malicious domains. If devices bypass the corporate resolver using DoH directly to an external provider, this protection is circumvented. Malware that uses DoH for command-and-control communication is harder to detect because the DNS queries are hidden from network security tools.

Content filtering: Schools, libraries, and parents use DNS filtering to block inappropriate content. DoH allows users (or malware) to bypass these filters by resolving domains through an external, unfiltered resolver.

Compliance and legal requirements: Some jurisdictions require ISPs to block access to certain domains (court-ordered blocks of piracy sites, for example). If users can trivially bypass DNS blocks using DoH, the enforcement mechanism fails.

Incident response: Network security teams rely on DNS logs for threat detection and incident response. DNS queries to known malicious domains, unusual query patterns, and DNS tunneling are all detectable through DNS monitoring. Encrypted DNS that bypasses the local resolver removes this visibility.

The resolution of this tension is still evolving. Some approaches include: deploying DoH/DoT within the organization (encrypting DNS between clients and the corporate resolver while maintaining local visibility), using canary domains to detect whether clients are using the local resolver, and implementing DNS filtering at the resolver level rather than the network level.

For individual users on their own networks, the calculus is simpler: encrypted DNS provides meaningful privacy improvement with minimal downsides. For users on managed networks (corporate, school, public), the situation is more complex and depends on the specific policies and security requirements of the environment.

DNS privacy is one layer of a comprehensive privacy strategy. Encrypted DNS, combined with VPN usage, encrypted WiFi (WPA3), and awareness of wireless tracking (BLE and WiFi probe requests), provides a much stronger privacy posture than any single measure alone. The BLEShark Nano helps assess the wireless layer of this stack, revealing what your devices broadcast over BLE while encrypted DNS protects the network layer above it.