• Glossary
  • What is DoT (DNS over Transport Layer Security)?

DNS glossary

What is DoT (DNS over Transport Layer Security)?

DNS over TLS (DoT) is a network protocol that encrypts DNS traffic between a client and a DNS resolver using Transport Layer Security. It carries standard DNS messages inside a TLS session over TCP, on port 853 by default, as defined in RFC 7858, which stops on-path observers from reading or altering queries.

Let's simplify your DDI
Abstract isometric UI showing network ranges, usage bars, region names (EMEA/APAC), and a purple "Deploy" button
Key takeawaysKey takeaways are generated with AI assistance. Because automated summaries can occasionally contain errors or miss important context, always refer to the full blog post for complete information.

DNS over Transport Layer Security (DoT) is a network protocol that encrypts DNS traffic between clients and resolvers using TLS on TCP port 853, as defined in RFC 7858, preventing on-path observers from reading or modifying queries. While DoT protects the client-to-resolver hop by wrapping standard DNS messages in encrypted TLS sessions, it does not protect the resolver's subsequent lookups to authoritative servers and does not validate DNS answers—functions handled separately by DNSSEC. For enterprise environments managing guest networks, branch offices, and remote workers, DoT offers operational advantages over DNS over HTTPS (DoH) through its dedicated port and easier firewall control, though successful deployment requires careful certificate management, clear resolver policies, and proper handling of strict versus opportunistic mode configurations to avoid silent fallbacks to unencrypted queries.

  • DoT operates on TCP port 853 with a dedicated channel, allowing network administrators to identify, monitor, and enforce DNS encryption policies through simple firewall rules, unlike DoH which blends with standard HTTPS traffic on port 443.
  • Certificate validation in strict mode requires resolver certificates to match configured names and chain to trusted CAs, with expired certificates or missing intermediates causing resolution outages—demanding proactive monitoring and expiry management.
  • Opportunistic mode clients that fail TLS handshakes may silently fall back to plaintext DNS queries without user awareness, potentially bypassing internal DNS filtering, logging, and split-horizon answers for internal zones.

DNS over TLS at a glance

AttributeValue
Full nameDNS over Transport Layer Security
CategoryNetwork protocol
Defined inRFC 7858, with usage profiles in RFC 8310
Protocol and portTCP port 853
OSI layerApplication layer, carried over TLS and TCP
Primary useEncrypting DNS queries and responses between a client and a recursive resolver
Related termsDNS over HTTPS, DNS over QUIC, DNS resolver, Transport Layer Security, DNSSEC

How DNS over TLS works

DoT sends ordinary DNS messages through an encrypted TLS session instead of in clear text. The DNS message format does not change; only the transport does.

  1. Open a TCP connection: The client connects to the resolver on TCP port 853, the port reserved for DoT in RFC 7858.
  2. Complete the TLS handshake: The client and resolver negotiate TLS parameters and the resolver presents a certificate. Depending on the usage profile in RFC 8310, the client either verifies the resolver's identity (strict) or accepts an unauthenticated session (opportunistic).
  3. Send the query: The client sends a standard DNS message through the encrypted session, prefixed with a two-byte length field as in DNS over TCP.
  4. Receive the response: The resolver returns the DNS response through the same session. An observer on the path sees only encrypted traffic.
  5. Reuse or close the session: The client can keep the connection open and send further queries over it, which avoids repeating the handshake for each lookup.

DoT protects only the hop between the client and the resolver. The resolver's own lookups to authoritative servers are a separate path and are not covered by DoT. DoT also does not validate answers; that is the role of DNSSEC.

Why DNS over TLS matters in enterprise networks

Traditional DNS queries travel in clear text, so anyone on the network path can see which names a device looks up and can alter responses. DoT closes that gap on the client to resolver hop. For enterprises, this matters on guest Wi-Fi, branch links and remote worker connections, where the path is not under direct control.

