局域网 DNS 欺骗：识别、防护与账号应急

登录页面长得一样，不能证明你到了同一个地方。

连上公共 WiFi，打开网站却跳到了“重新认证”页面；或者平时正常的网站突然提示证书错误。这些现象值得停下来检查，但单凭一次跳转，还不能断定遇到了 DNS 欺骗。网络确实需要认证、网站证书过期、本机时间错误，都可能造成相似现象。

这篇笔记从使用者的角度整理：哪些信号需要警惕，怎么缩小问题范围，以及已经填过密码后应该做什么。

DNS 改了地址，HTTPS 还会检查身份

DNS 负责把域名解析为地址。DNS 欺骗可能通过伪造解析响应、污染缓存，或篡改设备与路由器的 DNS 设置，让用户连接到错误的服务器。

把它理解成“谁离得近、谁先回答就听谁的”并不准确。DNS 响应有匹配和校验规则，解析器也可能进行 DNSSEC 验证；具体风险取决于网络位置、实现和配置。局域网里的地址解析、DNS 域名解析，以及浏览器显示的网页，是不同环节。

假设你访问 https://login.example.com，DNS 却给出了错误地址。浏览器建立 HTTPS 连接时，仍然要检查服务器证书是否可信、是否匹配 login.example.com。仅仅改变 DNS 结果，并不能自动获得这个域名的有效服务器身份。 证书不匹配或不受信任时，浏览器通常会阻止连接或显示警告，不应该靠点击“继续访问”来解决。

这里还有个容易漏掉的条件：钓鱼页面可以使用它自己域名的有效 HTTPS 证书。浏览器确认的是“当前域名的连接”，不会替你判断这个域名是不是学校、银行或公司的官方入口。所以既要看证书警告，也要核对地址栏。

遇到可疑页面，先停止提交

登录失败时反复输密码，很容易把故障排查变成反复泄露。可以先按下面几个信号判断：

校园和企业网络可能有合法的认证入口。确认方式应当来自校园官网、管理员公布的说明等独立渠道，不要只使用可疑页面自己提供的联系方式。普通上网认证也不应索要你在其他平台使用的密码或验证码。

把问题缩小到设备、网络或网站

排查时保留出错时间、完整域名和证书错误信息即可。截图发给管理员前，遮住账号、验证码和其他个人资料。

对比可信网络，但别只比较一个 IP

断开可疑 WiFi，用移动网络访问同一个官方地址。如果移动网络正常，而该 WiFi 下持续异常，问题范围就缩小到了这条网络链路。这个结果仍不能单独证明有人攻击，还可能是网络认证或 DNS 配置错误。

在安装了相应工具的电脑上，可以查看域名解析结果：

nslookup example.com

把 example.com 换成需要排查的域名。输出中的 DNS 服务器和解析地址可以提供线索，但 CDN、地域调度和缓存都会让不同网络得到不同 IP。IP 不一致是排查起点，不能直接当作被劫持的证据。

检查自己的设备与路由器

如果同一 WiFi 下只有一台设备异常，检查这台设备近期新增的代理、浏览器扩展、网络配置，以及 hosts 文件中是否出现不认识的记录。Windows 的文件位置通常是 C:\Windows\System32\drivers\etc\hosts，Linux 是 /etc/hosts。先确认记录用途，不要把单位配置一并删除。

如果多台设备都异常，检查自己管理的路由器：DNS 设置是否被更改，管理员密码是否仍是默认值，是否开着不需要的远程管理，固件有没有安全更新。路由器使用私有地址充当 DNS 转发器很常见，仅凭 192.168.x.x 不能判断它恶意。

学校、公司和公共场所的网络应由管理员处理。提交现象、时间和错误信息，比自己反复修改网络参数更有助于定位。

防护各管一段，不能互相替代

HTTPS、加密 DNS 和 DNSSEC 经常一起出现，但各自处理的问题不同：

• HTTPS：验证所访问服务的身份，并加密与该服务之间的连接。前提是域名正确、证书验证没有被绕过，设备本身也可信。
• DoH / DoT：加密设备到所选 DNS 解析服务之间的查询链路。仍需要信任所选解析服务，也不会修复已经被篡改的浏览器或系统。
• DNSSEC：通过签名验证 DNS 数据的来源和完整性，需要域名正确部署签名、解析端执行验证。它不负责加密网页内容，也不能证明网站经营者可信。

日常防护更实际的做法是：保持系统和浏览器更新，使用可信的网络与 DNS 配置，不忽略证书警告，给不同账号使用不同密码，并开启多因素认证。在学校或企业网络启用加密 DNS 前，也要确认内部域名和网络认证是否兼容。

不要长期把网站 IP 写死进 hosts 当成修复。地址可能变化，这样做也绕不过 HTTPS 的身份检查。手动换 DNS 只对部分问题有效；如果设备、路由器或账号已经失陷，还需要处理对应环节。

已经输入密码，按账号泄露处理

恢复网页访问和保护账号是两件事。即使后来能正常上网，也不能据此判断刚才提交的密码没有被保存。

1. 换到可信设备和网络。 从官方地址进入账号安全页面，修改刚才提交的密码。无法登录时，使用平台的官方恢复流程。
2. 处理复用密码。 其他网站如果用了同一个密码，也要分别更换。邮箱尤其重要，因为它常被用来接收其他账号的重置链接。
3. 检查登录状态和恢复设置。 注销陌生设备或会话，核对恢复邮箱、手机号和第三方授权；邮箱还要检查异常转发规则。不要假定改密码会自动撤销所有会话和授权。
4. 开启多因素认证。 平台支持时，可以使用通行密钥或安全密钥等方式。已经在可疑页面提交过验证码的，也要检查当前登录会话。
5. 通知相关服务的管理者。 校园统一身份账号可能关联多个系统，应联系学校信息部门协助检查；涉及支付或个人资料异常时，及时联系对应服务并保留证据。

可疑页面如果还要求下载并运行程序，问题就可能超出密码泄露，需要继续检查设备安全。不要在同一台疑似失陷的设备上把所有新密码又输入一遍。

DNS 异常不总是攻击，熟悉的页面也不总是可信。先停下提交、核对入口，再把网络故障和账号风险分开处理，通常比急着“让页面恢复正常”更有用。

参考资料

• IETF RFC 9525：TLS 服务身份验证：客户端如何核对预期身份与服务器证书。
• Cloudflare：DNSSEC：DNS 签名及部署条件。
• Google Public DNS：DNS over HTTPS：加密查询与 DNSSEC 验证的区别。
• Google：保护被入侵或盗用的账号：异常登录、恢复设置和关联服务的处置。
• Information Security Stack Exchange：为什么 DNS 欺骗不能直接冒充 HTTPS 站点？：用于理解问题边界；具体 TLS 身份验证规则以 RFC 9525 为准。

可用性说明：本文发布于 2020 年 6 月，距今已超过五年。文中涉及的软件版本、接口、下载地址、命令参数和操作界面可能已经发生变化，部分方案在当前环境下可能失效。请结合官方最新文档核对后再操作，生产环境使用前务必先行验证。