You already know that DNS translates domain names into IP addresses — the internet’s phone book, as the classic analogy goes. If you want a refresher on how DNS works at its core,our introduction to DNScovers the fundamentals. But here is something most website owners don’t know: every DNS query your visitors make is sent in plain text by default. That means your ISP, network administrators, and anyone monitoring the connection can see exactly which domains are being resolved — even when the page content itself is protected by HTTPS. This is the problem thatencrypted DNSwas designed to solve. In practice, there are four protocols that replace unencrypted DNS:DNS over HTTPS (DoH),DNS over TLS (DoT),DNS over QUIC (DoQ), and DNS over HTTPS/3 (DoH3). Each one encrypts your DNS queries using a different transport layer, with different tradeoffs in performance, privacy, and compatibility. If you have ever searched forDoH vs DoTand found conflicting answers, this article explains why — and gives you real benchmark data from over 3,000 resolvers to help you decide which encrypted DNS protocol is right for your website. Table of Contents Table of Contents When a visitor types your domain name into their browser, their device sends a DNS query before any connection to your server is established. That query travels over the network in plain text on port 53 — visible to: This happens regardless of whether your site uses HTTPS. TheHTTPSencryption protects the content of the page. The DNS query that happens before the connection is made is a completely separate, unprotected step. DNS hijacking exploits this gap: an attacker intercepts the plain-text DNS query and returns a false IP address, redirecting the visitor to a malicious site that looks identical to yours. For websites in sensitive sectors — banking, healthcare, e-commerce — this is a real attack vector with documented incidents. The encrypted DNS protocols solve this by wrapping the DNS query in a secure transport layer. The question is which one to use, and for what purpose. Port:53 (UDP and TCP)Encryption:NoneStatus:Still dominant, but declining for privacy-sensitive use cases The original DNS protocol, defined in RFC 1035 in 1983. Fast, simple, universally supported. The problem is that it was designed in an era when the internet was a small academic network — privacy was not a design concern. Every query is sent in plain text. For server-to-server communication in controlled environments (internal networks, data centers), Do53 is still reasonable. For client-facing DNS — the queries your visitors make from their browsers — it should be replaced by one of the encrypted alternatives. Port:853Transport:TCP + TLS 1.3RFC:7858 (2016)Encryption:YesStatus:Widely deployed, supported by most major resolvers DoT wraps DNS queries in TLS — the same encryption layer used by HTTPS. It runs on a dedicated port (853), which makes it easy for network administrators to identify, filter, or block encrypted DNS traffic. The advantage is simplicity: it is essentially the same encryption model that secures web traffic, applied to DNS. The disadvantage is that the dedicated port makes it easy to detect and block — which is why it has seen limited browser adoption but strong adoption in enterprise and mobile operating systems. Android 9+andiOS 14+support DoT natively as “Private DNS.” If a visitor is using a modern mobile device, there is a reasonable chance their DNS queries are already using DoT — regardless of what your server does. Performance consideration:DoT requires a TCP three-way handshake plus a TLS handshake before the first query — adding approximately 2 round-trip times of latency compared to Do53. For high-frequency DNS environments, this matters. Port:443Transport:HTTPS (HTTP/2 orHTTP/3)RFC:8484 (2018)Encryption:YesStatus:Default in Firefox and Chrome; widely adopted DoH tunnels DNS queries inside standard HTTPS traffic on port 443 — the same port used for all web traffic. This makes it indistinguishable from regular browsing traffic, which means it cannot be selectively blocked without blocking all HTTPS. This is both its greatest strength and the source of its most significant controversy. Enterprise network administrators who need to monitor and filter DNS traffic — for security policy enforcement — cannot do so when DNS is hidden inside HTTPS. This has led to ongoing tension between browser vendors (who favor DoH) and enterprise security teams (who prefer DoT or local resolvers).