Appearance
DNS 解析走 TCP 还是 UDP？一份讲清楚的解答文档
更新: 6/28/2026 字数: 0 字 时长: 0 分钟
这是个经典面试题，也是个容易被「背答案」糊弄过去的问题。标准答案是：两个都走，但分场景。 默认走 UDP，特定情况下转 TCP。下面把「为什么」和「什么时候」彻底讲明白。
一、一句话结论先给你
DNS 在协议设计上同时使用 UDP 和 TCP，端口都是 53。
- 绝大多数普通查询走 UDP（53 端口）——这是日常你访问网站时发生的事。
- 特定场景走 TCP（53 端口）——主要是响应数据太大、或者做区域传送（主从同步）的时候。
所以「走 TCP 还是 UDP」这个问法本身就有点陷阱，正确姿势是：它俩各管一摊，UDP 是主力，TCP 是后备和特殊任务专用。
二、为什么默认选 UDP？
DNS 查询的特点是：请求小、响应也小、要求快、量极大。 你打开一个网页可能背后就有几十次域名解析，全网每秒的 DNS 查询量是天文数字。
UDP 正好对上了这些需求：
- 没有三次握手，发一个包、收一个包就完事，延迟极低；
- 没有连接状态，DNS 服务器不用为每个查询维护连接，能扛住海量并发；
- 开销小，一次查询通常一来一回两个包就够。
代价是 UDP 不可靠——可能丢包、不保证顺序。但 DNS 用了个很聪明的办法兜底：应用层自己重试。客户端发出去没等到响应，超时了就再发一次，或者换一个 DNS 服务器问。对于「一问一答」这种简单交互，这套机制成本远比维护 TCP 连接低。
核心逻辑：DNS 用「应用层重试」换掉了「传输层可靠性」，从而能享受 UDP 的低延迟和高并发。
三、什么时候必须转 TCP？
UDP 虽好，但有它扛不住的场景。主要是这三类：
1. 响应数据太大（最常见的原因）
早期 DNS 规定 UDP 报文最大 512 字节。一旦响应内容超过这个限制（比如一个域名配了一大堆记录、或者返回很多 IP），UDP 这个「小快递」就装不下了。
这时的标准流程是：服务器在 UDP 响应里把 TC（Truncated，截断）标志位置 1，告诉客户端「数据没发全，你改用 TCP 再问一次」。客户端收到后，就用 TCP 重新发起同一个查询，靠 TCP 的分段传输把完整数据拿回来。
补充：现在有个扩展叫 EDNS0，可以协商更大的 UDP 报文（比如 4096 字节），让更多大响应也能继续走 UDP，减少转 TCP 的次数。但根本兜底机制还是 TCP。
2. 区域传送（Zone Transfer / AXFR）
DNS 主服务器和从服务器之间同步整个区域的解析数据时，数据量很大、而且必须完整、不能丢一条。这种场景对可靠性的要求远高于对延迟的要求，所以区域传送固定走 TCP，不用 UDP。
3. DNS over TLS / DNS over HTTPS 等加密查询
现代为了隐私和安全，出现了 DoT（DNS over TLS）、DoH（DNS over HTTPS）这类加密 DNS。它们建立在 TLS/HTTPS 之上，而 TLS/HTTPS 本身基于 TCP，所以这类查询也是走 TCP（DoH 走 443 端口，DoT 走 853 端口，注意这俩不是 53）。
四、用一张表收束记忆
| 场景 | 协议 | 端口 | 原因 |
|---|---|---|---|
| 普通域名查询 | UDP | 53 | 小、快、并发高 |
| 响应超过 UDP 限制（TC 标志置位） | 转 TCP | 53 | UDP 装不下，需可靠分段传输 |
| 区域传送（AXFR/IXFR 主从同步） | TCP | 53 | 数据大且要求完整 |
| DoT 加密查询 | TCP | 853 | 基于 TLS |
| DoH 加密查询 | TCP | 443 | 基于 HTTPS |
五、面试 / 实战里怎么答才到位
如果被问到，别只说「UDP」，那是半个答案。完整且有层次的回答应该是：
- 先给结论：默认 UDP，必要时 TCP，端口都是 53；
- 讲清为什么默认 UDP：查询小、要求快、并发高，靠应用层重试弥补不可靠；
- 讲清何时转 TCP：响应被截断（TC 位）、区域传送、加密 DNS；
- 加分项：提一句 EDNS0 扩展和 DoT/DoH，说明你了解现代演进。
这样答，既覆盖了原理，又体现了你对真实场景的理解，比单纯背「两个都走」高一个档次。
一句话收尾
DNS 不是二选一，而是「UDP 打主力、TCP 当后备和特种兵」：日常查询图快走 UDP，数据装不下或要做主从同步就上 TCP。把「为什么这么设计」想明白，这个问题你就再也不会答错。