What is DNS over HTTPS (DoH)?

9 November 2026

DNS over HTTPS, or DoH, sends domain name lookups inside an ordinary HTTPS connection to a resolver that supports it. Anyone on the path, such as a café network or your internet provider, can no longer read the names or tamper with the answers. The resolver that answers, however, still sees everything you ask.

The problem it solves

A classic DNS query is plain text sent to port 53, and every device on the path can read it. Whoever controls the network can also alter it, or reply with a forged answer before the real one arrives. What is DNS covers the basics of the system itself.

Encryption fixes two things: the privacy of the query on the path, and the integrity of the answer. It does not settle whether you can trust the resolver, which knows the names just as it did before.

How it works, step by step

1. The client is configured with the service address as a URI template, such as https://dnsserver.example.net/dns-query{?dns}.
2. The client builds a DNS message in the same binary format used on port 53.
3. It sends that message in an HTTPS request. With GET, the message is base64url-encoded and placed in the dns variable; with POST, it is the request body.
4. The server returns the answer as a DNS message with the content type application/dns-message, inside the same encrypted connection.

All of this is defined in RFC 8484, which recommends HTTP/2 as the minimum version. Here is a GET request taken from the standard, asking for the address of www.example.com:

:method = GET
:scheme = https
:authority = dnsserver.example.net
:path = /dns-query?dns=AAABAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB
accept = application/dns-message

The value after dns= is the query message itself, encoded, and it reads in this order:

• ID. The first two bytes are zero. The standard recommends ID 0 in every request, because HTTP already pairs each request with its response, and a varying ID would stop identical requests from being cached.
• Flags and counts. A flag asking for recursion, then the section counts: one question and nothing else.
• Name. Written as labels, each preceded by its length: 3 www 7 example 3 com.
• Type and class. Type A, an IPv4 address, and class IN, the internet.

Because the answer is an ordinary HTTP response, it can be cached. The standard requires that its freshness lifetime in an HTTP cache be no longer than the smallest TTL among the answer's records.

To try it in practice, curl can resolve a site's name over DoH instead of using the system resolver:

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

The DoH server's own name is resolved the normal way first, because the client needs its address before connecting to it. The site's name, though, is asked inside the HTTPS connection and never appears on port 53.

DoH, DoT and DoQ compared

The three encrypted protocols protect the content of the query to about the same degree. They differ in how easy they are to spot and block, and in which tools support each one.

What it does not hide

• The resolver that answers. It sees every name together with your address. Encryption moves trust from your network to the resolver's operator; it does not remove it.
• The destination address. Once it has the answer, your device connects to the site's address, which everyone on the path can see.
• The site name in the TLS handshake. The SNI field is sent in clear text, unless both the browser and the site use Encrypted Client Hello, defined in RFC 9849.
• Traffic size and timing. Encryption hides the content, not the number, size and timing of requests, which can sometimes be enough to guess the sites.
• Your address as sites see it. DoH does not change the address websites see; that is the job of a proxy or VPN.

When the resolver cannot be verified

RFC 8310 defines two usage profiles for DoT, and the same idea applies to DoH. In Strict Privacy, the connection must be encrypted and the server must prove its identity, or name resolution stops altogether. In Opportunistic Privacy, the client tries encryption and carries on without verification, or even in clear text, if it fails.

Some browsers offer the same choice under different names: one option falls back to the system resolver if the encrypted one fails, and one does not. The first keeps you connected; the second keeps your lookups private.

DoH with a VPN or a proxy

If you turn on DoH in the browser while on a full-device VPN, the encrypted query travels through the tunnel. It goes, however, to the resolver you picked in the browser, not to the tunnel's resolver.

This has a practical effect: some services pick the nearest content server based on where the asking resolver is. You may then get answers meant for a region other than your exit address. A leak test will also show a resolver you did not expect, which is not a leak in the sense explained in DNS leaks.

If you want answers to come from the tunnel's country, leave the browser on the system settings and let the tunnel choose the resolver.

How to turn it on and check it

• Chrome and Edge. Under Privacy and security there is a Use secure DNS option, with a list of providers or a field for a custom address.
• Firefox. Under Privacy & Security there is a DNS over HTTPS setting with several protection levels.
• Windows 11. When you edit the DNS server for a network adapter, an HTTPS encryption option appears for servers that support it.
• Linux. The systemd-resolved service supports DoT with DNSOverTLS=yes in /etc/systemd/resolved.conf.
• Android. The Private DNS option in the network settings is based mainly on DoT, and takes the resolver's hostname.

After turning it on, run a leak test. It should show the provider you chose, not your ISP's resolver.

Encrypted DNS with syriaproxy

In our apps and over WireGuard, name lookups travel encrypted inside the tunnel and are resolved in Syria by Syriatel's resolvers. You therefore do not need DoH in the browser to protect lookups on the path, because the tunnel already encrypts them.

FAQ

See which resolver answers for you with the free DNS leak test.