再谈那些不正常的 DNS 行为

Cover Image

在上一篇文章简单围绕 DNS 解析行为与 CDN 实现,在评论区里好伙伴 木子 提醒我关注 DNS 劫持、污染等非常规行为 。这些不良手段还是有必要了解下细节,以及该如何避免。

非正常行为

DNS 劫持

如果通过某些手段获取 DNS 服务器的控制权,便可人为操纵查询结果。将结果指向修改过的 IP 地址,以实现访问导向假网址或者直接导致无法访问。

这种行为最常出现在 ISP 提供的免费 DNS 服务器上。有些 ISP 会对 DNS 投毒引导至自己的服务器上,降低外网压力,甚至植入广告获利。有些 ISP 会积极响应号召,将某些「不合适」的网站返回错误的解析结果。还有 ISP 调高 TTL 使 DNS 请求减少导致无法及时得到最新记录。

不仅时 ISP 专供 DNS,部分公网 DNS 也可能会有一些小手脚。

如果只是单纯 DNS 劫持还是比较容易解决的,选取一个合适的公共 DNS 即可。如 Cloudflare DNS (1.1.1.1, 1.0.0.1) ,或者 Google DNS (8.8.8.8, 8.8.4.4) ,这些国外互联网巨头一般不容易受到 某些组织 牵动,可以提供稳定的解析服务。

但绝大多数不正常 DNS 行为都不仅仅是 DNS 劫持,相比之下应对 DNS 污染更加麻烦。

DNS 污染

虽然有绝对正确的权威 DNS 服务器,但是为了加快查询效率,通常递归 DNS 服务器上会设置缓存机制,命中已缓存的域名便不再继续向上级查询。

如果我们回顾一下 DNS 解析流程,想访问网站就必须将域名转换为对应的 IP 地址。而目前主流 DNS 请求都是基于 UDP 连接,UDP 连接最大的问题就是没有一个可信的验证机制,查询也十分容易被悄无声息地篡改。

如果模拟一个被污染的域名解析请求,如 chralpha.com

  1. A 在浏览器中敲入此域名 chralpha.com,未命中缓存,便向 DNS 服务器 C 发起请求
  2. 在路由至 C 的途中需要许多中间设备转发,假设 B 是其中一台
  3. 由于 DNS 请求使用 53 端口的 UDP 连接,通过对这个端口查询流量进行入侵检测,一旦发现匹配到规则集中的链接便直接返回虚假结果
  4. 作为 A 至 C 链路上的一个节点,B 显然可以提前代替 C 返回错误结果给 A,而缺少验证机制也让 A 无法察觉
  5. A 收到错误的地址并发起请求,当然它得不到任何想要的结果

根据规定,查询者 A 只认第一个结果并丢弃后面的,由此肯定无法成功访问那些被关进小黑屋里的网站。

这样即便不用操控 DNS 服务商,通过在合适的路由上部署污染匹配机制也能让用户无法获得正确的 IP 地址。


对于 DNS 劫持而言,只要选取一个安全靠谱的公共 DNS 服务即可。主要来看看后者,DNS 污染的解决。不过除了一劳永逸的代理外,还有其他方法可供选择。

解决手段

DNSSEC

确实,当前互联网已经离不开 DNS。你访问的每一个网页、每一封电子邮件,都需要 DNS 将便于人们使用的域名转为便于机器识别的 IP 地址。

而 DNS 被设计出来之时,互联网规模远比现在小得多,其安全性也并未得到重视。无法做到真实性检验,导致查询结果,无论是递归 DNS 得到的还是用户收到的,都很容易被仿冒伪造。

事实上工作组早就意识到问题,也开始寻找解决方案,DNS 安全扩展(DNSSEC)便应运而生。

DNSSEC 使用 非对称加密算法 对加密进行数字签名,在原始 DNS 协议中新增了:

  • 数据来源验证:解析器可以通过加密的方式验证收到的数据是否确实来自其认定的数据传送区域。
  • 数据完整性保护:解析器可以确信,自区域所有者使用区域私钥初次进行数据签名以来,数据在传输过程中并未遭到修改。

这两项功能主要凭借新增的资源记录类型:DNSKEY (DNS Public Key) 实现。

问题又来了,既然使用私钥签名使得无法伪造查询结果,但是为了验证签名公钥必须一同公开下发。那对公钥动手脚,这样无法通过下方的公钥解开原本使用私钥加密的内容,而终端无法确认是公钥被篡改还是查询结果被伪造。这种不确定也使无法正常获取解析结果,虽然不能再导向另一个地址,但是至少无法获取 IP 是可以做到的。

解决方案是再对公钥进行一次加密,只不过不使用加密查询结果的私钥,而是每个区域特殊生成的密钥对。为了描述方便,下文简单称加密查询结果的公钥、私钥为「公钥」、「私钥」,称加密「公钥」的公钥、私钥为「区域公钥」、「区域私钥」。该公钥使用父区域的区域私钥签名,比如 chralpha.com 的公钥由 com 区域进行签名。父区域也负责核实子区域公钥真实性。这样按顺序一层一层形成 信任链,信任链顶端则是根区,根区自然无法再通过父区域私钥签名,而是通过有关责任机构背书。

