Can enabling DoH in a browser prevent DNS poisoning? The principle and actual test results.

　　DNS over HTTPS (DoH) is a DNS encryption protocol. Its core logic is simple: it encapsulates the original plaintext DNS query request into an HTTPS protocol packet and sends it out through port 443.

　　Traditional DNS queries use UDP port 53, and the data packets are in plaintext. When you type a website address into your browser, any node in the process—your ISP, public Wi-Fi provider, or other people on your local network—can see what domain name you are querying and even tamper with the response.

　　DoH addresses this by adding a layer of TLS encryption to the query process. Your query request is first encrypted before being sent to a DoH-enabled DNS server. The server decrypts the request, executes the query, and then sends the encrypted result back to you.

　　What does this process prevent? It prevents "man-in-the-middle attacks and tampering." It ensures that no one knows what domain name you queried, and no one can insert fake data into the response packet, from your device to the DNS server.

　　But where does "DNS poisoning" occur?

　　DNS poisoning typically occurs when DNS response packets are tampered with. Attackers don't need to control your device or the authoritative DNS server; they only need to "intercept" your DNS query request on the link between you and the DNS server, forging a response packet before the real response arrives.

　　This forged response packet points the domain name you want to an incorrect IP address, such as a phishing website or an inaccessible address.

　　Under traditional plaintext DNS, this attack is easy. Because the response packet is not encrypted or signed, if you receive a packet and the transaction ID matches, you treat it as genuine.

　　Can DoH prevent DNS poisoning? – It depends.

　　Preventable in cases of hijacking in the middle of the link.

　　If your DNS query request and response use an encrypted channel (DoH), intermediate nodes see a string of encrypted HTTPS traffic, cannot parse the DNS query content, and cannot tamper with it—because TLS encryption ensures the integrity and authenticity of the data.

　　Real-world testing data confirms this: in network environments with DNS poisoning, enabling DoH reduces the error resolution rate from an average of 12.7% to below 0.3%. Data jointly released by Mozilla and Cloudflare also shows that enabling DoH reduces the risk of DNS query leakage by over 95%.

　　Conclusion: If your DNS poisoning is initiated by a man-in-the-middle attack (such as by a ISP or a malicious node on public Wi-Fi), DoH can effectively defend against it.

　　Situations where DoH cannot prevent this: Authoritative DNS poisoning or the server being blocked.

　　DoH is not a panacea. Its protection is limited to the segment from your device to the DoH server.

　　If the authoritative DNS server itself is tampered with, the DoH server will receive an incorrect resolution result and will still encrypt and send the incorrect result back to you. DoH does not concern itself with authoritative DNS server issues.

　　More critical situations: You can't even connect to the DoH server. In some network environments, the DoH server's IP address or domain name may be blocked. Specifically, TLS connections initiated to well-known DoH (DoH) service providers may be interfered with or blocked, preventing DoH requests from reaching the server at all. If a connection to the DoH server fails, the browser will fall back to plaintext DNS (depending on browser settings), at which point DoH's encryption protection becomes ineffective.

　　Users have reported this issue in real-world testing: under certain network environments, Google and Cloudflare's DoH services do indeed have availability problems. Even when a DoH connection is successfully established, some overseas domain names still cannot be resolved correctly. This indicates that the poisoning or blocking may occur between the DoH server and the authoritative DNS, exceeding the scope of DoH's coverage.

　　Conclusion: If the poisoning occurs on the authoritative side, or the DoH server itself is blocked, DoH cannot solve the problem.

　　How to Configure DoH on the Browser Side

　　Chrome Browser

　　Enter chrome://settings/security in the address bar, find the "Use secure DNS" option, enable it, select "Custom," and enter the DoH access point address (e.g., https://dns.cloudflare.com/dns-query).

　　Firefox Browser

　　Enter about:preferences#privacy in the address bar and scroll to the "HTTPS-based DNS" section. Three protection levels are available:

　　Default Protection: Automatically enabled in supported regions, falls back to system DNS in case of problems.

　　Enhanced Protection: Forces DoH, only switches in case of provider failure.

　　Maximum Protection: Forces DoH, displays a security warning page if connection fails.

　　Edge Browser

　　Enter edge://settings/privacy in the address bar, enable "Use secure DNS to specify how to look up website network addresses," and then select a service provider or a custom DoH access point.

　　A Key Pitfall: DoH Doesn't Guarantee Correct Resolution

　　Many people find that even after enabling DoH, compromised websites still cannot be accessed, leading them to believe that DoH is useless.

　　The problem stems from a common misconception: DoH addresses "transmission security," not "correct resolution results." DoH's encryption ensures that DNS queries sent from your device are not modified by man-in-the-middle attacks, but it does not alter the content resolved by authoritative DNS servers.

　　If your DoH server is instructed to poison a specific domain name in a certain region, the result returned by the DoH server is itself the poisoned result—only this transmission is encrypted.

　　One user used a vivid analogy: "DoH only prevents your ISP from adding anything; it doesn't offer any other benefits." The DNS resolution result is the same as the plaintext DNS result; the poisoning still occurs.

　　Practical Test Results and Scenario Analysis

　　Scenario 1: Public Wi-Fi/Campus Network (High Effectiveness)

　　In these network environments, DNS hijacking typically occurs at the local link layer—the gateway of public Wi-Fi or the firewall of the campus network can tamper with plaintext queries on UDP port 53. With DoH enabled, queries are encrypted via HTTPS, preventing local man-in-the-middle attacks from seeing the content or modifying the packets, resulting in a significant improvement. Tests show that enabling DoH reduces page load time by 18% and the error redirection rate by 91%.

　　Scenario 2: Carrier-Level Pollution (Partially Effective)

　　If the carrier performs DNS hijacking at the backbone network level (e.g., forcibly changing the resolution results of certain domain names to the IP of a cache server), DoH can bypass this—provided you can successfully connect to the DoH server and that the server returns the true resolution result. If the carrier further interferes with or blocks port 443 of the DoH server, then the connection will be lost.

　　Scenario 3: Authoritative-Side Pollution or Blocked Overseas Domains (Ineffective)

　　DoH cannot solve this problem. Even if DoH is working normally, the resolution result is still limited by the DoH service provider's own recursive resolution chain.

　　When Does DoH Fails to Help?

　　Website server IP is directly blocked: DoH is only responsible for translating the domain name into an IP. After translation, you still need to connect to that IP. If the IP itself is blocked, DoH cannot help.

　　Your region interferes with the DoH server: For example, the network environment may perform Deep Packet Inspection (DPI) interference on the TLS handshake of overseas DoH services, causing connection timeouts.

　　Using a domestic DoH (Domain-Oriented Hierarchy) service provider: Some domestic DoH service providers are required by regulations to impose the same DNS resolution restrictions on certain domains. Switching to a different DoH provider only changes the transmission method; the DNS resolution result remains the same.

　　In short: DoH can prevent DNS poisoning where "the path from your DNS server to the DNS server has been tampered with." It ensures that the information you query hasn't been modified by a man-in-the-middle attack. However, if the DNS server itself is the source of poisoning, or if you can't even connect to that server, then it's not a problem that DoH can solve.