DNS over TLS, commonly abbreviated DoT, carries DNS messages through a Transport Layer Security connection rather than sending them as ordinary unencrypted DNS traffic. Traditional DNS commonly uses UDP port 53, with TCP port 53 used when needed. DoT normally uses TCP port 853 and authenticates the resolver through its TLS certificate. This protects query names, responses, and other DNS message contents against passive observation and active modification on the protected network segment.
The security boundary is important: DoT protects a connection, not the entire recursive resolution process. If a workload connects to a recursive resolver using DoT, that resolver still sees the queries. Its subsequent communications with authoritative DNS servers are not automatically encrypted. Source and destination IP addresses, traffic timing, and approximate message sizes also remain observable. Resolver selection, query logging policies, and trust in the resolver operator therefore remain security decisions.
In a cloud environment, engineers can configure DoT-capable operating systems, local forwarding agents, or DNS proxies to send queries to an approved resolver. For example, an application instance can use a local caching resolver that forwards external queries over DoT. An organization can also run DoT listeners on virtual machines to accept encrypted queries from branch offices or other networks. The listener needs a certificate matching the configured authentication name, secure private-key handling, sufficient capacity, and redundant deployment.
For AWS networking designs, distinguish the DNS transport from the service providing resolution. An Amazon EC2 instance running suitable resolver software can terminate DoT and forward queries to Amazon Route 53 Resolver for private hosted zones. That forwarding connection is a separate security segment; receiving a query over DoT does not make the next connection encrypted. Likewise, using a managed DNS resolver or a private network does not itself establish DoT. Check the specific endpoint's supported protocols rather than assuming that every DNS interface accepts TCP port 853.
Strict certificate validation is essential. Configure the resolver's expected authentication name and trusted certificate authorities, and plan how clients obtain an initial endpoint address without creating a circular DNS dependency. A strict policy should fail rather than silently fall back to unencrypted DNS when TLS negotiation or certificate validation fails. Opportunistic configurations can improve privacy when encryption is available, but do not provide the same assurance against downgrade or interception.
Network controls must allow TCP port 853 to approved resolvers and the corresponding return traffic. Security groups, network ACLs, routes, and firewalls must all support the intended path. Blocking unauthorized port 53 traffic alone is insufficient to enforce resolver policy because applications might use other encrypted DNS transports, including DNS over HTTPS. Public resolvers also cannot normally resolve private hosted zones, so split-DNS forwarding rules must preserve internal resolution.
DoT adds connection establishment, certificate management, and connection-state overhead. Persistent connections, connection reuse, and caching reduce that cost. Monitor TLS failures, certificate expiry, query latency, and resolver availability; use resolver-side query logs when authorized because packet inspection cannot read encrypted DNS payloads. Finally, distinguish DoT from DNSSEC: DoT protects the transport to a resolver, while DNSSEC validates signed DNS data. DNS over HTTPS is another encrypted DNS transport, not another name for DoT.
Amazon EC2