DNS over HTTPS vs. DNS over TLS: What's the Difference?

Updated on Sep 27, 2026

9 min read

DNS over HTTPS (DoH) and DNS over TLS (DoT) encrypt DNS queries between a device and its recursive resolver. They address a basic privacy weakness in traditional DNS, but use different transports and are configured in different places. This comparison is for developers, network operators, and privacy-conscious users who need to understand what each protects, what remains visible, and how to choose a resolver without mistaking encryption for anonymity.

What Are DNS over HTTPS and DNS over TLS?

DNS translates names such as example.com into records that applications need to connect to services. In traditional DNS, the request from a device to its recursive resolver is usually sent as plaintext over UDP or TCP port 53. A person or network device along that path may be able to read or modify the query.

DoT sends ordinary DNS messages through a Transport Layer Security (TLS) connection. DoH carries DNS messages over HTTPS, the same application protocol used by encrypted websites. Both protect the connection between a client, also called a stub resolver, and a recursive resolver. The IETF specification for DNS over TLS (RFC 7858) describes the TLS transport, while RFC 8484 defines DNS messages carried over HTTPS.

The protocols do not change what DNS records mean or how domain ownership works. They encrypt one part of the lookup path; the resolver still has to process the query and usually contacts authoritative DNS servers using conventional DNS.

Why Encrypted DNS Exists

Without transport encryption, a local network, internet provider, or other on-path observer can inspect DNS requests and responses. This can reveal which services a device is trying to reach even when the later web connection uses HTTPS. An attacker able to alter an unprotected reply may also try to redirect a client to a different address.

Encryption limits this exposure on the link between the device and the recursive resolver. It does not prevent the resolver from seeing the query, and it does not conceal every sign of later activity. The IP address of a destination, connection timing, and traffic volume may still be visible to other parties. A resolver is therefore a trust decision: changing to an encrypted protocol can move visibility from a local network to the resolver provider rather than removing it altogether.

How DoH and DoT Work

The lookup still follows the usual DNS roles:

Application
    |
    v
Stub resolver -- encrypted DoH or DoT --> Recursive resolver
                                            |
                                            v
                                   Authoritative DNS servers

The stub resolver sends a query to a configured recursive resolver. The recursive resolver checks its cache and, if needed, follows DNS delegations to find the authoritative answer. It then returns the answer through the encrypted client-to-resolver connection. DoH and DoT do not normally encrypt every recursive-to-authoritative exchange; that is a separate deployment choice.

Feature	DNS over HTTPS (DoH)	DNS over TLS (DoT)
Encapsulation	DNS message carried in HTTP over TLS	DNS message carried directly in TLS
Common destination port	HTTPS, usually 443	Dedicated port 853
DNS message format	Standard DNS wire format in an HTTP request and response	Standard DNS message inside the TLS stream
Typical client configuration	Browser, operating system, or DoH-capable resolver	Operating system, stub resolver, or device-level private DNS setting
Network visibility	Encrypted as HTTPS; simple port-based filters may not distinguish it from web traffic	Encrypted but easier to identify by its usual port
Main operational trade-off	Can traverse networks that allow HTTPS, but may be harder to manage centrally	Clearer to identify and control, but port 853 may be blocked

DNS over HTTPS

DoH sends a DNS message to an HTTPS endpoint. The request can use HTTP methods and headers, while the DNS payload uses the standard wire format defined by RFC 8484. Because HTTPS commonly uses port 443, DoH can work on networks that restrict other outbound ports. The Cloudflare DoH documentation describes its public resolver endpoint and client setup options.

That transport can make basic network filtering more difficult: a rule that only blocks non-web ports may not stop a DoH client. It does not make DoH invisible. The resolver’s address, connection metadata, and some TLS-level information may still be observable, and an organization may manage encrypted DNS through endpoint policy or approved resolvers.

DNS over TLS

DoT establishes a TLS connection directly for DNS traffic, normally on TCP port 853. A resolver certificate lets the client verify it has connected to the intended service, provided the client validates the certificate and hostname correctly. The Cloudflare DoT documentation gives a public resolver example; the 1.1.1.1 service homepage identifies the service and its supported encrypted DNS options.

The dedicated port makes DoT straightforward for network operators to identify and allow or deny. It also means that a network blocking outbound port 853 can prevent a client from using DoT unless an alternate path is available. DoT is often offered as an operating-system or device resolver setting, so applications usually inherit the system choice.

Components and Key Differences

