IPv6 将分片处理从转发节点移至发送端，导致 DNS 大包在全 IPv6 路径上遭遇更高丢包率，结论是需通过 EDNS0 缓冲区协商与 TCP 回退机制缓解，而非依赖网络层分片。
**分片处理的架构差异**
IPv4 允许路由器在转发时对超长包进行分片与重组，IPv6 则禁止中间节点分片，要求发送端通过路径 MTU 发现（PMTUD）预先将包切分至路径最小 MTU。原文指出 IPv6 这种设计“显著劣于 IPv4”，且曾引发业界讨论彻底取消 IPv6 分片。DNS 响应常超出 1,500 字节以太网 MTU，若发送端未正确执行 PMTUD 或中间设备丢弃 ICMPv6 Packet Too Big 报文，大包将在网络中静默丢失，导致解析超时或失败。
**包大小权衡与历史参数**
早期网络对包长取舍各异：以太网 64–1,500 字节、FDDI 至 4,478 字节、帧中继 46–4,470 字节。小包降低首部开销比例但增加处理负载与队列阻塞风险；大包提升载荷效率与交换吞吐，却加剧抖动。DNS 需在 512 字节 UDP 传统限制、EDNS0 宣告缓冲区（常 1,232–4,096 字节）与 TCP 回退之间平衡。原文未给出具体 DNS 分片丢包率数据。
**工程对策与协议演进**
运维层面应确保边界设备不拦截 ICMPv6 Type 2 报文，授权服务器启用 EDNS0 并将 UDP 缓冲区设为不超过路径 MTU（建议 1,232 字节），超长响应主动截断（TC=1）触发客户端 TCP 重试。长期看，DNS over HTTPS/TLS 与 HTTP/3 将应用层分片下沉至传输层，绕过网络层分片缺陷。原文未给出部署比例或实测延迟对比。
对网络工程师而言，核心启示是：不要指望 IPv6 网络层替你分片，必须在 DNS 服务端与解析端通过协议参数显式控制包长，并保障 ICMPv6 反馈路径通畅，才能在全 IPv6 环境下维持解析可靠性。
原文: APNIC Blog（2017-08-22）｜编译自 APNIC Blog，事实以原文为准。
来源：APNIC Blog