DoT is often compared with DNS over HTTPS (DoH), defined in RFC 8484. Both encrypt the same traffic. The main operational difference is that DoT uses its own port, 853, while DoH shares port 443 with ordinary web traffic. A dedicated port lets network teams identify, monitor, route or block DoT with simple rules. DoH is harder to separate from web traffic, which can bypass enterprise DNS policy if clients choose their own resolver.

Poor management creates problems in both directions. If DoT is blocked at the firewall without a plan, clients configured for strict mode fail to resolve names. If clients send encrypted queries to external resolvers, internal zones stop resolving and DNS-based security filtering and logging are bypassed. Resolvers need valid certificates, monitored expiry and a clear policy on which clients may use which resolvers.

DNS over TLS vs DNS over HTTPS (DoH)

DoT wraps DNS messages directly in TLS on a dedicated port, while DoH carries them as HTTP exchanges inside TLS, which lets DoH traffic blend with ordinary web traffic. What is DNS over HTTPS?

AttributeDNS over TLSDNS over HTTPS (DoH)
StandardRFC 7858RFC 8484
Default portTCP 853TCP 443
Transport layerTLS directly over TCPHTTP inside TLS
Visibility to network teamsEasy to identify, filter or allow by portHard to separate from other HTTPS traffic
Typical enforcementAllow or block port 853 at the firewallNeeds resolver address lists or application-level controls
Protocol overheadLower, with no HTTP framingHigher, because of HTTP headers and framing

Common DNS over TLS issues

Many firewalls and guest networks drop outbound TCP 853, so DoT queries time out. In strict mode the client may then fail to resolve names, and in opportunistic mode it may silently fall back to clear text.

In strict mode the resolver certificate must match the configured name and chain to a trusted CA. An expired certificate, a missing intermediate or an internal CA not trusted by clients causes handshake errors and resolution outages.

Opportunistic clients that cannot complete a TLS session may send queries unencrypted without warning. Users believe DNS is protected while on-path observers can still read it.

Encrypted queries sent to an external resolver bypass internal DNS filtering, logging and split-horizon answers. Internal names return NXDOMAIN or policy controls are skipped until clients are pointed at an approved DoT resolver.

Resolvers that terminate DoT must keep many long-lived TCP and TLS sessions open. Undersized connection limits or idle timeouts cause resets and added latency during query bursts.

See how unified DDI simplifies network operations

Manage DNS, DHCP and IP addresses from one platform with automation, visibility and control built in.

Talk to us

DNS over TLS FAQ

Related terms

Article

DNS over HTTPS (DoH)

DNS over HTTPS (DoH) encrypts DNS queries and responses by transmitting them over HTTPS, protecting DNS traffic from interception and monitoring.

Learn more
Article

Transport layer security (TLS)

TLS (transport layer security) is a cryptographic protocol that provides communications security over a computer network.

Learn more
Article

DNS – Domain Name System

The Domain Name System (DNS) is a hierarchical naming system that resolves domain names to IP addresses, enabling communication across network devices.

Learn more
Article

DNSSEC (Domain Name Service Security Extension)

DNSSEC (Domain Name Service Security Extension) is a mechanism that uses cryptography to authenticate DNS data and verify the integrity of DNS queries and responses.

Learn more
Article

DNS stub resolver

A DNS stub resolver is the component on a client device that initiates and facilitates DNS queries to recursive resolvers.

Learn more
Article

Recursive DNS server

A recursive DNS server is the first server contacted by a requesting host; it retrieves the proper IP address of the intended domain name and returns it to the requester.

Learn more
Article

TCP

TCP (transmission control protocol) is a protocol that provides reliable, ordered, and error-checked delivery of bytes between applications on an IP network.

Learn more
Article

DNS Filtering

DNS filtering controls access to websites and online resources by allowing or blocking DNS queries based on predefined security policies and threat intelligence.

Learn more
Browse the full glossary