What is DNS over TLS (DoT) and how does it compare to DoH?

Sajjad
DNS
10 Oct, 2026

DNS over TLS (DoT) is a protocol that wraps ordinary DNS queries in a TLS-encrypted connection to your resolver, using its own dedicated port, TCP 853. It protects the privacy and integrity of your lookups in the same way as DNS over HTTPS (DoH), but the two differ in how they travel: DoT is a distinct, easily identifiable stream on port 853, while DoH hides DNS inside normal HTTPS traffic on port 443. In practice, DoT is easier for network administrators to see, manage and block, and DoH is harder to block and blends in with web traffic. Both encrypt the same thing, so the right choice depends mostly on who controls the network and the device.

Encrypted DNS has gone from a niche idea to a default in operating systems and browsers within a few years, and DoT and DoH are the two main options you'll come across. In this article you'll learn how DoT works under the hood, what it does and doesn't protect, how it compares to DoH and the newer DNS over QUIC, and how to configure DoT on Linux, Android and your own Unbound resolver, with commands you can use to test it.

Why Plain DNS Needs Encrypting

Traditional DNS sends queries and answers in plain text, usually over UDP port 53. Anyone on the path between your device and your resolver can read them, and in many cases modify them. That includes:

The local network: Anyone on the same public Wi-Fi, or a compromised router.
Your ISP: Which can log every domain you look up, or inject its own answers.
Transit networks: Any network the packets cross on the way to a remote resolver.

The domain names you look up reveal a lot: the banks you use, the health sites you visit, the software you run. Plain DNS also makes it easy to redirect users by forging answers, which is why many ISPs have historically replaced NXDOMAIN responses with advertising pages.

DNSSEC solves part of this problem by signing records so they can't be forged undetected, but it doesn't hide anything. Encrypted transports such as DoT and DoH solve the other half: confidentiality of the query between your device and the resolver.

How DNS over TLS Works

DoT was standardised in RFC 7858 in 2016. The idea is simple: take the existing DNS-over-TCP format, which has been part of DNS since the beginning, and run it inside a TLS session.

The Connection Step by Step

TCP connection: Your device (the stub resolver) opens a TCP connection to the resolver on port 853.
TLS handshake: The two sides negotiate a TLS session, normally TLS 1.3. The resolver presents a certificate, for example one valid for cloudflare-dns.com or dns.google.
Authentication: In strict mode, your device checks that the certificate is valid for the hostname it expects. This is what stops someone impersonating the resolver.
Queries: DNS messages are sent over the encrypted connection, each prefixed with a two-byte length field, exactly as in DNS over TCP.
Reuse: The connection stays open so later queries skip the handshake. Multiple queries can be in flight at once, and answers can arrive out of order.

Because setting up TCP and TLS costs a couple of round trips, connection reuse matters. A well-behaved DoT client keeps its connection alive and uses TLS session resumption, so the extra cost is paid once rather than on every lookup.

Strict and Opportunistic Privacy

RFC 8310 defines two usage profiles for DoT, and you'll see them reflected in client settings:

Strict privacy: The client must authenticate the resolver's certificate. If it can't connect securely, it fails rather than falling back to plain DNS. This protects against active attackers.
Opportunistic privacy: The client tries DoT, but if the connection or certificate check fails it falls back to unencrypted DNS. This protects against passive eavesdropping but not against someone who can block port 853 and force a downgrade.

Strict mode is the one to use when you care about privacy. Opportunistic mode is useful as a low-risk default on networks where you're not sure DoT will work.

How DoT Compares to DoH

DoH, standardised in RFC 8484, sends DNS messages as HTTP requests over HTTPS, normally to a URL such as https://dns.google/dns-query. Both protocols use TLS and offer the same level of encryption. The differences are about transport, visibility and where they're implemented.

Feature	DNS over TLS (DoT)	DNS over HTTPS (DoH)
Standard	RFC 7858	RFC 8484
Port	TCP 853	TCP 443 (or UDP 443 with HTTP/3)
Wire format	DNS over TCP inside TLS	DNS message in an HTTP request body or URL
Visible to network admins	Yes, distinct port	Blends in with other HTTPS traffic
Easy to block	Yes, block port 853	Harder, needs blocking specific resolver IPs or hostnames
Typical implementation	Operating system	Browsers and apps, increasingly OS too
Configured by	Hostname, such as `dns.quad9.net`	URL template, such as `https://dns.quad9.net/dns-query`
Overhead	Lower, no HTTP layer	Slightly higher, but benefits from HTTP/2 and HTTP/3

Visibility and Control

This is the biggest practical difference. Because DoT uses its own port, a network administrator can see that encrypted DNS is happening and decide what to do with it. A company can allow DoT only to its own resolvers, and a school can block it to keep its content filter effective.

DoH is deliberately indistinguishable from ordinary web traffic. That's good for users on hostile networks, such as in countries that censor DNS, because blocking DoH means blocking HTTPS to a whole IP address. It's frustrating for administrators, because an app with its own DoH resolver can quietly bypass the network's DNS policy.

