DNS over TLS (DoT) Explained — Encrypted DNS on Port 853

DNS over TLS — DoT, standardised in RFC 7858 — was the first widely-deployed encrypted DNS protocol, predating DNS over HTTPS by several years. It encrypts the client-to-resolver conversation using TLS over a dedicated port, and remains the default mechanism for Android's Private DNS and many Linux DNS stubs. This guide is a focused explainer of what DoT is, where it's deployed, and how it compares with the alternatives.

For DoH, see DNS over HTTPS (DoH) explained. For the integrity-vs-privacy comparison, see DNSSEC vs DNS over HTTPS.

What DoT Actually Is

DoT runs the standard DNS wire-format query inside a TLS connection on TCP port 853. The client opens a TLS handshake to the resolver's port 853, validates the resolver's certificate, and then sends DNS queries and receives responses over that encrypted connection.

The DNS wire format itself doesn't change. A DoT query is the same as a TCP/53 query — the only difference is the TLS wrapper. From the application's perspective, queries and responses look identical to plain DNS; from the network's perspective, all that's visible is encrypted traffic to port 853.

Connection lifetime: TLS handshakes are expensive, so DoT clients typically keep the TLS connection open and pipeline multiple queries through it (RFC 7858 explicitly recommends this). Idle timeouts are typically 30 seconds to several minutes.

What DoT Protects Against

The threat model is identical to DoH — network observers between client and resolver:

• ISP seeing every domain you visit
• Wi-Fi operators (coffee shop, hotel, airport) intercepting DNS
• On-path network-tap attackers
• Passive DNS surveillance at the network layer

In all of these cases, plain DNS exposes queries; DoT hides them inside TLS. An observer can see "this client is making encrypted connections to dns.google on port 853" but not "this client is looking up example.com".

What DoT Does NOT Protect

Like DoH, DoT does not change the relationship with the resolver itself. The resolver still sees and can log every query.

If privacy from the resolver also matters, the parallel privacy-preserving option is Oblivious DNS (ODNS, with ODoH for the HTTPS variant), which adds a relay layer. ODNS variants of DoT are less standardised than ODoH, so in practice ODoH (over HTTPS) is the more common path when relay-based privacy is needed.

DoT vs DoH

The cryptographic guarantees are equivalent. The differences are operational and political:

The political consequence: DoT is honest about being encrypted DNS — you can see it, you can route it, you can block it. DoH hides itself in HTTPS, which is great for users in censored networks but a headache for legitimate corporate DNS controls and parental-control systems.

DoT Is Not DNSSEC

The same caveat as DoH:

DoT prevents an observer from seeing the queries; DNSSEC prevents a tampered cache from poisoning the answers. They operate at different layers and modern stacks deploy both.

Public DoT Resolvers

The same resolvers that offer DoH also offer DoT:

When configuring DoT, you typically need both the hostname (for TLS certificate validation) and either the IP address or DNS-over-HTTPS bootstrap. Most modern OS configurations handle this automatically given the hostname.

OS and Client Support

Android

Settings → Network & internet → Private DNS → Private DNS provider hostname. Android's Private DNS uses DoT exclusively at the system level. Set a hostname (e.g., dns.google, 1dot1dot1dot1.cloudflare-dns.com, dns.quad9.net) and Android will use DoT for all system DNS.

Android 9+ supports this; Android 10+ added stricter validation. App-level DoH is supported in some apps (Firefox, etc.) but the system-level mechanism is DoT.

iOS / macOS

Encrypted DNS profiles via configuration profiles (.mobileconfig files) since iOS 14 and macOS Big Sur. These profiles can specify either DoT or DoH. App-level encrypted DNS is also possible.

Linux

systemd-resolved supports DoT via DNSOverTLS=yes in /etc/systemd/resolved.conf (since systemd 239). Standalone stubs:

• stubby — a focused DoT stub resolver, runs on 127.0.0.1:53 and forwards via DoT
• unbound — full recursive resolver with DoT-forwarding capability
• knot-resolver — full recursive resolver with DoT support

Configure /etc/resolv.conf to point at the local DoT stub.

Windows

Windows 11 added native DoT support (and DoH); Windows 10 did not. Configuration is via Settings → Network & Internet → properties of an active connection → DNS server assignment → Manual DNS settings → choose DoT/DoH for each address.

Routers / network-level

