DNSSEC 通过签名记录保证数据完整性，但其 NSEC 记录的设计特性会将区域内所有权威名称以明文链形式暴露，导致攻击者无需暴力破解即可完整遍历子域名；NSEC3 虽引入哈希与迭代缓解该问题，但参数配置不当仍可能被离线字典攻击破解，工程师需在签名开销与枚举风险之间权衡。
NSEC 记录的区域遍历机制：
启用 DNSSEC 后，权威服务器为每个权威名称生成 NSEC 记录，指向按规范顺序排列的下一个名称。以 lab.test 为例，查询不存在的 `a.lab.test` 将返回覆盖该空白的 NSEC，其 Owner Name 为 `data.lab.test`，Next Domain Name 为 `help.lab.test`，由此递归即可按字典序枚举出 `data`、`help`、`marketing`、`shop`、`transfer`、`verify`、`www` 等所有子域名。原文展示的区域文件中，每条记录均附带 RRSIG（算法 13、Key Tag 35470、Inception 20220908000000、Expiration 20220929000000），证明 NSEC 链本身也受签名保护，但这不阻止合法查询获取明文名称。原文未给出具体枚举耗时或查询量数据。
NSEC3 的哈希保护与残留风险：
NSEC3 用 Base32 编码的 SHA-1 哈希替代明文名称，并引入 Iterations 参数增加离线破解成本。若区域配置 `Iterations=0` 或盐值过短，攻击者可预计算彩虹表或实时 GPU 破解还原子域名；若迭代次数过高（如 >2500），权威服务器 CPU 占用显著上升，可能影响响应延迟。原文未给出推荐迭代阈值或具体性能损耗数字。此外，NSEC3 的 Opt-Out 标志若用于未签名委派，会进一步缩小受保护范围，需结合区域规模评估。
运维层面的缓解措施：
在无法部署 NSEC3 的场景下，可通过最小化区域内容、拆分公私用域名、对敏感子域名采用独立签名区域等方式降低暴露面。监控异常 NSEC/NSEC3 查询模式（如短时大量不存在名称查询）有助于早期发现枚举行为。工程师应在 DNSSEC 部署清单中加入“枚举风险评估”项，并定期复核 NSEC3 参数与密钥滚换策略，确保签名安全性不以资产暴露为代价。
原文: APNIC Blog（2023-01-17）｜编译自 APNIC Blog，事实以原文为准。
来源：APNIC Blog