Support Library
DoH vs DoT vs DoQ
DoH, DoT, and DoQ all encrypt DNS between a client and its resolver; they differ in transport. DoT uses TLS on port 853, DoH hides DNS inside HTTPS on port 443, and DoQ runs over QUIC on UDP port 853.
The short answer
Classic DNS, sometimes called Do53 because it uses port 53, sends queries and answers in plain text over UDP or TCP. Anyone on the path, from the coffee shop Wi-Fi to an upstream ISP, can read which names you look up and can tamper with the answers. DNS over TLS (DoT), DNS over HTTPS (DoH), and DNS over QUIC (DoQ) all fix that for the hop between your device (the stub resolver) and the recursive resolver it uses. The DNS messages inside are the same in all three. What changes is the wrapper, and the wrapper decides how the traffic looks to the network, how it performs, and how easy it is for a network operator to manage.
Use DoT when you want encrypted DNS that a network can still recognize and manage, such as on managed devices and resolvers. DoH is the choice for applications and browsers that need to work wherever HTTPS works. DoQ is worth testing when you want encryption with lower connection setup cost, especially on mobile or lossy networks, and your resolver supports it. What you can actually use depends on the client: support for each protocol, and options such as how the resolver's certificate and hostname are checked, differ between operating systems, browsers and versions.
Why encrypt DNS at all
DNS queries reveal a lot. Even when the web traffic that follows is protected by HTTPS, the lookup for a hostname tells an observer which service you are about to contact. RFC 9076, DNS Privacy Considerations describes these risks in detail, including passive monitoring on shared networks and at ISPs.
Plain DNS is also easy to tamper with. An on-path device can rewrite answers or inject fake ones, which is one way captive portals, some ISP redirect pages, and some attacks work. Encrypted DNS authenticates the resolver with a TLS certificate, so a device in the middle cannot read or alter the exchange without being detected.
It is important to be precise about scope. These protocols protect the stub-to-resolver hop only. The resolver still decrypts every query, and most traffic between recursive resolvers and authoritative servers remains unencrypted today. They also do not prove that the records are genuine. That is the job of DNSSEC, compared in DNSSEC vs DoH.
How each protocol works
DNS over TLS (DoT)
Defined in RFC 7858, DNS over Transport Layer Security. The client opens a TCP connection to port 853, completes a TLS handshake, and then sends normal DNS messages using the same two-byte length prefix that DNS over TCP already uses. One connection can carry many queries, and answers may come back out of order. Because port 853 is dedicated to DoT, the traffic is encrypted but clearly identifiable as DNS.
DNS over HTTPS (DoH)
Defined in RFC 8484, DNS Queries over HTTPS. Each DNS message is sent as an HTTP request to a URL on the resolver, commonly a path such as /dns-query, using the media type application/dns-message. GET requests carry the query base64url-encoded in a dns parameter, while POST requests carry it in the body. It runs over port 443, usually with HTTP/2 or HTTP/3, so to an observer it looks like any other HTTPS connection to that server.
DNS over QUIC (DoQ)
Defined in RFC 9250, DNS over Dedicated QUIC Connections. QUIC is a transport built on UDP with TLS 1.3 integrated into it. DoQ sends each query on its own QUIC stream, so a lost packet only delays the query it belongs to instead of every query behind it on the connection. It uses UDP port 853 and the ALPN token doq. Note that DoH over HTTP/3 also runs on QUIC, but it is still DoH: the DNS message is wrapped in HTTP, not sent directly on the QUIC stream.
Side-by-side comparison
| Property | DoT | DoH | DoQ |
|---|---|---|---|
| Standard | RFC 7858 | RFC 8484 | RFC 9250 |
| Transport | TLS over TCP | HTTP/2 or HTTP/3 over TLS | QUIC over UDP |
| Default port | 853/tcp | 443/tcp (443/udp with HTTP/3) | 853/udp |
| Recognizable as DNS on the wire | Yes, by port | Not easily, blends with HTTPS | Yes, by port |
| Head-of-line blocking | Yes, one TCP stream | Yes on HTTP/2, no on HTTP/3 | No, one stream per query |
| Typical home | OS-level stubs, routers, Android Private DNS | Browsers and apps, also OS stubs | Newer resolvers and clients |
Support varies by operating system version and resolver, so check the documentation for the specific client and resolver you plan to use rather than assuming a feature is present.
Performance and reliability
Encryption adds a handshake. A fresh DoT or DoH connection needs a TCP handshake and a TLS handshake before the first query is sent, which costs round trips. In practice, clients keep connections open and reuse them, so the cost is paid once and later queries are close to plain DNS speed. TLS session resumption shortens reconnects.
QUIC folds the transport and TLS handshakes together, and it can resume with 0-RTT data on a known server, so DoQ and DoH over HTTP/3 can start answering sooner on a new connection. QUIC also handles changing networks better: a phone that moves from Wi-Fi to mobile data can migrate the connection instead of rebuilding it.
The trade-off is reachability. Some networks block or throttle UDP on unusual ports, which can make DoQ fail where DoT or DoH would work. Robust clients fall back from one transport to another, and that fallback logic often matters more to real-world reliability than the protocol choice itself. The general behavior of DNS over the two transports is covered in TCP vs UDP and Why DNS Uses Both.
Network control, discovery, and enterprise use
The biggest practical difference between DoT and DoH is not speed but visibility. Network operators often rely on their own resolvers for filtering malware domains, split-horizon names, and logging. DoT on port 853 can be allowed, redirected, or blocked as a policy decision. DoH on port 443 is hard to separate from web traffic, so an application with DoH enabled may quietly bypass the network's resolver. That is a privacy feature on a hostile network and a management problem on a corporate one. If your internal names resolve only on internal resolvers, a browser using an external DoH resolver will fail to find them, which is one reason DNS works on one network but not another.
Standards now exist to help clients find an encrypted resolver the network actually offers. RFC 9462, Discovery of Designated Resolvers lets a client ask its current plain DNS resolver whether it has an encrypted equivalent, and RFC 9463, DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers lets the network announce one directly. In managed environments, the cleaner approach is usually to run your own DoH or DoT service and configure devices to use it through policy, rather than trying to block every external resolver.
Testing each protocol from the command line
Recent versions of BIND's dig (9.18 and later) can send queries over DoT and DoH, and kdig from Knot DNS supports DoT and DoH as well. For DoQ, use a client that implements RFC 9250, since not every dig build includes it. The resolver below uses a documentation address.
$ dig +tls @192.0.2.53 example.com A +short
203.0.113.10
$ dig +https @192.0.2.53 example.com A
...
;; ANSWER SECTION:
example.com. 300 IN A 203.0.113.10
;; Query time: 21 msec
;; SERVER: 192.0.2.53#443(192.0.2.53) (HTTPS)
$ kdig +tls-ca +tls-hostname=dns.example.net @192.0.2.53 example.com AThe SERVER line confirms which port and transport were used. When testing DoT or DoH, also verify the certificate: a client that does not check the resolver's name is encrypted but not authenticated. DNS over HTTPS (DoH) Testing walks through more DoH-specific checks.
How DNS Panopticon helps
DNS Panopticon's own lookups use encrypted DNS. Domain Visualizer resolves records through Cloudflare and Google DNS-over-HTTPS resolvers, and Website Recon resolves the records it inspects over DNS-over-HTTPS as well, so you see what a large public resolver returns rather than what your local network's resolver does. If a name resolves in those tools but not on your machine, the difference often points to your local resolver, a filtering policy, or split-horizon DNS rather than to the zone itself. The tools do not test whether a particular resolver supports DoT, DoH, or DoQ; use the command-line checks above for that.
FAQ
Is DoH more secure than DoT?
Not in terms of cryptography. Both use TLS to authenticate the resolver and encrypt queries. The practical difference is that DoH shares port 443 with ordinary web traffic, which makes it harder for a network to identify or block, while DoT uses its own port 853.
Does encrypted DNS replace DNSSEC?
No. Encrypted DNS protects the path between your device and the resolver from eavesdropping and tampering. DNSSEC lets a resolver verify that the records themselves came unmodified from the zone owner. They solve different problems and work well together.
Can my resolver still see my queries with DoH, DoT, or DoQ?
Yes. Encryption hides queries from the networks in between, but the resolver you send them to decrypts and answers every one. Choosing a resolver whose logging and privacy policy you trust matters as much as choosing the protocol.