Protocol pair
DoH vs DoT Compared on Security, Speed and Blocking
The doh vs dot choice looks bigger than it is. DNS over TLS and DNS over HTTPS both wrap ordinary DNS messages in TLS, both authenticate the resolver with a certificate, and both stop the local network from reading or rewriting your queries. What differs is the packaging, the port, and how the network reacts.
DoT came first: RFC 7858, published in May 2016, defines a TLS session on a dedicated TCP port. DoH followed in October 2018 with RFC 8484, which sends DNS messages as HTTP requests to a URL such as https://dns.quad9.net/dns-query. Most public resolvers, Quad9 among them, offer both endpoints side by side.
DoH vs DoT at a glance
| Property | DNS over TLS (DoT) | DNS over HTTPS (DoH) |
|---|---|---|
| Standard | RFC 7858 (2016), profiles in RFC 8310 | RFC 8484 (2018) |
| Transport | DNS messages inside TLS over TCP | DNS messages inside HTTPS, HTTP/2 or later recommended |
| Default port | TCP 853, reserved for DoT | 443, shared with all HTTPS traffic |
| Server identity | TLS certificate for the resolver hostname | TLS certificate for the resolver hostname |
| Configured as | A hostname, e.g. dns.quad9.net | A URL, e.g. https://dns.quad9.net/dns-query |
| Easy to identify on the network | Yes, by port | Not by port |
| Native OS support | Windows 11, Apple platforms, Android Private DNS | Windows 11, Apple platforms |
DoH vs DoT security: same encryption, different visibility
On the wire, doh vs dot security is a tie. Both rely on TLS, and both authenticate the resolver by checking its certificate against the name you configured. RFC 8310 adds a Strict Privacy profile for DoT, in which the client refuses to continue at all rather than fall back to cleartext queries.
The real difference is who can see that you use encrypted DNS. A firewall can block TCP port 853, and DoT stops working; in the opportunistic profile of RFC 8310 the client then falls back to plain DNS. Blocking DoH means blocking specific HTTPS servers by address or name, which takes far more effort from the network.
For you, that resistance is an advantage of DoH. For a company network administrator, it is a management headache. Microsoft’s Windows 11 documentation reflects the split: administrators can mandate DNS over HTTPS, so that devices using insecure DNS fail to reach network resources, or keep encryption off where edge appliances inspect plain-text queries.
Neither protocol hides the destination IP address of the websites you then visit, and neither protects you from the resolver operator, which still sees every query together with your IP address. If that is the concern, the relay designs, Anonymized DNSCrypt and Oblivious DoH, split the two pieces of information between different servers.
How failures look in practice
Strict and opportunistic modes decide what happens when the encrypted path breaks. Microsoft documents the choice for its DNS client as Encrypted only, Encrypted preferred with unencrypted allowed, or Unencrypted only. In the preferred mode, Windows can drop to plain DNS without notifying you, so the strict setting is the one that actually guarantees encryption.
Android takes the strict route by design. When you enter a Private DNS hostname and the phone cannot reach that server, Android marks the network as having no internet access instead of quietly sending plain queries. That behaviour makes a blocked port 853 obvious, which is useful when you are debugging a hotel or office network.
DoH vs DoT performance: why connection reuse decides
Benchmarks of doh vs dot performance mostly measure something else: whether the client reused its connection. A new TLS session costs handshake round trips before the first answer. RFC 7858 says clients should reuse one connection and pipeline queries, and RFC 8484 recommends HTTP/2 at minimum, which multiplexes queries on one connection.
Once a connection is warm, both protocols add little on top of the resolver’s own response time. HTTP headers make each DoH message slightly larger, while DoT prefixes each message with a two-octet length field. Distance to the resolver and its cache matter far more, which is why the DoH speed test reports cold and warm queries separately.
Where DoQ fits
DNS over QUIC, standardised in RFC 9250, moves DoT’s model to QUIC: a dedicated connection on UDP port 853, negotiated with the ALPN token “doq”. QUIC mitigates the head-of-line blocking that TCP suffers when one packet is lost. Because DoQ shares port 853 with DoT, it is just as easy for a network to block.
Which one to turn on
On Android, the answer is DoT, because the built-in Private DNS setting only takes a hostname. On Windows 11 and Apple devices both are available, and DoH is the better default on networks that interfere with port 853. For DNSCrypt or relays as well, a local client handles it; the comparison matrix lines up every option.
Frequently asked questions
Is DoH or DoT more secure?
The encryption is equivalent: both use TLS and both authenticate the resolver with a certificate. The difference is visibility. DoT on port 853 is clearly DNS traffic, which networks can identify and block. DoH on port 443 looks like normal web traffic, which protects it from simple blocking. Neither one hides your queries from the resolver operator itself.
Which is faster, DoH or DoT?
Neither protocol is inherently faster. Both work best when the client keeps one connection open and reuses it for many queries, which both RFCs recommend. Distance to the resolver and the resolver's cache matter more. A browser speed test against your own candidates gives a more useful answer than a general rule.
Does Android Private DNS use DoH or DoT?
Android's Private DNS setting, introduced with Android 9, uses DNS over TLS. You enter the resolver's hostname and the phone connects to it on port 853. If the phone cannot reach that server, Android marks the network as having no internet access instead of falling back to plain DNS. That strict behaviour makes a blocked port 853 easy to spot.
Can I use DoH and DoT at the same time?
On one device you normally pick one resolver configuration, but nothing stops a browser from using DoH while the operating system uses DoT. That split can send queries to two different resolvers, so check which one each application is using before relying on either. Using one resolver for both keeps a single logging and filtering policy in charge.
Sources
- RFC 7858: Specification for DNS over Transport Layer Security
- RFC 8310: Usage Profiles for DNS over TLS and DNS over DTLS
- RFC 8484: DNS Queries over HTTPS (DoH)
- RFC 9250: DNS over Dedicated QUIC Connections
- Microsoft Learn: Windows 11 network security
- Microsoft Learn: Secure DNS Client over HTTPS (DoH)
- Apple WWDC20: Enable encrypted DNS
- Android Developers Blog: DNS over TLS support in Android P
- Quad9: Service addresses and features