01 · 研究背景与意义
1.1 DNS 在攻击链路中的枢纽地位
DNS（Domain Name System，域名系统）自1987年RFC 1034/1035确立以来，一直承担"域名→IP地址"的翻译职责，被形象地称为"互联网的地址簿"。然而，DNS协议在设计之初以"可用、可扩展、分布式"为首要目标，默认不提供完整性校验、来源认证与传输加密——基于UDP的查询/应答仅以16位事务ID（Transaction ID）与源端口做弱关联，应答方无需证明"我就是权威"。这一设计缺陷使DNS成为整条攻击链路中最前置、最隐蔽的突破口：攻击者无需入侵目标服务器，只需在"翻译"环节动手，就能把用户静默引导至钓鱼、仿冒或恶意节点。
为何"改地址簿"比"攻服务器"更经济：入侵一台Web服务器影响的是单点；而劫持解析可使该域名下的全部用户（乃至依赖该域名的API、邮件、CDN回源）在不知情的情况下集体失联或被误导。对攻击者而言，解析层攻击具有"一次得手、全域生效"的杠杆效应，且多发生在用户侧与运营商链路之间，终端上的TLS证书、杀毒软件往往无法感知"域名被指向了错误IP"这一事实。
1.2 劫持与篡改的威胁本质
从攻击结果看，DNS劫持（DNS Hijacking）与DNS篡改（Tampering）常被混用，但侧重点不同：劫持强调"解析结果的去向被控制"（用户想去A，被送到B）；篡改强调"应答内容被非法改动"（缓存或传输中的记录被替换、污染）。二者都破坏了DNS的真实性（Authenticity）与完整性（Integrity）。需特别指出：即便网站启用了HTTPS/TLS，DNS劫持仍可在"连接建立之前"生效——用户拿到的是攻击者IP，随后看到的要么是自签名证书的拦截页（触发浏览器告警但仍有用户忽略），要么攻击者持有合法证书（通过非法申请或证书透明度监控盲区）完成的"透明"中间人。因此DNS安全是TLS安全的前置条件，而非替代关系。
1.3 与迪妙反钓鱼业务的直接关联
迪妙网络空间安全学院深耕反钓鱼、反诈骗与企业安全意识培训。大量钓鱼事件的发生，第一步就是让用户"到达错误的站点"——这既可能是诈骗分子直接注册形似域名（typosquatting），也可能是通过DNS劫持把合法域名解析到钓鱼服务器。本子课题的检测方法（多路径比对、DNSSEC验证、证书透明度监控、被动DNS异常识别）可直接支撑学院的钓鱼站点发现、仿冒域名预警与公众识别指南，并与"域名滥用治理""域名数据与威胁监测"等兄弟子课题形成数据闭环。
核心科学问题：在"明文、分布式、弱认证"的DNS体系下，如何以可复核、可复现、低成本的方式，从海量解析结果中区分"正常的多CDN/Anycast差异"与"恶意的劫持与篡改"？本课题围绕"链路可观测—应答可验证—异常可度量—事件可处置"四个层次展开工程化研究。
02 · DNS解析链路模型
理解劫持的前提是厘清"一次解析经历哪些环节"。以用户访问 www.example.com 为例，典型解析链路自底向上分为四层，每一层都存在被劫持/篡改的攻击面：
| 链路层 | 主要角色 | 典型劫持/篡改手法 | 检测切入点 |
|---|---|---|---|
| ① 终端/本地 | 操作系统hosts、网卡DNS、家用路由器、本机Agent | 篡改hosts文件、修改本地DNS指向 rogue resolver、路由器CSRF改DNS、恶意软件（如DNSChanger类） | 本地配置核查、出口解析一致性 |
| ② 递归解析器 | ISP/local DNS、公共DNS（Google/Cloudflare/Quad9等） | 解析器被入侵或被收买注入虚假应答、策略性污染（按地域/网络返回不同结果） | 多解析器交叉比对、权威侧回源验证 |
| ③ 权威/注册 | 权威DNS、域名注册商、注册管理机构 | 注册商账户被盗改NS、区文件被非法修改、权限提升改A/AAAA记录 | 变更审计、DNSSEC验证、注册锁 |
| ④ 根与链路 | 根/TLD服务器、网络运营商、BGP | BGP前缀劫持影响解析流量、国家级DNS注入/污染、链路中间人抢占应答 | 分布式测量、多地域探针、OONI类测量 |
说明：上表为本课题基于RFC 1034/1035解析流程与公开威胁报告（Cisco Talos Sea Turtle/DNSpionage、FBI Operation Ghost Click等）归纳的攻击面分层，非任何厂商官方对照表。
03 · 劫持与篡改分类框架
为统一检测口径，本子课题将DNS劫持/篡改归并为六类。该分类与攻击发生的"链路层"一一对应，又叠加了"缓存投毒""协议层加密绕过"等跨层手法：
| 编号 | 类型 | 定义与典型场景 | 对应链路层 |
|---|---|---|---|
| H-1 | 终端配置劫持 | 修改本机hosts、网卡DNS、路由器DHCP下发，使终端始终使用受控解析。代表：DNSChanger恶意软件（FBI"Ghost Click"行动，2011）。 | ① 终端 |
| H-2 | 路由器网关劫持 | 通过CSRF/弱口令/漏洞入侵家用或企业边界路由器，篡改其DNS设置，影响下游全部终端。代表：2016—2017巴西银行大规模路由器DNS重定向钓鱼案。 | ① 终端/链路 |
| H-3 | 递归解析器劫持 | 控制或收买递归解析器，对特定域名返回攻击者IP；含ISP级策略性污染。代表：国家级DNS注入（见第5页测量）。 | ② 递归 |
| H-4 | 权威/注册劫持 | 盗用注册商账户改NS、非法修改区文件或A/AAAA记录。代表：Sea Turtle（Talos, 2019，涉40+组织/13国）、DNSpionage（2018）。 | ③ 权威/注册 |
| H-5 | 缓存投毒 | 利用事务ID/源端口可预测性，向解析器缓存注入伪造记录，长期污染。代表：Kaminsky漏洞 CVE-2008-1447。 | ② 递归（缓存） |
| H-6 | 链路上中间人/路由劫持 | 在传输路径抢占应答（on-path），或通过BGP前缀劫持把解析流量引向攻击者。代表：2018 MyEtherWallet BGP+DNS劫持事件。 | ④ 链路/根 |
分类易错点：缓存投毒（H-5）与递归劫持（H-3）常被混淆——前者是"骗缓存"，污染具有时间窗口（受TTL约束）且无需控制解析器；后者是"控解析器"，可持续、可定向。两者检测手法不同：缓存投毒看"应答是否经DNSSEC验证/与权威是否一致"，递归劫持看"同一解析器对全网用户是否异常地返回非权威结果"。
04 · 研究目标与关键问题
- 可观测：建立覆盖"终端—递归—权威—链路"的多层次解析测量能力，形成常态化的劫持/篡改基线画像（第4、5页）。
- 可验证：以DNSSEC、证书透明度、被动DNS为锚点，对可疑应答做"真实性"判定，而非仅做"差异"告警（第3、4页）。
- 可度量：将劫持行为量化为可比较的指标（劫持率、篡改类型分布、验证覆盖率），支撑态势评估（第5页）。
- 可处置：形成"检测—取证—通报—加固"闭环，输出面向运营商、注册商、企业的可落地加固方案（第6、7页）。
4.1 三个关键研究问题
| 编号 | 关键问题 | 内涵说明 | 对应章节 |
|---|---|---|---|
| KQ-1 | 差异与恶意的判别 | 多CDN/Anycast/智能解析本就返回不同IP，"解析不一致"≠"被劫持"。如何设定可复核的判定阈值与白名单，避免误报泛滥？ | 第4页 §02—§04 |
| KQ-2 | 验证能力的覆盖率 | DNSSEC能终结"真伪之辩"，但全球验证率约30%—35%（APNIC/Akamai 2024年测量约30%；美国约35%）。未签名区如何兜底检测？ | 第4页 §05 / 第5页 |
| KQ-3 | 情报到行动的转化 | 检测结果如何转化为可执行的加固（DNSSEC部署、可信递归、加密DNS管控）与监管通报，形成闭环？ | 第6、7页 |
4.2 研究范围界定
- 域范围：聚焦"递归—权威—终端"主链路，兼顾客服DNS/hijack at registry；BGP劫持仅作为"影响DNS的路由层因素"纳入，不展开BGP本身攻防。
- 协议范围：覆盖传统DNS（UDP/53）、DoT（RFC 7858）、DoH（RFC 8484）、DoQ（RFC 9250）下的劫持差异；DNSSEC（RFC 4033/4034/4035）作为验证基线。
- 深度范围：做到"检测方法+验证+处置"层面，不提供可直接复用的攻击实现；对真实攻击手法的描述仅用于理解与构建防御。
05 · 八页研究框架
本子课题按"认知框架 → 攻击面 → 技术机理 → 检测方法 → 实证数据 → 处置闭环 → 防护治理 → 案例收口"组织为八页，各页通过统一的分类编号（H-1~H-6、KQ-1~KQ-3、A1~A8）衔接：
06 · 核心研究内容总览
| 编号 | 研究内容 | 要点 | 展开位置 |
|---|---|---|---|
| A1 | 劫持类型学与攻击面 | H-1~H-6六类手法的技术机理、ATT&CK式映射、真实案例归属 | 第2页 |
| A2 | 缓存投毒机理 | Kaminsky攻击、事务ID/源端口猜测、0x20编码、NSEC/NSEC3缓存与缓解 | 第3页 |
| A3 | 检测技术体系 | 多解析器交叉验证、DNSSEC验证、被动DNS、证书透明度、TTL/一致性、RPZ、流量日志 | 第4页 |
| A4 | 测量网络与实证 | 分布式探针、全球DNS注入测量、DNSSEC验证率与TLD/域名签名覆盖、.cn体系测量、事件案例库与数据可视化 | 第5页 |
| A5 | 取证与应急响应 | 事件分级、取证要素（应答/证书/网络）、监管通报、加固与复盘 | 第6页 |
| A6 | 防护与治理 | DNSSEC部署、加密DNS（DoH/DoT）企业管控、递归审计、路由器/终端加固、合规 | 第7页 |
| A7 | 实战案例与检测工程 | Sea Turtle完整链、检测规则样例、实施路线图、局限性与总结 | 第8页 |
07 · 常见认知误区与术语辨析
| 误区/混淆 | 辨析 |
|---|---|
| "上了HTTPS就安全了" | 错误。HTTPS保护"连接建立之后"的传输，但DNS劫持发生在"连接建立之前"——用户先被解析到错误IP，再看证书。除非配合DNSSEC+HSTS+证书透明度监控，否则仍可能被诱导至仿冒站（尤其中途证书合法时）。 |
| "解析不一致=被劫持" | 错误。CDN、Anycast、按地域/网络智能解析本就返回不同IP。判别需结合白名单、DNSSEC验证、与权威侧回源比对，而非单纯看"多地结果不同"。 |
| "DNSSEC能解决一切" | 错误。DNSSEC仅保证"已签名区"的应答真实完整，不防"域名未签名"，也不防"注册商账户被盗改NS后重新签名"。它是地基而非全部。 |
| "公共DNS一定更可信" | 错误。公共DNS（8.8.8.8/1.1.1.1等）在抗劫持上通常优于被污染的本地递归，但仍可能受 jurisdictional 策略影响；且"用公共DNS"本身不改变终端hosts/路由器被改的风险。 |
| "缓存投毒=控制了DNS服务器" | 错误。缓存投毒是向缓存"注入"伪造记录，无需控制服务器；与"递归解析器被控制"（H-3）在权限与持续性上完全不同（见第3页）。 |
| "DoH/DoT让劫持消失" | 错误。加密DNS保护"终端↔递归"这一段不被链路监听/篡改，但不保证"递归↔权威"的完整性，也不验证域名真实性（仍需DNSSEC）。且加密DNS在企业侧带来管控与审计新课题（第7页）。 |
7.1 核心术语速查
| 术语 | 释义 |
|---|---|
| DNS Hijacking | DNS劫持：解析结果去向被控制，使用户到达非预期主机 |
| Cache Poisoning | 缓存投毒：向解析器缓存注入伪造资源记录，污染具TTL时效性 |
| DNSSEC | 一组RFC（4033/4034/4035）定义的DNS安全扩展，以数字签名提供来源认证与完整性 |
| Passive DNS | 被动DNS：通过历史解析观测积累"域名↔IP"映射，用于异常比对 |
| Certificate Transparency | 证书透明度（CT）：公开审计日志，记录所有已签发证书，用于发现针对域名的非法证书 |
| RPZ | Response Policy Zone：DNS防火墙策略区，可基于策略阻断/改写特定应答 |
| ECS | EDNS Client Subnet（RFC 7871）：将客户端子网信息随查询携带给权威，以支持智能解析；同时引入隐私与劫持面扩展 |
| Anycast | 任播：同一IP由全球多个节点宣告，用户就近接入；CDN与公共DNS广泛采用，是"多解析器结果不同"的常见合理原因之一 |
| DANE/TLSA | 基于DNSSEC的TLS证书绑定（RFC 6698/7671）：将证书指纹写入DNS并签名，与CT互补验证 |
08 · 研究边界与合规声明
合规与伦理声明：①本课题全部技术路线以防御为目的，严格遵守《网络安全法》《数据安全法》《个人信息保护法》等法律法规；②涉及的测量仅在授权范围内、以聚合/匿名方式进行，严禁针对任何未授权目标发起解析欺骗或探测；③对真实攻击活动的描述仅用于理解威胁与构建防御，不提供可直接复用的攻击实现；④引用标准遵循其发布条款（如DNSSEC相关RFC、NIST SP 800-81）；⑤面向国内关键信息基础设施场景，交付时须提示《关键信息基础设施安全保护条例》（2021年施行）与网络安全等级保护（GB/T 22239-2019）、《互联网域名管理办法》（工信部令第43号，2017-11-01施行，含域名实名与解析安全要求）等国内合规锚点——本课题研究不构成合规测评结论，合规以国内正式测评体系为准。
知识产权边界：DNSSEC、DoH/DoT/DoQ等均为IETF标准（RFC文档），可公开引用；NIST SP 800-81《Secure Domain Name System (DNS) Deployment Guide》为美国国家标准与技术研究院公开发布指南；本课题在研究与教学材料中引用时保留出处标注，不对标准内容本身主张任何权利。
09 · 预期成果与交付物
- 《DNS劫持与篡改检测方法论》研究报告（含H-1~H-6分类框架、判定阈值规范、术语辨析）
- 多路径解析一致性测量工具与基线库（覆盖主流公共DNS与运营商递归，含白名单与差异判定）
- DNSSEC验证检查清单与自动化脚本（基于dig/delv/DNSViz，输出验证覆盖率与失败原因）
- 证书透明度+被动DNS异常监测模板（面向仿冒域名/非法证书的早发现）
- 真实事件取证与应急响应手册（含通报流程与加固方案，参照Sea Turtle/DNSpionage等案例）
本节参考来源（第1页）
以下均为真实可查的权威来源（IETF RFC、NIST、ICANN、MITRE/CTI、学术与厂商威胁报告），用于支撑本页事实性表述。
P. Mockapetris, "Domain Names - Concepts and Facilities" (RFC 1034) 与 "Domain Names - Implementation and Specification" (RFC 1035), IETF, 1987：datatracker.ietf.org/doc/html/rfc1034
R. Arends et al., "DNS Security Introduction and Requirements" (RFC 4033)、"Resource Records for the DNS Security Extensions" (RFC 4034)、"Protocol Modifications for the DNS Security Extensions" (RFC 4035), IETF, 2005：RFC 4033/4034/4035
NIST SP 800-81《Secure Domain Name System (DNS) Deployment Guide》（DNS安全部署指南）：csrc.nist.gov SP 800-81
FBI, "Operation Ghost Click" / DNSChanger 行动（2011-11-08公开，2012-07-09"DNS Changer黑名单"关停）：en.wikipedia.org/wiki/DNSChanger（FBI"Operation Ghost Click"行动条目，含司法部起诉书与DCWG数据）
Cisco Talos, "Sea Turtle: DNS hijacking abuse of trust" (2019-03)、"DNSpionage"系列报告：blog.talosintelligence.com/sea-turtle
APNIC / Internet Society, "Measuring DNSSEC" 系列测量（全球验证解析器占比估计，约20%—30%，因测量方法而异）：stats.labs.apnic.net/dnssec
ICANN SSAC, "DNS Security Threats and Mitigation" 相关报告（SAC系列）：icann.org/groups/ssac
Z. Niaki et al., "Quantitative Investigation of the DNS Injection Attack" (IMC 2018/后续扩展)，量化多国DNS注入：USENIX IMC 2018