什么是 EDNS：DNS 扩展机制与 UDP 载荷扩容

EDNS（Extension Mechanisms for DNS，DNS 扩展机制）是指一组在保持 DNS（域名系统，负责把域名翻译成 IP 地址的分布式协议）报文格式向后兼容的前提下，为 DNS 增加新能力的扩展机制，由 RFC 2671 定义，其现行版本为 RFC 6891 定义的 EDNS0。要理解 EDNS 解决的问题，需要回到原始 DNS 协议的两条硬性限制：使用 UDP（用户数据报协议，一种无连接的传输层协议）传输时，单个报文的载荷上限只有 512 字节；报文头部只设置了 16 个标志位，几乎全部已被占用，没有任何空间容纳新的协议特性。

EDNS 的核心做法是在报文中追加一个伪记录——OPT 伪记录（OPT pseudo-record），它不进入域名区数据、不出现在区文件里，只存在于查询与应答的传输过程中。客户端在发起查询时携带 OPT 记录，声明自己能接受的 UDP 载荷大小；服务端在应答时同样携带 OPT 记录，并利用其中的扩展标志位与扩展返回码传递传统头部放不下的信息。由于不支持 EDNS 的老实现会直接忽略 OPT 记录，整套机制得以在不升级全网设备的情况下平滑落地——这也是”向后兼容扩展”这一名称的由来。

从技术架构上看，EDNS 并没有发明新协议，而是给运行了几十年的 DNS 基础设施提供了一条持续演进的通道。今天互联网上的递归解析器几乎全部支持 EDNS0，本文后续讨论中的 EDNS 默认即指 EDNS0。围绕 UDP 载荷扩容这一最直观的变化，下文将依次展开 OPT 记录的结构、载荷协商与回退机制、DNSSEC 依赖、对解析行为的影响以及常见误区。

详细说明：OPT 伪记录如何扩展 DNS

OPT 伪记录的巧妙之处在于复用了标准资源记录的框架。它把传统记录中”记录所有者名称”的字段固定为根标记（”.”），把”记录类型”字段固定为 41，再把”类别”字段重新定义为 UDP 载荷大小（请求方宣布的接收能力，最大可声明为 4096 字节），”TTL”字段则被拆成三个部分：扩展返回码（EXTENDED-RCODE）、版本号（VERSION，当前为 0）以及 16 个 DNSSEC（DNS Security Extensions，DNS 安全扩展）相关的标志位（DO 位是其中最常用的一个，置为 1 表示请求方希望获得 DNSSEC 签名数据）。记录本身的数据区则用于存放一个个选项（option），例如保存客户端原始地址的 NSID 选项等。

对普通读者而言，不必逐字段记忆这些细节，把握一个要点即可：OPT 记录是一个”可编程的附加头”。传统 DNS 头部写不下的参数，全部塞进这条附加记录随报文一起传输，双方按需读取。DNSSEC 之所以能部署，正是因为验证者需要通过 DO 位告诉服务器”把签名记录一并返回”；如果没有 EDNS 提供的这 16 个扩展标志位，DNSSEC 的请求协商无处安放。

载荷扩容则直接体现在”类别”字段声明的 UDP 载荷大小上。1987 年的 RFC 1035 将 UDP 模式下的 DNS 报文限制在 512 字节，这在 TXT 记录、DNSKEY 签名记录动辄上千字节的今天完全不够用。EDNS 允许通信双方各自声明更大的接收能力，协商取两者较小值，从而让单次 UDP 往返就能装下更大的应答。IETF 在 2020 年的 RFC 8909 建议过程中将推荐值收敛为 1232 字节——这个数字同时避开了常见的 1500 字节 MTU（最大传输单元，链路层单帧能承载的数据量）在扣除 IP 头部后可能触发分片的区间，也照顾了隧道与 VPN 环境中更小的有效 MTU。BIND 9.16 及以上版本、Unbound 1.16 及以上版本的默认值均已调整为 1232 字节。

载荷协商与回退机制

EDNS 的载荷协商遵循”取双方较小值”的原则：客户端在 OPT 记录中声明自己能接收的 UDP 载荷上限，服务器应答时选择不超过该上限的尺寸；若应答超过上限，服务器会在头部设置 TC（截断）标志位，客户端收到后改用 TCP 重发查询。这套协商-回退流程保证了任何一端配置保守都不会导致解析失败。

理解分片风险是配置载荷大小的关键。假设服务器声明 4096 字节并按此返回了一个 1800 字节的应答，而路径上某段链路的 MTU 只有 1500，IP 层就会把 UDP 报文切成多个分片。一旦任何一个分片在网络中丢失，整个 UDP 报文都无法重组，客户端只能等待超时——这与”DNS 应答丢失”的表现完全一致，排查起来相当困难。更棘手的是，部分防火墙对非首片分片的处理策略与完整报文不同，直接丢弃的情况并不罕见。

历史上还有一段与”最小 EDNS”相关的插曲：ICANN 在 2020 年启动的域名根服务器标识轮换（KSK-2020）验证中，要求权威服务器忽略来自不声明 EDNS 能力的客户端的查询，以确认 EDNS 的真实普及率。相关测量得出的结论是：互联网上不支持 EDNS 的客户端已不足 0.02%，这也促使各公共递归服务陆续把”默默代替老客户端重试”的兼容逻辑移除，让 EDNS 成为事实上的解析标配。

EDNS 与 DNSSEC：扩展机制的核心受益者

DNSSEC 是 EDNS 扩展位最典型的使用者。一条启用 DNSSEC 的 DNSKEY 应答需要同时携带公钥记录与 RRSIG（资源记录签名，DNSSEC 中用于验证数据完整性的签名记录），总大小经常超过 512 字节；验证方还必须通过 OPT 记录中的 DO 位显式请求签名数据。换言之，没有 EDNS 就没有可用的 DNSSEC——这也是部分老旧防火墙在放行 DNS 流量时不认 OPT 记录、导致 DNSSEC 验证失败的根因。

