To understand DoH and DoT, it's essential to understand the core problems of traditional DNS. Standard DNS queries use UDP or TCP protocols, transmitted on port 53, with the content completely unencrypted. This leads to three risks: First, privacy breaches—anyone with network monitoring capabilities can know which websites you've visited, even if the websites themselves use HTTPS encryption; second, tampering and hijacking—malicious attackers can forge DNS responses, redirecting you to phishing websites or advertising pages, commonly known as DNS hijacking; and third, censorship and interference—network administrators can intercept or block DNS requests based on plaintext. DoH and DoT fundamentally solve these problems by integrating DNS queries into a robust encrypted tunnel.

DNS over TLS, as the name suggests, establishes an encrypted tunnel between the DNS client and server using the same TLS protocol as HTTPS websites. It still uses the independent DNS protocol but changes the communication port from the standard 53 to port 853. When your device (client) wants to resolve a domain name, it first completes a TLS handshake with a DoT-enabled DNS server (such as `1.1.1.1` or `8.8.8.8`) on port 853 to establish an encrypted connection. All subsequent DNS queries and responses occur within this encrypted channel. For observers along the network path, they can only see encrypted data streams, but cannot decrypt the specific query content. DoT's design maintains DNS's position as an independent, dedicated service. Network administrators can clearly identify and manage DoT traffic through port 853, which is both an advantage (facilitating enterprise network policy control) and a potential disadvantage (this port may be directly blocked in strictly restricted environments).

In contrast, DNS over HTTPS adopts a more integrated strategy. DoH does not create a new port; instead, it encapsulates all DNS query and response data into standard HTTPS requests and responses. This means that DoT traffic is indistinguishable from ordinary web browsing and API call traffic, running on port 443 and mixed in with the vast flow of HTTPS data on the internet. A DoH query is essentially an HTTP POST or GET request sent to a specific URL (e.g., Cloudflare's `https://1.1.1.1/dns-query`), and the server returns an HTTP response containing DNS response data. Because HTTPS itself provides end-to-end encryption and integrity verification, DNS information is perfectly protected. This deep integration brings strong anonymity, but also raises greater controversy—network administrators find it increasingly difficult to distinguish DNS management traffic from other web traffic.

We can understand their core differences through a simple comparison. Imagine you want to send a confidential letter: using DoT is like renting a secure courier line (port 853) to send the letter; the security guard knows it's a "secure channel" but doesn't know the letter's content. Using DoH, on the other hand, is like writing the letter's content on a piece of paper and stuffing it into a regular courier box (HTTPS traffic) that carries thousands of similar packages daily; outsiders have no idea which box contains your letter or what it says.

In terms of technical implementation, DoH, being based on HTTP/2 or HTTP/3, typically makes better use of modern web protocol features such as multiplexing, reducing latency. Major operating systems (such as Windows, Android, and macOS) and browsers (such as Chrome and Firefox) natively integrate DoH or DoT support. Users or enterprise IT administrators can easily configure it. For example, on Linux systems, you can manually initiate a DoH query using the `curl` command to visually see how it works:

# Use curl to send a DNS query to Cloudflare's DoH endpoint, requesting the A record for example.com

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

The server will return an encrypted JSON response. For DoT, you can use the `kdig` or `openssl` commands to test:

# Simulate a DoT connection using `openssl s_client` to connect to Cloudflare's DNS over TLS service

`openssl s_client -connect 1.1.1.1:853`

After this connection is established, you can enter binary DNS query data (usually generated using other tools) for testing.

However, the popularity of DoH and DoT is not without controversy and challenges. The biggest controversy centers on network visibility and management. In enterprise, school, or public network environments, administrators traditionally rely on monitoring DNS requests to implement security policies (such as blocking malware connections to command servers, filtering inappropriate content), and optimize network performance. DoH, especially when browsers bypass system settings and directly use built-in DoH services (such as those enabled by default in Firefox), renders these network-level security policies ineffective; this is known as "DoH bypass." To address this, enterprises may need to deploy more sophisticated deep packet inspection technologies or directly block the IP addresses of specific public DoH services on their firewalls. Another challenge is the risk of service centralization. If a large number of users rely on public DoH services provided by a few large companies (such as Google and Cloudflare), these providers gain extraordinary insights into user network behavior. Despite their promises of strict privacy policies, this still raises concerns about data monopolies and single points of failure.

So, how should one choose in practice? For individual users, the primary goal is to enhance privacy and prevent local network hijacking. Enabling DoH/DoT functionality in browsers or operating systems is a direct and effective method, prioritizing reputable, privacy-friendly providers. For enterprise IT administrators, a balance needs to be struck between security and control. One feasible solution is to deploy their own recursive DNS server (such as Unbound or Bind) that supports both DoT and DoH within the enterprise, and force all enterprise devices' DNS (including DoH/DoT) to point to this internal server. This provides internal security through encrypted channels (preventing internal network eavesdropping) while maintaining unified management policies and logging capabilities.

In conclusion, DoH and DoT represent an important step in the evolution of DNS protocols towards greater security and privacy. Through sophisticated encryption technologies, they have protected the most fundamental yet long-exposed address lookup service on the internet. While their application has sparked renewed discussions about network management models, the direction of technological development is clear.