在 TLS 隧道中承载 DNS 报文的加密解析协议，专用 TCP 853 端口、强制证书校验，安卓私人 DNS 与路由器全局加密的事实标准。
从发起解析到拿到加密响应，中间发生了什么
传统明文 DNS 是一个「一问一答」的 UDP 报文：客户端把要查的域名以明文发往服务器 53 端口，任何人在链路上都能看到、甚至篡改这个报文。DoT 的思路非常直接——不改变 DNS 报文本身的格式，而是在它外面套一条 TLS 加密隧道，让中间节点只能看到「你正在和某个 DoT 服务器通信」，看不到具体查了什么域名。
客户端向 DoT 服务器的 853/TCP 端口发起 TCP 连接，随后进行标准 TLS 握手（ClientHello / ServerHello / 证书交换 / 密钥协商）。RFC 7858 要求服务器出示由客户端信任 CA 签发的证书，且证书上的主机名必须与用户配置的 DoT 主机名一致——这一步与浏览器访问 HTTPS 网站完全相同。
RFC 7858 第 6 节明确要求：证书校验失败时，客户端必须终止连接，而不是悄悄回退到明文 DNS。如果允许降级，攻击者只需在握手时返回一张假证书，就能让客户端「自愿」走明文，加密形同虚设。这也是为什么安卓私人 DNS 填错主机名会直接显示「无法连接」，而不是悄悄退回明文。
握手成功后，客户端把标准 DNS 查询报文直接写入这条 TLS 连接，服务器把 DNS 响应写回。为了在一条字节流上区分多个报文，DoT 采用 2 字节长度前缀Framing：先写 2 字节长度，再写对应长度的 DNS 报文。连接可以长期复用，后续查询不需要重新握手，这正是 DoT 延迟低、开销小的关键。
明文 DNS 的风险是三重的——窃听（运营商记录你访问了哪些域名）、篡改（中间人返回假 IP）、污染（针对特定域名注入伪造响应）。DoT 通过 TLS 同时解决了这三件事：内容加密防窃听、MAC 完整性校验防篡改、证书绑定服务器身份防冒充。
与明文 DNS、DoH 在同一张表里对照
| 维度 | 明文 DNS | DoT（RFC 7858） | DoH（RFC 8484） |
|---|---|---|---|
| 默认端口 | 53/UDP 与 53/TCP | 853/TCP（IANA 专用） | 443/TCP（复用 HTTPS） |
| 封装方式 | 裸 DNS 报文 | TLS 隧道 + 2 字节长度前缀 | HTTP 请求体 / GET 参数 |
| 证书校验 | 无 | 强制校验证书与主机名 | 强制校验 HTTPS 证书 |
| 流量可识别性 | 一眼即知 | 853 端口独立，易被针对 | 与网页流量混在一起，最难区分 |
| 协议开销 | 最小 | 低（无 HTTP 头） | 略高（带 HTTP 请求头） |
| 典型客户端 | 全部设备 | 安卓私人 DNS、iOS、OpenWrt | Chrome/Edge/Firefox、Windows 11 |
RFC 8310 进一步规定了 DoT 的「使用配置」：客户端应优先使用系统信任的 CA 证书库、不接受自签名证书，并定义了如何在与明文 DNS 并存时避免意外泄露。Cloudflare 在其 1.1.1.1 DoT 文档中也沿用了同一套端口与证书要求。
DoT 最常见的两个落地场景，复制主机名即可
dns.23-4.cntls://dns.23-4.cndns.23-4.cn。在路由器的 DHCP/DNS 设置里把上游服务器填成 tls://dns.23-4.cn，路由器会以 DoT 向该服务器发起加密解析，家里所有设备的 DNS 查询都先经过路由器再被加密转发，等于一次配置、全屋生效。这也是 DoT 相比 DoH 在家庭场景更受欢迎的原因——路由器固件原生支持 DoT 上游的比例更高。
服务端需要在 853/TCP 监听，并配置一张受信任 CA 签发的证书（如 Let's Encrypt）。防火墙/安全组必须放行入方向 853/TCP，否则客户端连握手都建立不起来；具体端口放行清单可参考本站《DoH/DoT 端口与防火墙放行》一文。