OpenWrt with unbound or dnsmasq can be configured for DoT-forwarded recursion. Many newer commercial routers also expose encrypted DNS as a setting.

ADoT — Encrypting the Other Half

The current default deployment looks like this:

[ Client ] ── DoT/DoH ── [ Recursive resolver ] ── plain DNS ── [ Authoritative ]

The first half (client to resolver) is increasingly encrypted; the second half (resolver to authoritative) is mostly still plain UDP/53 or TCP/53. ADoT — Authoritative DNS over TLS — is the proposal to encrypt the second half too.

ADoT is being trialled by:

• Cloudflare — published their 1.1.1.1 resolver supporting ADoT to authoritative servers that opt in
• Google Public DNS — limited ADoT support announced
• DPRIVE working group at IETF — actively standardising the resolver-to-authoritative profile

Most authoritative servers in 2026, including DNScale's, do not yet expose DoT. The arguments for and against are non-trivial:

For ADoT:

• Closes the last unencrypted link in the DNS chain
• Prevents passive surveillance at the resolver-to-authoritative layer
• Aligns with the broader trend of universal transport encryption

Against (or "complications"):

• TLS handshake adds latency to every cache miss
• Authoritative servers handle massively higher query volumes than resolvers; the TLS state cost is real
• Coordination problem: every authoritative server has to opt in independently
• DNSSEC already provides integrity; ADoT is largely about privacy/metadata

The likely 2026–2028 trajectory: ADoT becomes a feature that high-end authoritative providers offer (alongside HTTPS-based equivalents), but plain DNS at the recursive-to-authoritative layer remains the default for the foreseeable future.

Why Authoritative DNScale Doesn't Yet Run DoT

DNScale, like most authoritative providers, currently focuses on the integrity/security layer at the authoritative side:

• DNSSEC for record integrity (default for new zones)
• TSIG for zone-transfer authentication
• Anycast for resilience and DDoS dilution

When ADoT becomes a stable, widely-deployed standard, expect DNScale and peer providers to add it. In the meantime, the resolver-to-authoritative privacy story is mostly handled by aggregating queries through public resolvers — your authoritative server sees a query coming from 1.1.1.1, not from the original client IP.

Testing DoT

From a Linux/macOS terminal:

# kdig (Knot's dig variant) supports DoT natively
kdig @1.1.1.1 +tls example.com
 
# stubby running locally — query localhost on port 53, stubby forwards via DoT
dig @127.0.0.1 example.com
 
# openssl s_client to confirm a DoT endpoint is healthy
openssl s_client -connect 1.1.1.1:853 -servername cloudflare-dns.com </dev/null
 
# Verify the TLS certificate
echo | openssl s_client -connect dns.google:853 -servername dns.google 2>/dev/null \
  | openssl x509 -noout -subject -issuer

For Android: Settings → Network & internet → Private DNS → enter a hostname like dns.google, then visit https://1.1.1.1/help to confirm. (Note: that page detects Cloudflare's resolver specifically; for Google or Quad9 use their respective verification endpoints.)

Operational Considerations

DoT is friendly to network operators who want visibility:

• Easy to identify on the wire (port 853)
• Easy to allow or block at the firewall level
• Doesn't bypass network-level DNS controls unless explicitly configured to (clients still typically use the configured resolver, just over DoT)

This makes DoT a better fit than DoH for many corporate environments. The trade-off is the same one users see: DoT's identifiability also means it's easier to suppress in censored networks.

Related Reading

• DNS over HTTPS (DoH) explained — the close cousin of DoT
• DNSSEC vs DNS over HTTPS — integrity vs privacy
• What is DNSSEC? — the integrity layer
• How DNSSEC works — KSK/ZSK/DS mechanics
• DNS cache poisoning — the attack DNSSEC and DoT/DoH together help mitigate
• DNS attacks and threats — the broader threat landscape

References

• RFC 7858 — Specification for DNS over Transport Layer Security (TLS)
• RFC 8094 — DNS over Datagram Transport Layer Security (DTLS)
• RFC 8484 — DNS Queries over HTTPS (DoH)
• RFC 9103 — DNS Zone Transfer over TLS
• IETF DPRIVE Working Group — DNS PRIVate Exchange (ongoing ADoT work)
• Cloudflare: 1.1.1.1 DoT documentation
• Android Open Source Project: Private DNS implementation notes