由此,DNS 查询结果便不容易篡改了。但这只是保证了数据真实性,毕竟中间人只是不能伪造,但还是能查看查询内容,也依然能够根据规则拦截。所以,你不容易被骗,但是可以被捂住耳朵,压根得不到回应,自然也就无法连接。

DoT/DoH

DNSSEC 保证数据不被篡改已经迈出了很大一步,但是仍然能够被识别、被阻断。为此,IETF 小组提出两个加密 DNS 协议:DNS over TLS (DoT) 和 DNS over HTTPS (DoH)。

DNS over TLS (DoT) 通过传输层安全协议(TLS)加密打包整个 DNS 协议,从而防止中间人窃听、篡改。RFC 7858RFC 8310 定义了 DNS over TLS。

DNS over HTTPS (DoH) 也是一种安全化域名解析方案,但目前尚属于实验性阶段。DoH 通过 HTTPS 加密传输进行 DNS 请求,从而保证传输数据可靠性和隐私性。当前,该方案由 IETF 支持,其规范文档以 RFC 8484 的名义发布。

由于 HTTPS 需要经过多次数据传输才能完成验证,所以 DoH 域名解析耗时会显著增加。而在实验性阶段,目前直接对 DoH 支持的终端设备较少,通常需要在本地系统或者本地网络服务器上安装 DoH 代理。当然,使用的 DNS 服务器也必须支持 DoH 才行,下图为部分公共 DNS 支持情况。

乍一看 DoT 与 DoH 好像挺相似,毕竟 HTTPS 就是应用了 SSL/TLS 加密协议的 HTTP 传输协议,但是这两者区别明显。DoT 使用基本 TCP 连接而 DoH 使用 HTTP 与 HTTP/2 连接;DoT 使用自己 853 端口连接而 DoH 使用标准 443 端口连接。这样 DoH 可以伪装成一般的 HTTP 流量,加密后他人也无从知晓里面究竟是什么。而 DoT 使用唯一 853 端口,至少中间人可以知道这是 DNS 请求,尽管他们也无法获得请求内容,所以也不敢随便封禁。

关于「DoT or DoH」的问题一直争论不休。DNS 架构师 Paul Vixie 曾在社交媒体上表态:

“RFC 8484 会给互联网安全带来隐患。抱歉向您泼了冷水。就像一群鸭子一样,囚犯们找到了庇护所。”

“DoH 是企业和其他私有网络的过顶旁路。但是DNS是控制平面的一部分,网络运营商必须能够监视和过滤它。使用 DoT,永远不要使用 DoH。”

然而这场辩论双方都有正当理由,只是取舍不同。DoT 更有利于网络安全,而 DoH 则比较倾向「人权保护」。事实上共识还是存在的,没有人认为 DNS 请求不应被加密,只不过对如何做得更好有不同意见。

代理下的 DNS 行为

即便解决了 DNS 污染等,依旧无法保证能够畅通连接互联网,使用代理才是正解。不过本文不会剖析代理行为,只聚焦 代理下的 DNS 行为

在上一篇文章「浅谈 DNS 解析与 CDN 原理」中已经介绍了 DNS 解析流程,不过都是默认 直连 下的请求。而在代理环境下还是有许多差别,还是拿 chralpha.com 举例:

  1. 假设已经通过 某种协议 与代理服务端建立通信,由于这种协议与 SOCKS5 一样支持将域名封装在传输中
  2. 由于本地已经建立好代理,浏览器可以直接将域名 chralpha.com 封装在 SOCKS5 流量内发送至代理客户端
  3. 代理客户端通过 SS 将从浏览器收到的流量整理后发给代理服务端
  4. 代理服务端同样使用 SS 解析流量内信息,从中获取域名 chralpha.com
  5. 代理服务端对 DNS 服务器发起 chralpha.com 的查询请求,通常这是在代理服务端上完成的,也就是代理服务端负责 DNS 解析

代理服务端 DNS 解析与普通 DNS 解析并无差异。以上便是在代理环境下的一次 DNS 流程,后续得到 DNS 查询结果,代理服务端再对得到的 IP 发起请求,并将请求结果用 某种协议 发送回本地,完成一次访问。

当然,如果在本地部署关于 IP 的分流策略,那么代理客户端便会收到浏览器发来的流量后抽取域名,并在本地先执行一次 DNS 解析。如果判断无需代理,那么通常会直接复用这个查询到的 IP 发起请求;否则,仍然是将域名封装送往代理服务端,而代理服务端会对这个域名再次发起 DNS 查询,这次查询不受之前代理客户端查询影响,往往也能得到正确的结果。

所以,「代理环境下无视 DNS 污染」是有一定道理的。这也是为什么在解锁失效时推荐使用白名单或全局代理——将更多行为转交代理服务端完成。

据自由之家(Freedom House)数据显示,全球只有不到四分之一用户生活在被定义为互联网自由的地区,许多地区都对互联网过多干涉。

数字权利同为人的基本权利,相信对这一权利的追随定会让更多技术得以出现。所以,后续 DNS 一定会越来越安全,我们也定能享受技术带来的安逸。

再谈那些不正常的 DNS 行为
本文作者
ChrAlpha
最后更新
2020-04-13
许可协议
转载或引用本文时请遵守许可协议,注明出处、不得用于商业用途!

评论

您所在的地区可能无法访问 Disqus 评论系统,请切换网络环境再尝试。