在IEPG会议上，ISC的Mark Andrews由Francis Dupont代为汇报：通过dig命令多选项探测发现，当前DNS流量中EDNS实现普遍不合规，大量设备表现出异常子集行为，尽管EDNS已成强制要求。
测试方法与发现：
测试团队构造不同EDNS选项的dig查询，向权威与递归服务器发送探测请求，记录响应的EDNS版本、DO位、UDP缓冲区大小及扩展选项支持情况。原文未给出具体探测样本量、覆盖的服务器数量或地理分布。结果显示，响应设备对EDNS隐含行为的支持呈现碎片化：部分仅回应版本号，部分忽略DO位，部分截断扩展选项，甚至出现未定义的响应码组合。这些变体在野外环境中大量共存，形成难以预测的兼容性矩阵。
合规现状与异常表现：
EDNS（RFC 6891）已规定实现必须支持，但实测中“错误实现与完全不支持的量级”异常高企。原文未给出具体不合规比例、错误类型分布统计或随时间变化趋势。观察到的典型异常包括：权威服务器拒绝带EDNS选项的查询、递归解析器丢弃扩展RCODE、中间设备将EDNS负载截断至512字节、防火墙基于未知选项码点直接丢包。这些行为导致DNSSEC验证失败、大响应回落TCP延迟增加、客户端重试风暴等连锁故障。
可能成因分析：
报告推测，核心成因在于查询-响应路径上的中间系统干扰。企业防火墙、运营商透明代理、负载均衡设备常对DNS报文做深度检测或改写，却未同步更新EDNS解析逻辑。原文未给出具体厂商、设备型号或固件版本的定向取证数据。此类设备要么按旧RFC 1035处理报文，要么对未知选项码点采取拦截策略，导致合规实现的EDNS扩展在传输中被篡改或丢弃，最终表现为端侧的“伪不合规”。
对运维工程师的实际意义：
排查DNS解析异常时，需优先验证链路上是否存在EDNS不透传设备；部署DNSSEC、EDNS Client Subnet等扩展前，应在生产路径上做全链路探测；防火墙与代理规则集需显式放行EDNS选项码点，避免因未知字段触发默认拦截。
原文: APNIC Blog（2015-03-26）｜编译自 APNIC Blog，事实以原文为准。
来源：APNIC Blog