Where Each Is Used

Android: The Private DNS setting, available since Android 9, uses DoT. You enter a hostname, such as dns.google or one.one.one.one, and Android connects to it on port 853.
Linux: systemd-resolved supports DoT natively. It doesn't support DoH.
Browsers: Chrome, Firefox, Edge and Safari implement DoH, often switching it on automatically when your system resolver is known to support it.
Apple platforms: iOS and macOS support both DoT and DoH through configuration profiles or apps using the system's encrypted DNS settings.
Windows 11: Has built-in DoH support in network settings for a list of known resolvers and custom templates.
Resolver software: Unbound, Knot Resolver, PowerDNS dnsdist and BIND 9.18 or later can serve DoT, and most can forward to upstreams over DoT.

Performance

In theory DoT is slightly lighter because it skips HTTP framing and headers. In practice the difference is small, and both are dominated by connection setup and the resolver's own speed. DoH can benefit from HTTP/2 multiplexing and from sharing a connection with other HTTPS traffic to the same provider. Either is fast enough that you won't notice once the connection is established.

What About DNS over QUIC?

DNS over QUIC (DoQ), standardised in RFC 9250, runs DNS directly over QUIC on UDP port 853. It offers the encryption of DoT with QUIC's faster connection setup and no head-of-line blocking. Support is growing in resolvers such as AdGuard DNS, NextDNS and dnsdist, but it's not yet as widely available in operating systems as DoT and DoH. It's worth keeping an eye on, especially for mobile networks where QUIC's connection migration helps.

What DoT Protects, and What It Doesn't

DoT is a transport protection. It's important to be clear about its limits.

What it protects:

The contents of your queries and answers between your device and the resolver.
The integrity of those answers in transit, so an on-path attacker can't forge them.
The resolver's identity, when used in strict mode with certificate validation.

What it doesn't protect:

The resolver itself: The resolver still sees every domain you look up. You're moving trust from your ISP to the resolver operator, so choose one with a privacy policy you're comfortable with.
Beyond the resolver: Queries from the resolver to authoritative nameservers are usually still unencrypted.
The destination: After the lookup, your device connects to the site's IP address, and the hostname often still appears in the TLS Server Name Indication (SNI) unless the site and browser use Encrypted Client Hello.
Record authenticity: DoT confirms the answer came from your resolver, not that the resolver got a genuine answer. DNSSEC validation at the resolver covers that.

How to Test DoT From the Command Line

Before configuring anything, it's useful to check that you can reach a DoT resolver and see what it looks like on the wire.

Using dig

BIND's dig supports DoT from version 9.18 onwards with the +tls option:

dig @1.1.1.1 +tls example.com A

The output looks like a normal query, but the server line shows the port and transport:

;; ANSWER SECTION:
example.com.		300	IN	A	203.0.113.10

;; Query time: 18 msec
;; SERVER: 1.1.1.1#853(1.1.1.1) (TLS)
;; WHEN: Tue Oct 20 09:12:41 BST 2026
;; MSG SIZE  rcvd: 56

For comparison, dig @1.1.1.1 +https example.com A sends the same query over DoH, and the server line shows (HTTPS) instead.

Using kdig With Certificate Validation

Knot DNS's kdig makes it easy to validate the resolver's certificate, which is what strict mode does:

kdig @1.1.1.1 +tls-ca +tls-hostname=cloudflare-dns.com example.com A

+tls-ca tells kdig to use the system's trusted certificate authorities, and +tls-hostname sets the name the certificate must match. If you deliberately use the wrong hostname, the connection fails, which is exactly what should happen when someone tries to impersonate a resolver.

Using openssl

To inspect the certificate a DoT server presents:

openssl s_client -connect 9.9.9.9:853 -servername dns.quad9.net </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

This prints the certificate's subject, issuer and validity dates, which is handy when debugging why a client refuses to connect.

How to Set Up DoT on Your Devices

Linux With systemd-resolved

Most modern Ubuntu, Fedora and Debian systems use systemd-resolved. Edit /etc/systemd/resolved.conf:

[Resolve]
DNS=1.1.1.1#cloudflare-dns.com 1.0.0.1#cloudflare-dns.com 2606:4700:4700::1111#cloudflare-dns.com
FallbackDNS=9.9.9.9#dns.quad9.net
DNSOverTLS=yes

The #hostname suffix tells resolved which name to check on the certificate. Setting DNSOverTLS=yes enables strict mode; opportunistic allows fallback to plain DNS. Restart the service and check the result:

sudo systemctl restart systemd-resolved
resolvectl status

Look for +DNSOverTLS in the protocols line. You can then confirm traffic is going to port 853 rather than 53:

sudo tcpdump -ni any 'port 53 or port 853'

While you run a few lookups, you should only see packets on port 853 to your configured resolvers.

Android Private DNS

On Android 9 or later:

Open Settings and go to Network & internet (the exact name varies by manufacturer).
Tap Private DNS.
Choose Private DNS provider hostname.
Enter a hostname such as dns.google, one.one.one.one or dns.quad9.net, then save.