DO 位置 1 之后，解析器收到的应答会附加一整套签名链。验证失败的应答会被标记为”数据不可信”，站点运营者在部署 DNSSEC 初期经常遇到的”部分用户无法访问”，往往不是签名本身有误，而是路径中某台中间设备丢弃了携带 OPT 记录或超过 512 字节的大应答。此时用不带 EDNS 的查询做对照测试，就能快速定位问题出在签名验证还是报文传输。相关背景可参考ICANN 关于根服务器 KSK 轮换的官方说明，以及 BIND ARM（Administrator Reference Manual）中关于 EDNS 行为的章节。

EDNS Client Subnet 与 CDN 调度

除了载荷与标志位，OPT 记录的选项区还催生了 ECSV——更准确的名称是 EDNS Client Subnet（ECS，RFC 7871/9196 定义的客户端子网选项）。它允许递归解析器把客户端的 IP 前缀（例如 /24）放进查询的选项区，使权威服务器能按客户端所在网络返回差异化的应答，主要服务于 CDN（内容分发网络，通过在全球部署节点加速内容访问）的就近调度。

其工作流程可以概括为三步：递归解析器收到用户查询后，判断目标权威服务器支持 ECS，便将用户 IP 的前若干位写入选项；权威服务器依据该前缀而非解析器出口 IP 做调度决策，并在应答中说明适用的前缀范围与剩余 TTL；解析器按该范围缓存多份应答，供同网段用户复用。代价是缓存键从”域名+记录类型”细化到了”域名+记录类型+网段”，解析器的缓存命中率和缓存容量都会受到一定影响，因此主流公共 DNS 对 ECS 的启用范围各有取舍，Google Public DNS 与 Cloudflare 的策略并不相同。

对网站运营者的实际影响集中在中国大陆访问场景：若权威服务器未正确处理 ECS，可能导致华东用户被调度到美国西海岸节点。排查这类问题时应同时检查权威侧的 ECS 支持与递归侧的选项传递，只看一端容易误判。

应用场景：EDNS 在服务器运维中的位置

在主机与服务器运维实践中，EDNS 主要出现在四类场景。其一是 DNSSEC 部署前的网络路径体检：确认防火墙放行大于 512 字节的 UDP 应答，这是域名上线 DNSSEC 前必须完成的检查项。其二是解析超时排查：当 dig 命令加上 +bufsize=512 +noedns 反而能拿到应答、正常查询却频繁超时时，基本可以锁定路径上存在丢弃大 UDP 报文或 OPT 记录的中间设备。其三是自建递归服务器的调优：把 edns-buffer-size 类参数设为 1232，可显著降低分片导致的静默丢包。其四是 CDN 调度异常的归因：借助 ECS 选项验证权威服务器是否按客户端网段返回了正确的边缘节点。

以下命令可用于快速验证 EDNS 协商行为，dig 工具默认发出带 OPT 记录的查询，通过对比两种参数组合的返回结果即可判断路径健康状况（关于 dig 基础用法与解析全流程，可参考域名与建站栏目下的相关词条）：

# 正常 EDNS 查询：观察应答中的 OPT 记录与协商到的载荷大小
dig @ns1.example.com example.com A +dnssec

# 对照测试：禁用 EDNS、限制 512 字节，用于定位中间设备问题
dig @ns1.example.com example.com A +noedns +bufsize=512

第一条命令的应答末尾若出现 ;; OPT PSEUDOSECTION，说明双向 EDNS 协商成功，udp: 1232 即双方协商的载荷尺寸；第二条命令若成功而第一条超时，问题几乎必然出在传输路径而非域名数据本身。

常见误区与边界条件

围绕 EDNS 存在几个高频误解。误区一：”EDNS 必须在域名注册商或 DNS 控制台里开启”。实际上 EDNS 是协议层的传输机制，由解析软件自动协商，不需要也无法在管理界面里配置；控制台里可配置的是 DNSSEC 开关、ECS 隐私策略这类基于 EDNS 之上的特性。误区二：”载荷大小设得越大解析越快”。恰恰相反，超过路径 MTU 的声明会触发 IP 分片，任何单片丢失都会导致整个应答作废，1232 字节正是平衡容量与分片风险的工程结论。误区三：”解析失败优先怀疑 DNSSEC 签名错误”。实践中相当比例的”DNSSEC 故障”其实是中间设备丢弃大 UDP 应答所致，先用 +noedns 对照测试可以避免在签名排查上浪费时间。

此外还应了解边界条件：区域传输（AXFR/IXFR）走 TCP，与 EDNS 载荷协商无关；EDNS 版本不匹配时服务器会返回 BADVERS 错误而不是降级应答，客户端实现需正确处理；ECS 会把用户网段信息带出本地网络，隐私敏感场景应评估前缀长度的披露范围。

参考资料

• RFC 6891 “Extension Mechanisms for DNS (EDNS(0))”：定义 OPT 伪记录、扩展标志位与载荷协商规则
• UDP 载荷推荐值收敛为 1232 字节：RFC 6891 给出的安全建议值，经 DNS Flag Day 2020 推动后成为主流解析器的默认配置
• ICANN 根区域 KSK 轮换官方说明：KSK 轮换计划、时间线与解析器运营者指南
• 延伸阅读：主机百科术语表（收录 DNS、CDN 等常见主机与网络术语的定义词条）
• 延伸阅读：域名与建站
• 延伸阅读：一文看懂 SSL 证书的作用与种类