DNS Flag Day 2020 推动权威服务器拒绝分片 UDP 响应，迫使大包改走 TCP。文章回溯 IP 极简服务模型，解释为何 DNS 长期依赖 512 字节 UDP 上限，以及分片在现网中为何失效。
**UDP 与 DNS 的原生契合：**
IP 仅提供不可靠数据报，TCP 负责可靠流，UDP 仅加端口号。DNS 查询/响应模式天然适配 UDP：包小、丢包可靠超时重发换服务器。正常丢包率低时，UDP 无连接开销优于 TCP。但前提是尽量避免分片导致丢包。IPv4 保证所有主机能收 576 octets，DNS 将响应载荷限 512 octets，超长截断并置 TC 位，提示客户端改 TCP 重查。
**分片在现网中的失效与 Flag Day 动因：**
原文未给出具体分片丢包率数据，但指出中间设备常丢弃分片或拦截 ICMP 过大报文，导致大包 UDP 可达性下降。Flag Day 2020 协调主流递归与权威软件，默认拒绝发送分片 UDP 响应，强制大包走 TCP。此举消除“发大包 UDP、靠分片、指望重传”的不确定路径。
**运维层面的协议栈调整：**
权威服务器需确保 TCP 53 端口可达，防火墙放行 TCP DNS；递归端需正确处理 TC 位并自动回落 TCP。EDNS0 缓冲区大小宣告仍保留，但不再用于承载分片 UDP。原文未给出具体部署比例或延迟对比数据，工程师需自行在测试环境验证 TCP 回落对查询时延的影响。
对网络工程师而言，Flag Day 后的核心动作是：确保权威与递归双向 TCP 53 端口通畅，关闭对分片 UDP 的依赖，并在监控中纳入 TCP DNS 失败率与时延指标，防止大包解析静默失败。
原文: APNIC Blog（2020-12-14）｜编译自 APNIC Blog，事实以原文为准。
来源：APNIC Blog