01 · 防护体系总览
防护遵循"纵深"原则：没有任何单一措施能挡住全部六类劫持。四根支柱互补：
分层对应攻击面：①对付"链路/缓存/递归"（H-3/5/6）；④对付"终端/网关"（H-1/2）；而H-4（注册/权威）则需"注册锁+双因素+变更审计+DNSSEC"的组合——DNSSEC在此处仅防"NS未被盗改后的篡改"，不能防"NS被改"。
02 · DNSSEC部署
2.1 密钥模型
DNSSEC使用两类密钥：ZSK（Zone Signing Key，区域签名密钥）签署区域数据（A/AAAA/MX等RRset的RRSIG）；KSK（Key Signing Key，密钥签名密钥）签署DNSKEY记录集，其公钥由父区的DS记录认证，形成从根到域的信任链。根区已于2010-07-15签名，故只要父区部署、子区签名、解析器启用验证，信任即可逐级传递。
2.2 部署与运维要点
- 区域签名：用签名软件（BIND、Knot、PowerDNS等）为区域生成ZSK/KSK并签署所有RRset，发布RRSIG与DNSKEY。
- 父区DS：将KSK的DS提交至注册商/注册管理机构，写入父区——这是"信任链闭环"的关键一步，常被遗漏。
- 密钥轮转：按 RFC 6781《DNSSEC Operational Practices》规划ZSK（较频）、KSK（较少，但需父区同步DS）的轮转与"双重签名（double-signature）"过渡，避免轮转期验证失败。
- 启用验证：递归解析器开启DNSSEC验证（BIND
validate、Unboundharden-dnssec-data等），使伪造应答被拒。
2.3 验证解析器的可用性防护（KeyTrap）
2024年披露的 KeyTrap（CVE-2023-50387）与 NSEC3漏洞（CVE-2023-50868）表明：DNSSEC验证解析器本身已成为拒绝服务攻击目标——单个恶意应答即可耗尽验证CPU（见第3页§5.4）。运维要求：①所有验证解析器在2024年补丁基线以上；②监控解析器CPU与验证失败率基线，对突发飙升告警；③评估关闭非必要域的NSEC3高迭代参数（KeyTrap放大了NSEC3迭代成本）。
运维陷阱：①"签了名却没提交DS"=信任链断裂，解析器验证失败；②KSK轮转需父区同步DS，操作不当会导致"全域验证失败"（Bailiwick/DS匹配）；③签名/DS需随记录变更及时重签，否则RRSIG过期致"insecure/bogus"。建议用DNSViz定期自检签名链完整。
03 · 加密DNS（DoH/DoT）企业管控
3.1 三种加密解析协议
| 协议 | RFC | 传输 | 特点 |
|---|---|---|---|
| DoT | RFC 7858（2016） | TLS / 853 | 专用端口，运维易识别与管控，企业侧友好 |
| DoH | RFC 8484（2018） | HTTPS / 443 | 与Web流量混淆，抗封锁强，但企业更难区分与审计 |
| DoQ | RFC 9250（2022） | QUIC / 853 | 基于QUIC，低延迟、抗丢包，新兴部署 |
3.2 收益与风险
收益：加密"终端↔递归"这一段，抵抗链路上的监听、篡改与抢答（H-6对未签名域的部分防护），保护用户查询隐私。风险：①默认DoH会把查询集中到少数公共解析商，隐私从"本地ISP"转移到"解析商"；②绕过企业本地DNS策略/过滤与威胁情报阻断（如RPZ），弱化内网检测与合规审计；③可能被用于规避合法监管。
3.3 企业管控方案
- 自建可信加密解析：内网部署支持DoT/DoH的解析器（启用DNSSEC验证+RPZ），终端指向它，既加密又可控。
- 网关代理/白名单：仅允许经批准的DoH端点，阻断指向外部不可控解析器的DoH（防止绕过内网策略）。
- 策略分级：对涉密/关基终端可强制"内网加密解析+审计"，对普通终端提供可选加密解析。
监管平衡：加密DNS与"本地监管/内容安全"之间存在张力，这是第3子课题"加密DNS协议安全评估"的核心议题。本课题立场：在不削弱合法监管与内网安全前提下，优先采用企业自建加密解析，使"隐私保护"与"可审计、可阻断"兼得。
04 · 递归解析器安全审计
递归解析器是"默认信任"的出口，应对其建立审计指标（呼应首页"递归解析器安全审计"子课题）：
| 指标 | 含义 | 理想 |
|---|---|---|
| 解析准确性 | 返回IP与权威一致的比例 | ≈100% |
| 劫持率 | 返回异常/非权威IP的比例 | 0 |
| DNSSEC验证 | 是否对签名域执行验证 | 启用 |
| 响应完整性 | 是否遭投毒/注入 | 无 |
| 隐私政策 | 查询日志留存与用途 | 透明、最小化 |
| 可用性 | 抗DDoS与解析连续性 | 高可用、多活 |
审计方法：以测量网络（第5页）对候选解析器做长期"准确性/劫持率"探针；优先选用公开承诺DNSSEC验证、隐私政策透明、抗污染记录良好的解析器；对关键业务采用"多解析器 + 一致性裁决"。
05 · 路由器/终端加固
- 终端：禁止非授权修改hosts/网卡DNS（组策略/EDR管控）；对关键主机可"钉死"可信解析器；员工安全意识培训（识别被改DNS的可疑迹象）。
- 路由器/网关：改默认管理口令、禁用WAN侧远程管理、及时升级固件（订阅厂商安全公告）、定期审计网关DNS设置；对企业边界网关启用配置变更告警。
- 高价值域名：启用注册锁（Registry Lock）+ 双因素认证 + 变更审计（见第6页），直接抬高H-4门槛。
- CAA 记录：发布
CAA记录（RFC 8657）限定可为该域名签发证书的CA白名单，压缩攻击者"非法申请证书配合DNS劫持"的空间（巴西银行案的关键教训之一）。
06 · 监管与合规
DNS安全防护须纳入国内合规框架（详见第1页§8边界声明）：
| 法规/标准 | 与DNS防护的关联 |
|---|---|
| 《网络安全法》（2017-06-01施行） | 网络运营者安全保护义务、关键信息基础设施保护、事件处置与报告 |
| 《数据安全法》（2021-09-01） | 解析数据分类分级、重要数据出境与处理活动合规 |
| 《个人信息保护法》（2021-11-01） | 解析日志中的个人信息最小化收集、告知与合规处理 |
| 《关基安全保护条例》（2021） | 关基域名解析连续性、供应链与应急协同的更高要求 |
| 等保2.0 GB/T 22239-2019 | DNS作为网络基础设施，须满足对应等级的安全物理/通信/计算/管理要求 |
| GB/T 36643-2018 | 网络安全威胁信息格式规范，支撑威胁情报（含DNS异常）的规范化交换 |
| 《互联网域名管理办法》（工信部令第43号，2017） | 域名实名制、注册服务机构解析安全义务、域名争议处理——域名运营方的直接合规依据 |
| 《非经营性互联网信息服务备案管理办法》（2005） | 境内网站ICP备案与解析指向一致性核查的配套要求 |
落地提示：合规结论以国内正式测评/监管口径为准。本课题提供的检测与防护方法可作为等保/关基"通信传输完整性""安全审计""入侵防范"等条款的支撑手段，但不替代正式合规测评。
本节参考来源（第7页）
RFC 4033/4034/4035（DNSSEC）；RFC 6781《DNSSEC Operational Practices》（密钥轮转）：RFC 6781
RFC 7858（DoT）、RFC 8484（DoH）、RFC 9250（DoQ）：RFC 8484 (DoH)
NIST SP 800-81《Secure Domain Name System (DNS) Deployment Guide》：csrc.nist.gov SP 800-81
GB/T 22239-2019《信息安全技术 网络安全等级保护基本要求》；GB/T 36643-2018《网络安全威胁信息格式规范》
CNNIC，.cn域名DNSSEC支持与部署指引：cnnic.cn