Stub resolver: The client-side software that sends a query. It may be built into the operating system, a browser, or a separate resolver application. A browser with its own DoH setting can bypass the system resolver, which can surprise administrators who expect every application to follow the same policy.

Recursive resolver: The service that accepts the query, checks its cache, and finds the answer. DoH and DoT protect traffic up to this service, not from the service itself. Consider its privacy policy, jurisdiction, logging, availability, and support for DNSSEC validation before choosing a provider.

Endpoint and server identity: DoH clients need the HTTPS URL of the resolver, while DoT clients generally need a hostname or address and a TLS identity to verify. Do not treat an IP address alone as proof that a resolver is trusted. Correct certificate validation is essential for both protocols.

DNSSEC: DNS Security Extensions add cryptographic signatures that allow validating resolvers to check the authenticity and integrity of DNS data. DNSSEC does not encrypt a query. DoH or DoT encrypts the client-to-resolver transport but does not prove that the returned data is authentic. These controls can be used together.

Neither transport is inherently more confidential from the resolver than the other. The meaningful differences are how clients configure them, how they behave on a particular network, and what control the operator needs.

Real-World Use Cases

Public Wi-Fi and shared networks: Encryption reduces the ability of local on-path observers to read or alter the client-to-resolver exchange.
Managed enterprise networks: DoT’s separate port can make policy enforcement and monitoring simpler. DoH may need browser or endpoint controls so clients use approved resolvers.
Browser-specific privacy settings: DoH lets a browser choose an encrypted resolver even when the operating system does not offer an encrypted DNS option.
Home networks: A router or local resolver can forward queries to an upstream DoH or DoT service, centralizing configuration while still allowing the local administrator to see queries.

These protocols do not replace a firewall, VPN, DNS filtering policy, or secure application connection. The right choice depends on the clients and the network policy, not on a promise that one protocol hides all browsing activity.

Practical Guide: Test DoH and DoT

First choose a resolver you trust and check whether the client application or operating system already has encrypted DNS enabled. For a Linux command-line test, install kdig, part of the Knot DNS utilities. On Debian or Ubuntu:

sudo apt install knot-dnsutils

On Fedora:

sudo dnf install knot-utils

Send a DNS query over TLS to Cloudflare’s public resolver and require certificate validation:

kdig +tls +tls-ca +tls-host=one.one.one.one @1.1.1.1 example.com A

The command should return an A record and show that the TLS connection succeeded. If it times out, check whether outbound TCP port 853 is allowed and whether the system clock and certificate store are valid. Consult the resolver provider’s current hostname and configuration documentation rather than disabling certificate checks.

For a quick DoH request using Cloudflare’s supported JSON interface, run:

curl --fail --silent --show-error \
  -H 'accept: application/dns-json' \
  'https://cloudflare-dns.com/dns-query?name=example.com&type=A'

The response should be JSON containing a successful status and an answer section. This checks the HTTPS endpoint and its JSON API; a production client that uses the standard DNS wire format should use a DoH-capable stub resolver or application. An HTTP response alone does not prove that every application on the device uses DoH.

After testing, verify the active resolver in the operating system and the application. Browsers may have independent secure-DNS settings, while Android’s system-level Private DNS commonly uses DoT. If DNS fails after enabling encryption, check resolver hostname validation, proxy or firewall rules, captive portals, and whether the client has silently fallen back to plaintext. A privacy policy should make fallback behavior explicit rather than hiding a failed secure connection.

Common Misconceptions

“DoH is automatically more secure than DoT.”

Both use TLS to protect the client-to-resolver connection. DoH runs through HTTPS and DoT uses a dedicated DNS-over-TLS connection. A careless setup, an untrusted resolver, or disabled certificate validation can undermine either one.

“Encrypted DNS hides every domain from everyone.”

The recursive resolver still receives the domain name. Other observers may infer activity from destination IP addresses, connection timing, or other metadata. Encryption narrows who can read the DNS exchange; it is not anonymity.

“DoH or DoT replaces DNSSEC.”

Transport encryption protects the path to a resolver. DNSSEC helps a validating resolver authenticate DNS data. They address different threats and can complement each other.

“A browser’s secure-DNS toggle controls the whole device.”

A browser can use its own DoH resolver independently of the operating system. Other applications may continue to use the system resolver, so device-wide behavior depends on configuration at both layers.

Follow the full DNS lookup process to see how recursive and authoritative servers work together.
Read DNS configuration on Linux for resolver, BIND, and DNSSEC administration.
See self-hosted DNS with Pi-hole and AdGuard Home for local resolver and upstream configuration.