DNSSEC通过数字签名验证DNS响应真实性和完整性，确保IP地址来自合法权威服务器，篡改后签名失效；需域名注册商、权威DNS及客户端协同启用验证，并配置信任锚与DS记录。
要保障域名解析真实可信，关键不是“堵住所有漏洞”，而是构建多层验证与加密机制，让劫持行为在发起、传播或生效环节就被识别或阻断。核心思路是：加密传输路径、验证数据来源、固化可信锚点。
启用 DNSSEC 验证
DNSSEC 不是加密查询内容，而是为 DNS 响应添加数字签名，确保返回的 IP 地址确实来自该域名的合法权威服务器。一旦响应被篡改，签名验证失败，解析器将拒绝使用该结果。
- 操作系统层面：Windows 10/11 和较新版本 Linux（如 systemd-resolved）支持 DNSSEC 验证，需在 DNS 配置中启用“DNSSEC validation”选项；macOS 则依赖第三方解析器（如 dnsmasq + unbound）实现。
- 路由器/网关设备：部分企业级路由器（如 OpenWrt 搭配 dnsmasq 或 Knot Resolver）可开启 DNSSEC 验证并作为局域网统一出口校验节点。
- 注意：仅当域名注册商和权威 DNS 提供商（如 Cloudflare、阿里云 DNS）已为其域名启用 DNSSEC 签名时，验证才有效。用户需确认目标域名的 DS 记录已在父域（如 .com）中发布。
切换至加密 DNS 协议（DoH / DoT）
传统 DNS 使用明文 UDP 查询，中间网络设备（如路由器、ISP）可轻易监听或伪造响应。DoH（DNS over HTTPS）和 DoT（DNS over TLS）将查询封装进加密通道，防止窃听与中间人篡改。
- 推荐公共加密 DNS 服务：Cloudflare（1.1.1.1，支持 DoH/DoT）、Quad9（9.9.9.9，启用恶意域名过滤+DoT）、CleanBrowsing（安全家庭版，DoH）。
- 浏览器级启用：Firefox 默认启用 DoH（可配置为 Cloudflare 或 NextDNS）；Chrome 和 Edge 支持手动开启 DoH（设置 → 隐私与安全 → 安全 → 使用安全 DNS）。
- 系统级部署：Windows 可通过组策略或 PowerShell 设置 DoT；Linux 用户可用 stubby 或 systemd-resolved 配置 DoT 上游。
固化本地解析信任链
避免依赖单一、易被篡改的 DNS 来源。通过组合本地控制与外部校验，压缩劫持生效空间。
- 禁用自动获取 DNS：在网卡设置中关闭“自动获得 DNS 服务器地址”，手动指定至少两个可信递归 DNS（如 114.114.114.114 + 223.5.5.5），并定期用 nslookup 或 dig 对比结果一致性。
- 清理并锁定 hosts 文件：检查 C:\Windows\System32\drivers\etc\hosts（Windows）或 /etc/hosts（macOS/Linux），删除异常条目；必要时设为只读（chmod 444 /etc/hosts）防止恶意软件写入。
- 路由器 DNS 强管控：登录路由器后台，关闭“从 ISP 获取 DNS”，固定填写可信 DNS 地址；同时修改默认管理员密码、禁用远程管理、关闭 UPnP，防止被远程篡改。
主动检测与响应机制
再强的防护也需配合可观测性——能及时发现异常，才能快速止损。
- 日常比对：访问可疑网站前，用在线工具（如 https://www.whatsmydns.net/ 或阿里云 DNS 检测）查看该域名在全球多个节点的解析 IP 是否一致；若仅本地异常，大概率已被劫持。
- 命令行快检：运行 nslookup example.com 8.8.8.8（强制走 Google DNS）与 nslookup example.com（走当前默认 DNS）对比结果；IP 不同即存在本地或网络层劫持。
- 企业环境建议部署 DNS 日志审计：通过 Pi-hole、Unbound 或商业 DNS 服务（如 Cisco Umbrella）记录全部查询请求与响应，结合时间、客户端 IP、返回 IP 的聚类分析，自动标记异常解析模式。