The Automatic option is opportunistic: Android uses DoT if the network's resolver supports it and falls back otherwise. Entering a hostname makes it strict, so DNS fails if the resolver can't be reached over TLS.

Unbound as a DoT Forwarder

If you run Unbound on a home server or router, you can have it forward every query upstream over DoT, so the whole network gets encrypted DNS without configuring each device:

server:
    interface: 0.0.0.0
    interface: ::0
    access-control: 192.168.0.0/16 allow
    access-control: 127.0.0.0/8 allow
    tls-cert-bundle: /etc/ssl/certs/ca-certificates.crt

forward-zone:
    name: "."
    forward-tls-upstream: yes
    forward-addr: 1.1.1.1@853#cloudflare-dns.com
    forward-addr: 1.0.0.1@853#cloudflare-dns.com
    forward-addr: 9.9.9.9@853#dns.quad9.net

tls-cert-bundle points at your system's CA bundle so Unbound can validate certificates; the path shown is for Debian and Ubuntu. Check the config and restart:

sudo unbound-checkconf
sudo systemctl restart unbound

Unbound as a DoT Server

You can also make Unbound accept DoT from your own clients, which is useful for Android devices on your network or for a resolver you share with family. You need a certificate for a hostname you control, such as one from Let's Encrypt:

server:
    interface: 0.0.0.0@853
    interface: ::0@853
    tls-service-key: "/etc/unbound/tls/privkey.pem"
    tls-service-pem: "/etc/unbound/tls/fullchain.pem"
    tls-port: 853

Clients would then use dns.example.com as their Private DNS hostname. Remember to allow TCP 853 through your firewall, and restrict access-control so you don't run an open resolver for the whole internet.

Choosing Between DoT and DoH

There isn't a single right answer. Use this as a guide:

You manage the network (a business, school or home lab): Prefer DoT to your own resolver. It's easy to monitor, and you can block port 853 to outside resolvers so devices can't bypass your policy. Pair it with a policy for DoH in managed browsers.
You're on networks you don't trust: DoH is harder to block or interfere with, so it's the more reliable choice when travelling or on restrictive networks.
You want whole-device protection on Android: Private DNS (DoT) covers every app, not just the browser.
You run Linux servers: systemd-resolved with DoT is the simplest option and needs no extra software.
You want a single encrypted path for a whole household: Run a local resolver such as Unbound and forward upstream over DoT.

Many setups use both. A local resolver forwards upstream over DoT, while browsers are configured to use the local resolver rather than their own DoH provider, so all lookups follow one policy.

Discovering Encrypted Resolvers Automatically

Configuring hostnames by hand doesn't scale well. Discovery of Designated Resolvers (DDR), defined in RFC 9462, lets a client ask its normal resolver whether it offers encrypted transports. The client queries the special name _dns.resolver.arpa for SVCB records, which list DoT, DoH or DoQ endpoints:

dig @1.1.1.1 _dns.resolver.arpa SVCB +short

The answers describe the encrypted endpoints the resolver offers, along with the ALPN values (dot, h2, h3) and the hostname to validate. Windows 11 and Apple platforms use DDR to upgrade to encrypted DNS automatically when the configured resolver supports it.

FAQ: DNS over TLS

No. Both use TLS and give the same level of encryption and integrity. The difference is in transport: DoT uses its own port, which makes it easier to identify and block, while DoH hides inside normal HTTPS traffic.

DoT uses TCP port 853. DNS over QUIC uses UDP port 853, while DoH uses port 443 like any other HTTPS traffic.

It stops your ISP reading your DNS queries, but your ISP can still see the IP addresses you connect to, and often the hostname in the TLS handshake. Encrypted Client Hello and VPNs reduce that remaining exposure.

Some networks block TCP port 853, often to enforce their own content filtering. In strict mode Android won't fall back to plain DNS, so lookups fail. Switch Private DNS to Automatic on that network, or use a resolver reachable over DoH.

The first query pays for a TCP and TLS handshake, but clients keep the connection open and reuse it. After that, lookup times are close to plain DNS and are mostly determined by how fast the resolver itself is.

Yes. DoT protects the path between you and your resolver, while DNSSEC proves that records came from the domain's real authoritative servers. Use a resolver that validates DNSSEC to get both protections.

Yes. Blocking outbound TCP 853 to anything except your own resolver prevents devices from using outside DoT servers. Clients in opportunistic mode then fall back to your resolver, while strict clients will fail until reconfigured.

Conclusion

DNS over TLS encrypts your DNS lookups by running ordinary DNS inside a TLS session on port 853. It gives you the same confidentiality and integrity as DoH, but as a clearly identifiable stream that's simple to manage, which is why operating systems such as Android and Linux favour it, while browsers lean towards DoH.

If you control the network, DoT to a resolver you trust is usually the cleaner option. If you're on networks you don't control, DoH is harder to interfere with. Whichever you choose, use strict mode where you can, pick a resolver that validates DNSSEC, and test your setup with dig +tls or kdig to make sure your queries are really leaving your device encrypted.