What Is DNS over HTTPS (DoH)?

Classic DNS was designed in the 1980s with no encryption at all. Every lookup your device makes — every website, every app's API endpoint, every tracker — crosses the network as plain text on port 53, readable by anyone on the same Wi-Fi, your ISP, and anything in between. It can also be quietly modified in transit. DNS over HTTPS (DoH) fixes the transport part of that problem by wrapping DNS queries inside ordinary encrypted HTTPS traffic. It's now built into every major browser and into Windows, macOS, iOS, and Android, so there's a good chance you're already using it.

This article explains how DoH works at the protocol level, how to send DoH queries yourself with curl, dig, and Python, how to turn it on in browsers and operating systems, and the trade-offs — including why network administrators often have mixed feelings about it. If you're comparing it with its sibling protocol, the post on DNS over TLS and how it differs from DoH covers that side.

What DoH Protects (and What It Doesn't)

To understand DoH, it helps to separate the two hops in a DNS lookup. Your device sends a query to a recursive resolver, which then contacts root, TLD, and authoritative servers to find the answer. DoH encrypts only the first hop — between your device and the resolver.

That gives you three concrete protections:

1. Confidentiality on the local network. People on the same café Wi-Fi, your ISP, and other on-path observers can no longer read which names you're looking up.
2. Integrity in transit. Because TLS authenticates the resolver and protects the data, an on-path attacker can't inject forged answers into that connection. This shuts down a whole class of last-mile spoofing attacks.
3. Resistance to interception. Networks that silently redirect port 53 traffic to their own resolver can't do the same to HTTPS without breaking TLS.

What DoH does not do:

• It doesn't hide your queries from the resolver. The DoH provider decrypts and sees every lookup. You're moving trust from your network to the resolver operator, so their privacy policy matters.
• It doesn't encrypt resolver-to-authoritative traffic. That second hop is still mostly plain DNS.
• It doesn't hide which sites you visit. After the lookup, your browser connects to the site's IP address, and the TLS handshake usually reveals the hostname through SNI unless Encrypted Client Hello (ECH) is in use.
• It doesn't prove the answer is authentic at the source. That's what DNSSEC is for; DoH and DNSSEC solve different problems and work well together.

How DoH Works Under the Hood

DoH is defined in RFC 8484. The idea is simple: take a normal DNS message in its standard binary wire format, and send it as the body of an HTTPS request to a URL on the resolver, conventionally ending in /dns-query. The response body is a binary DNS response. The media type for both is application/dns-message.

There are two ways to send the query:

• POST, with the raw DNS message as the request body.
• GET, with the DNS message encoded as unpadded base64url in a dns query parameter, for example https://cloudflare-dns.com/dns-query?dns=AAABAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB.

GET requests are cache-friendly — HTTP caches can store responses — which is why RFC 8484 recommends setting the DNS message ID to 0 for DoH, so identical queries produce identical URLs.

Because it all runs over HTTPS on port 443, DoH benefits from everything modern HTTP offers: HTTP/2 and HTTP/3 multiplexing many queries over a single connection, connection reuse, and TLS 1.3. It also means DoH traffic looks like any other web traffic, which is both its main privacy advantage and the main reason it frustrates network operators.

The JSON API (not part of the standard)

Several resolvers also offer a simpler JSON interface. It isn't part of RFC 8484, but it's handy for scripts and debugging. Cloudflare and Google both support it:

# Cloudflare: JSON format selected with the Accept header
curl -s -H "accept: application/dns-json" \
  "https://cloudflare-dns.com/dns-query?name=example.com&type=A"

# Google Public DNS: dedicated JSON endpoint
curl -s "https://dns.google/resolve?name=example.com&type=A"

Both return a JSON object with the response code, flags, and records:

{
  "Status": 0,
  "TC": false,
  "RD": true,
  "RA": true,
  "AD": true,
  "CD": false,
  "Question": [{ "name": "example.com", "type": 1 }],
  "Answer": [
    { "name": "example.com", "type": 1, "TTL": 300, "data": "203.0.113.10" }
  ]
}

Status: 0 means NOERROR (3 would be NXDOMAIN), type: 1 is an A record, and AD: true means the resolver validated the answer with DNSSEC.

Sending DoH Queries Yourself

With dig

BIND's dig gained native DoH support in version 9.18:

dig @1.1.1.1 +https example.com A
dig @dns.google +https example.com AAAA

The +https flag sends the query as an RFC 8484 POST to /dns-query on the server. The SERVER line at the bottom of the output shows (HTTPS) to confirm the transport. Use +https-get to send a GET request instead.

With curl

curl can resolve the hostname of the URL you're fetching through DoH, rather than the system resolver:

curl --doh-url https://cloudflare-dns.com/dns-query https://example.com/ -I

This is useful for testing whether a site behaves differently when resolved through a specific DoH provider.

With Python

You can build a wire-format DoH request yourself to see exactly what's on the wire. This example uses dnspython to build and parse messages and the standard library to send the request:

import base64
import urllib.request

import dns.message

query = dns.message.make_query("example.com", "A")
query.id = 0  # RFC 8484 recommends ID 0 for cacheable GET requests
wire = query.to_wire()
encoded = base64.urlsafe_b64encode(wire).rstrip(b"=").decode()

request = urllib.request.Request(
    f"https://cloudflare-dns.com/dns-query?dns={encoded}",
    headers={"accept": "application/dns-message"},
)
with urllib.request.urlopen(request, timeout=5) as resp:
    print("Content-Type:", resp.headers["content-type"])
    answer = dns.message.from_wire(resp.read())

for rrset in answer.answer:
    print(rrset.to_text())

The script builds a binary DNS query, base64url-encodes it without padding as RFC 8484 requires, sends it as a GET request, and decodes the binary response back into DNS records. dnspython can also do this in one call with dns.query.https() if you install its optional HTTP dependencies with pip install "dnspython[doh]".

Turning On DoH in Browsers and Operating Systems

Browsers

• Firefox: Settings → Privacy & Security → DNS over HTTPS. Firefox offers levels ranging from default protection (which uses DoH when available and falls back to normal DNS) up to max protection (DoH only, no fallback). You can choose a provider or enter a custom URL. Firefox has enabled DoH by default for users in several countries.
• Chrome: Settings → Privacy and security → Security → Use secure DNS. By default, Chrome upgrades to DoH automatically if your system's configured resolver is a known DoH-capable provider, keeping the same provider rather than switching you to a different one. You can also pick a provider explicitly.
• Edge: Settings → Privacy, search, and services → Security → Use secure DNS, which works the same way as Chrome.

Operating systems

• Windows 11 supports DoH natively. In Settings → Network & internet → your connection → DNS server assignment → Edit, set a resolver and choose the DNS over HTTPS option. From PowerShell, you can see which resolvers Windows knows DoH templates for:

Get-DnsClientDohServerAddress

• macOS and iOS support DoH through configuration profiles (.mobileconfig files), which many resolver providers publish for download, or through apps that install a DNS settings extension.
• Android offers Private DNS, which uses DNS over TLS rather than DoH; browsers on Android can still use DoH independently.

For general instructions on changing which resolver your devices use, see how to change DNS settings on Windows, Mac, iPhone, and Android. Picking a provider is a separate decision covered in Cloudflare DNS vs Google Public DNS vs Quad9.

Automatic Discovery: DDR and the Canary Domain

Two mechanisms help clients decide when to use DoH without manual configuration:

• Discovery of Designated Resolvers (DDR), defined in RFC 9462, lets a client ask its normal resolver whether it also offers an encrypted endpoint. The client queries the special name _dns.resolver.arpa for SVCB records, which list the resolver's DoH or DoT endpoints. You can check what your resolver advertises:

dig _dns.resolver.arpa SVCB

If your resolver supports DDR, the response lists records with alpn values such as h2 or h3 (DoH) or dot, plus a dohpath parameter with the URL template. These use the same record format described in HTTPS and SVCB records.

• The Firefox canary domain, use-application-dns.net, lets a network signal that Firefox shouldn't automatically enable DoH. If the network's resolver returns NXDOMAIN for that name, Firefox's default mode stays on the network's resolver. It's honored only for automatic enablement — users who turn DoH on explicitly keep it.

The Trade-offs for Networks and Organizations

DoH is a clear win for individuals on untrusted networks, but it changes the picture for anyone who relies on DNS for network control:

• DNS-based filtering is bypassed. Parental controls, malware blocking, and corporate policies implemented through DNS filtering stop working if a browser sends its queries to an outside DoH provider instead.
• Split-horizon and internal names can break. Internal hostnames that only exist on the company resolver won't resolve through a public DoH provider. Most browsers detect enterprise-managed devices and back off, but it's a common source of support tickets.
• Visibility for security teams drops. DNS logs are one of the best data sources for spotting malware. Encrypted DNS to an outside provider removes that signal.

The practical answer for organizations is usually not to block DoH outright but to run or choose a filtering resolver that itself supports DoH, then enforce it through device management policies (Chrome, Edge, and Firefox all support enterprise policies for secure DNS). That keeps queries encrypted and keeps policy enforcement in place.

---

DNS over HTTPS FAQ

Conclusion

DNS over HTTPS takes the oldest unencrypted protocol most people still use every day and moves it inside the same encrypted channel as the rest of the web. For the hop between your device and your resolver, it delivers real confidentiality and integrity, defeats on-path snooping and tampering, and does it with no extra effort once enabled — which is why every major browser and operating system now supports it.

Its limits are just as important to understand. DoH shifts trust to the resolver you pick, doesn't hide the sites you ultimately connect to, and doesn't authenticate the data itself. For individuals, choosing a trustworthy DoH provider is an easy privacy upgrade. For organizations, the right move is to offer encrypted DNS through a resolver you control or trust, so you get DoH's protections without losing filtering and visibility.

These references go deeper on DoH and related standards:

1. RFC 8484: DNS Queries over HTTPS (DoH) — the specification defining the protocol, media type, and GET and POST formats.
2. RFC 9462: Discovery of Designated Resolvers — how clients discover a resolver's encrypted endpoints via _dns.resolver.arpa.
3. Cloudflare Developers: DNS over HTTPS — Cloudflare's documentation for its DoH endpoints, including the JSON format.
4. Google Public DNS: DNS-over-HTTPS (DoH) — Google's DoH documentation and JSON API reference.
5. Mozilla Support: Firefox DNS over HTTPS — how Firefox's DoH modes, providers, and canary domain work.