top of page

What is DNS over TLS?

Oct 6
7 min read

Updated: 3 days ago

What is DNS over TLS?

DNS over TLS (DoT) is a standard for encrypting DNS queries and responses between a client and a recursive DNS resolver using Transport Layer Security (TLS). Instead of sending conventional DNS queries in clear text over port 53, DoT normally establishes a TCP connection to dedicated port 853 and protects the DNS messages inside TLS. The key distinction is that DoT protects the DNS transport between you and the resolver; it does not encrypt every connection you make on the internet.

That matters because a normal DNS lookup can reveal the domain names a device is trying to resolve before the application makes its separate connection to the destination. Encrypting the client-to-resolver leg makes straightforward passive inspection and alteration of those DNS messages much harder, but the resolver itself still receives the queries and therefore remains an important trust decision.

How does DNS over TLS work?

The protocol defined by RFC 7858 keeps the DNS message format intact and changes how those messages are transported. The client first connects to a DoT-capable resolver, normally using TCP port 853. A TLS handshake then establishes the protected session. Once that succeeds, DNS queries and responses travel through that encrypted connection.

  1. The device needs to resolve a name such as example.com.

  2. The DoT client opens a TCP connection to the configured recursive resolver, normally on port 853.

  3. The client and resolver perform a TLS handshake. In a strict authenticated configuration, the client verifies that it is talking to the intended resolver.

  4. The client sends ordinary DNS messages through the encrypted TLS session.

  5. The recursive resolver answers from cache or performs the necessary DNS resolution and returns the response through the same protected session.

  6. The device then uses the returned DNS data to make the separate application connection to the destination service.

This is separate from the later web connection. If the destination is a secure website, HTTPS protects the HTTP connection to that website, while DoT protects the DNS exchange with the DNS resolver.

The infographic below shows the important boundary: DoT encrypts the client-to-resolver DNS link, not the whole path to every internet service.

Techie Broadband infographic explaining DNS over TLS, encrypted DNS queries, port 853, DoT benefits, DoT vs DoH and practical limitations

What does DNS over TLS protect?

DoT is primarily a transport-privacy mechanism. It prevents an observer on the client-to-resolver network path from simply reading the DNS payload and, when the resolver is properly authenticated, helps protect that exchange against active on-path interference.

  • Confidentiality of DNS queries and responses while they travel between the DoT client and resolver.

  • Integrity protection for the TLS-protected exchange, making undetected modification on that protected leg substantially harder.

  • Resolver authentication when the client uses a strict authenticated privacy profile and correctly validates the intended service.

  • Connection reuse, allowing multiple DNS messages to travel over an established TLS session rather than requiring a new TLS handshake for every lookup.

What DNS over TLS does not protect

Encrypted DNS is useful, but it is easy to overstate what it hides. The recursive resolver still needs to see the DNS query in order to answer it, so using DoT changes who can observe the query rather than making the query invisible to everyone.

  • The chosen recursive resolver can still see the DNS names you ask it to resolve.

  • Destination IP addresses used by later connections remain visible to networks carrying those connections.

  • Traffic timing, sizes and other metadata can still reveal information even when the DNS payload is encrypted.

  • DoT does not encrypt ordinary web, email, gaming or other application traffic. Those protocols need their own protection.

  • DoT does not make a malicious domain safe and does not prove that DNS data itself was cryptographically signed by the domain owner.

A VPN operates at a different layer: it creates an encrypted tunnel between your device and a VPN endpoint for traffic routed through that tunnel. DoT is narrower and protects DNS transport to the configured resolver.

DNS over TLS vs DNS over HTTPS

DoT and DNS over HTTPS (DoH) both encrypt DNS between a client and a resolver, but they use different transports. DoT uses TLS directly for DNS and has a dedicated default port, 853. DoH carries DNS messages inside HTTPS and commonly uses port 443.

  • DoT: DNS directly over TLS, normally TCP port 853.

  • DoH: DNS carried as HTTPS traffic, commonly over port 443.

  • Both: protect the DNS exchange on the client-to-resolver leg when correctly configured.

  • Operational difference: DoT is easier for a network to identify by its dedicated port, while DoH can resemble other HTTPS traffic.

  • Privacy difference: the resolver still receives the DNS query in both cases; resolver policy and logging remain relevant.

DNS over TLS vs DNSSEC

DoT and DNSSEC solve different problems. DoT encrypts the transport between the DNS client and resolver. DNSSEC is designed to let validating resolvers check cryptographic signatures on DNS data so they can detect forged or altered signed records. DNSSEC does not provide confidentiality for DNS queries.

They can therefore complement each other: DoT can protect the client-to-resolver transport while DNSSEC validation can provide assurance about signed DNS data. Neither should be described as a substitute for the other.

Why does DNS over TLS normally use port 853?

RFC 7858 specifies TCP port 853 as the well-known default for DNS over TLS. Keeping encrypted DNS on a dedicated port avoids mixing clear-text and TLS-protected DNS on port 53 and reduces ambiguity about whether the connection is expected to be encrypted.

Other ports can be used when the client and server have an explicit agreement, but port 53 must not be used as the alternative DoT port described by RFC 7858. A DoT service must not accept clear-text DNS on a port being used for DoT.

