DNSSEC，从终端用户视角解析（第三部分）

在本DNSSEC系列的首篇文章中，我揭示了DNS漏洞问题；第二篇介绍了解决方案。在这第三部分中，我将深入分析DNSSEC：它能否全面保护用户免受攻击？还是仅能防御部分攻击？边缘案例又该如何处理？

DNSSEC可防护的攻击类型（摘自首篇文章）

• DNS服务器缓存投毒（传统方式）
• DNS缓存投毒（Kaminsky方式）
• ISP出于广告或监控目的的劫持
• 强制门户（Captive Portals）
• 渗透测试者通过主动中间人攻击劫持DNS
• 恶意攻击者通过主动MITM劫持DNS

DNSSEC无法防护的攻击类型

• 通过恶意软件设置的恶意DNS服务器

• 通过DNS管理面板权限直接修改IP记录

• 强制门户（重复项）

• 渗透测试者通过主动中间人攻击劫持DNS（重复项）

• 恶意攻击者通过主动MITM劫持DNS（重复项）

细心的读者可能会疑惑：“我到底是否受到保护？” 问题的关键在于攻击场景——当攻击者位于用户与DNS服务器之间时，可伪装成DNS服务器，将其降级为非DNSSEC感知版本，并返回无DNSSEC签名的响应。

全面防护方案

1. 本地部署DNSSEC验证解析器：在本地localhost配置支持DNSSEC的服务器作为解析器（可通过教程轻松实现）
2. 杜绝恶意软件运行：保持系统清洁
3. DNS管理面板加强认证：至少启用双因素认证
4. 注册局锁定机制（详见第一部分）
5. 使用支持DNSSEC的操作系统
6. 访问受DNSSEC保护的网站
7. 需要客户端强制验证API：未来需开发能强制要求DNSSEC保护的接口，无签名时拒绝建立连接

DNSSEC冷知识集锦

• .SE域于2005年9月成为全球首个签署DNSSEC的顶级域
• DNSSEC于2010年7月15日首次在根域完成部署
• .NL成为首个拥有超百万DNSSEC签名域名的TLD
• 匈牙利正处于DNSSEC测试阶段（注意：相关页面为匈牙利语）
• 可使用DNSSEC验证工具进行测试
• 存在DNSCrypt等替代方案
• 未来可能通过DNSSEC强制实施HSTS（HTTP严格传输安全）
• 未来可能通过DNSSEC实现证书钉扎（Certificate Pinning）

祝各位DNSSEC配置愉快！;-)

作者注：
差点误删全文，幸而通过Chrome缓存恢复。特别感谢Nir Sofer的ChromeCacheView工具——拯救于水火！:D

Posted by Z at 1:47:00 PM
标签: DNS劫持, DNS欺骗, DNSSEC