DoH & DoT Demystified: Two Ways to Encrypt DNS

When your browser visits github.com, what's the very first thing it does?

Not an HTTP request. Not a TCP handshake. It's a DNS query. The browser sends a UDP packet asking a DNS server "what's the IP of github.com?" — and only after getting the answer does it start the actual connection.

Here's the problem: that DNS query is in plaintext.

Traditional DNS uses UDP port 53 with zero encryption. Every domain you visit — github.com, youtube.com, coolboiledwater.cn — is visible to the coffee shop Wi-Fi admin, your ISP, and any intermediate network device. In some environments, a man-in-the-middle can even tamper with the DNS response and redirect you to a phishing site.

DoH (DNS over HTTPS) and DoT (DNS over TLS) were designed to fix exactly this. This article explains how they work, how they differ, and what you need to watch out for in day-to-day development.

• Understand the plaintext risk of traditional DNS — why "your ISP can see everything you browse" is not fearmongering
• Master how DoT and DoH each work — what they encrypt and how
• Know when to choose DoH vs. DoT, and why browsers picked DoH
• Understand DoH's unexpected impact on local development (/etc/hosts may be bypassed)

• Understand DNS basics (recursive resolver, authoritative server, A records)

• Understand TLS fundamentals (encryption handshake, certificate verification)

You're at a coffee shop, connected to the public Wi-Fi. You open your browser and type github.com. Your DNS query travels through the Wi-Fi router, the coffee shop's ISP, all the way to a recursive resolver:

The Wi-Fi admin can fire up Wireshark and see every domain you visit. In airports, hotels, and cafes, this is very real.

More dangerous is DNS hijacking: a man-in-the-middle intercepts your DNS query and returns a fake IP. You typed github.com, but your browser might open a pixel-perfect phishing page.

What DoH and DoT do is simple: wrap the DNS query in encryption. The admin can still see "you're talking to some IP," but they can't see what you're asking about.

Capture a normal DNS query packet:

The DNS query sits naked in the UDP datagram. Anyone who can capture packets can read it.

DoT's approach is straightforward — put a TLS layer around DNS. The DNS query is encapsulated inside a TLS connection, with the port changed from 53 to 853:

The connection setup is exactly like HTTPS:

After setup, what the IP layer sees:

An observer can only tell "you're talking to 1.1.1.1 on port 853," but not what domain you're querying.

DoH goes a step further — DNS queries are placed in the body of HTTP/2 or HTTP/1.1 requests, over the standard HTTPS port 443:

Put DoH and normal web browsing side by side:

An observer cannot tell whether you're browsing a website or making a DNS query. This is DoH's elegance — traffic analysis tools can't tell the difference.

An actual captured DoH packet:

Why did browsers pick DoH?

Because browsers don't want to hand their DNS requests to the operating system's DNS resolver — that means the system could intercept, log, or redirect them. DoH lets the browser directly make HTTPS requests to a DoH server (like https://1.1.1.1/dns-query), completely bypassing the OS and ISP DNS settings.

Why did Android pick DoT?

Android 9+ has a "Private DNS" feature — configure a DoT server address (like 1dot1dot1dot1.cloudflare-dns.com) in system settings, and all apps' DNS queries automatically go through the encrypted channel. DoT is a better fit for the OS level than DoH — no HTTP stack needed, just TCP + TLS.

If you use /etc/hosts during local development to point my-project.test to 127.0.0.1:

Normally, when the browser resolves my-project.test, it checks the hosts file first and gets 127.0.0.1.

But if you've enabled Chrome's DoH feature, the browser may bypass the system DNS and the hosts file entirely, sending the query directly to a DoH server (like https://dns.google/dns-query). The DoH server doesn't know about my-project.test, returns NXDOMAIN — and your local development domain fails to resolve.

Chrome's decision logic:

So if you use DoH in Chrome and also need local dev domains, make sure Chrome detects your "enterprise environment" or manually disable DoH:

Or in Firefox:

Browser (recommended, zero config):

• Chrome: chrome://settings/security → Secure DNS → Choose Cloudflare or Google
• Firefox: Settings → Network Settings → Enable DNS over HTTPS → Choose provider
• Edge: Same location as Chrome

Operating system:

• Android: Settings → Connections → More connection settings → Private DNS → Enter 1dot1dot1dot1.cloudflare-dns.com
• iOS: Install a DNS configuration profile (Cloudflare provides one)
• macOS: Install a profile or use a third-party tool
• Windows 11: Settings → Network → Wi-Fi → Hardware properties → DNS server assignment → Edit → IPv4 → Encrypted

Router (OpenWRT):

All devices on your home Wi-Fi automatically use DoH — no per-device configuration needed.

1. Check if your browser is using DoH

   Visit in your browser:

   https://1.1.1.1/help

   Check the Using DNS over HTTPS (DoH) line:

   txt

   Connected to 1.1.1.1: Yes Using DNS over HTTPS (DoH): Yes ← If Yes, DoH is enabled DNS over TLS (DoT): No

2. Capture plaintext DNS with tcpdump

   Disable DoH in your browser first, then capture:

   bash

   # Capture DNS traffic sudo tcpdump -i en0 'udp port 53' -n -X # Visit any domain you haven't visited before # Watch the capture output — you'll see the domain in plaintext in the X column

3. Compare packet capture with DoH enabled

   After enabling DoH, visit the same domain and observe:

   bash

   # DNS traffic (UDP 53) should show NO related queries sudo tcpdump -i en0 'udp port 53' -n # Only HTTPS traffic to the DoH server (TCP 443) sudo tcpdump -i en0 'tcp port 443' -n

1. Make a DoH query directly with curl

   bash

   # Use curl's built-in DoH support curl --doh-url https://1.1.1.1/dns-query https://github.com

2. Deploy DoH on your router

   If you have an OpenWRT router at home, deploy https-dns-proxy or AdGuard Home. All devices on your network will automatically get encrypted DNS — a one-time privacy upgrade for the entire household.

• Traditional DNS is plaintext — your ISP, the coffee shop Wi-Fi admin, and any man-in-the-middle can see every domain you visit.
• DoT establishes a TLS tunnel on TCP port 853, with DNS queries transmitted inside the tunnel. Observers only know which DNS server you're talking to.
• DoH disguises DNS queries as HTTPS requests (port 443). From the outside, it's indistinguishable from normal web browsing.
• DoH is implemented at the browser level, bypassing the OS DNS resolver, which can cause /etc/hosts and local dev domains to stop working.
• Recommended deployments: enable DoH/DoT on browsers and phones; deploy a DoH proxy on your router for whole-home encrypted DNS.

DoH DoT DNS over HTTPS DNS over TLS DNS encryption DNS privacy Private DNS /dns-query 1.1.1.1

DNS encryption solves the problem of "keeping queries private." But the answer DNS gives you — that IP address — once you have it, how do packets get correctly routed to their destination? If you're not yet familiar with routing and forwarding, that's the core of the network layer.

Continue reading:

Also, DoH relies on HTTPS (and thus on TLS). If you want to understand how the TLS encryption handshake works: