DNS 作为互联网最关键的协议之一，将难记的 IP 地址映射为可读域名，支撑所有用户的日常访问。然而其原始设计未预见敌对网络环境，天然易受拒绝服务、劫持与缓存投毒攻击。DNSSEC 作为已就绪十余年的安全扩展，能从顶级域向下验证每条记录，确保用户访问银行等站点时获得真实 IP，却至今未获大规模部署。
协议缺陷与安全扩展机制：
DNS 早期设计缺乏完整性与来源认证机制，攻击者可伪造响应将流量导向恶意服务器。DNSSEC 引入公钥密码学，在资源记录集上附加 RRSIG 签名，通过信任链从根区向下逐级验证。当解析器收到带签名的回答，可追溯至信任锚点，确认数据未被篡改。这套机制在协议层面解决了缓存投毒与中间人劫持，但部署需域名持有者签名、注册商传递 DS 记录、递归解析器开启验证，三方同步推进难度大。
HTTPS 演进对比与部署现实：
1990 年代中期银行业务上网催生 HTTPS，Netscape 推出加密传输后，敏感数据逐步全站加密，现无商业服务敢裸跑 HTTP。但 HTTPS 仅保护传输链路，若 DNS 被劫持将用户引向攻击者服务器，浏览器因无证书而不报警，用户仍会落入钓鱼陷阱。DNSSEC 与 HTTPS 互补：前者保证域名解析真实性，后者保证会话机密性。原文未给出具体部署比例数据，但指出全球大部分区域仍未启用验证，根因在于签名密钥管理复杂、区域大小导致响应包超 MTU 引发截断重传、以及运维缺乏即时收益激励。
对网络工程师的实践意义：
在递归解析器开启 DNSSEC 验证可拦截伪造响应，需配置信任锚点并监控验证失败日志。权威服务端需生成 KSK/ZSK、定期滚动密钥、通过注册商提交 DS 记录，并启用 NSEC3 防止区域枚举。运维层面应纳入 DNSSEC 状态监控，将验证失败率、密钥过期时间纳入告警指标，避免因密钥滚动失误导致解析中断。尽管部署成本客观存在，但在零信任架构与供应链安全要求下，DNSSEC 已成基础设施加固的必要项而非可选项。
原文: APNIC Blog（2017-06-28）｜编译自 APNIC Blog，事实以原文为准。
来源：APNIC Blog