Does DNS over TLS work with IPv4 and IPv6?

Yes. The transport connection to the resolver can run over IPv4 or IPv6 depending on the network and configuration, and the DNS messages carried inside DoT can request many record types. That includes IPv4 A records, IPv6 AAAA records, MX records, TXT records and other DNS data.

Does DNS over TLS make broadband faster?

Not inherently. DoT adds TCP and TLS session establishment, although implementations can reuse connections and TLS sessions to reduce repeated setup cost. DNS response time is only one small part of many internet interactions, and a faster or better-connected resolver can matter more than whether the DNS transport is encrypted.

For UK FTTP, FTTC, cable, fixed wireless and mobile broadband, the security function of DoT is the same. Real-world lookup performance can still be affected by latency to the resolver, packet loss, resolver load, caching, routing and whether the network blocks or interferes with port 853.

Techie Broadband analysis: where the privacy boundary actually moves

A useful way to think about DoT is not 'DNS becomes private', but 'the clear-text observation point is removed from one part of the path'. With traditional unencrypted DNS, a party able to observe the client-to-resolver link can inspect DNS queries directly. With correctly authenticated DoT, that payload is encrypted on that link.

Visibility is not eliminated. The recursive resolver receives the clear DNS question after TLS processing because it must resolve it. The resolver may then communicate with authoritative DNS infrastructure as part of normal resolution, and the later application connection has its own metadata and security properties. The privacy decision therefore shifts towards which resolver you trust, how it handles logs, and where that resolver sits in relation to your network.

What can go wrong with DNS over TLS?

If DoT is enabled and name resolution stops working, the fault is not necessarily with DNS itself. The encrypted transport adds a TCP/TLS connection and a specific resolver configuration that can fail independently.

  1. Confirm that the configured resolver actually supports DNS over TLS.

  2. Check that the resolver hostname or configured identity is correct. Strict modes need to authenticate the intended service.

  3. Test whether TCP port 853 is reachable from the current network. Some networks may block it.

  4. Check the device date and time because incorrect clocks can break certificate validation.

  5. Compare behaviour using the network's normal DNS service to separate a DoT transport problem from a wider connectivity problem.

  6. Try another known DoT-capable resolver only as a diagnostic step, remembering that changing resolver also changes who can observe your DNS queries.

  7. Check router, firewall, parental-control, enterprise-security or VPN settings that may deliberately control DNS traffic.

  8. After restoring DNS, test the actual application connection separately; successful name resolution does not prove that the destination service itself is reachable.

Should you use DNS over TLS on a UK broadband connection?

DoT is a sensible option when you want to prevent straightforward observation of DNS payloads on the path between your device and a resolver you have deliberately chosen and trust. It is particularly useful when the operating system or router can apply the setting consistently across applications.

It is not automatically a privacy upgrade in every context. Moving from an ISP resolver to a large public resolver can move DNS visibility to a different organisation. The resolver's privacy policy, logging, jurisdiction, reliability and filtering behaviour remain part of the decision. Networks that intentionally provide local DNS names, security filtering or parental controls may also behave differently when a device bypasses their resolver.

Authoritative technical references

RFC 7858 — Specification for DNS over Transport Layer Security (TLS) defines DNS over TLS, including the default use of TCP port 853 and TLS session behaviour.

RFC 9076 — DNS Privacy Considerations explains the privacy limits of encrypted DNS, resolver trust, metadata and the remaining observation points.

Frequently asked questions

Is DNS over TLS the same as TLS?

No. TLS is the general security protocol. DNS over TLS is a specific use of TLS to protect DNS messages between a client and resolver.

Does DNS over TLS use port 853?

Port 853 is the well-known default specified by RFC 7858. Another port can be used by explicit agreement, but the RFC says that alternative must not be port 53.

Can my ISP see DNS queries when I use DoT?

If the ISP is only observing the path between your device and an external DoT resolver, it cannot simply read the encrypted DNS payload. If the ISP operates the DoT resolver you use, that resolver still receives the DNS queries. Other traffic metadata and destination IP addresses may also remain visible.

Is DNS over TLS better than DNS over HTTPS?

Neither is universally better. Both can protect DNS transport to a resolver. DoT uses a dedicated TLS transport and default port 853, while DoH uses HTTPS and commonly port 443. The best choice depends on the device, network policy, resolver and operational requirements.

Does DNS over TLS replace a VPN?

No. DoT encrypts DNS transport to the resolver. A VPN can encrypt a much broader set of traffic between the device and VPN endpoint. They protect different parts of the network path.

Key takeaway

DNS over TLS encrypts DNS queries and responses between a client and recursive resolver using TLS, normally over TCP port 853. It can stop straightforward passive inspection of DNS payloads on that leg and, with strict authentication, protect against on-path interference. It does not hide DNS queries from the resolver, encrypt every internet connection or replace DNSSEC, HTTPS or a VPN. The practical privacy question is therefore not only whether DNS is encrypted, but which resolver receives it and what happens to the data there.

To explore the related technical concepts used in this DNS over TLS guide, visit our broadband terminology guide.

 
 
UK Techie Broadband Providers
bottom of page