DNS 科普·DNS 安全

上回我们说到 DNS 的基本知识以及 DNS 劫持的科普，那么 DNS 安全上又有哪些措施呢？

加密通信

如同 HTTP 通信一样，默认的 DNS 查询同样也是明文的，那么必然也可能遭受到攻击，比如下图中表示了一次中间人攻击（图源 cloudflare）：

那么同样的，我们也可以通过加密流量的方式来保证数据的可靠性。对于 DNS 来说，主要有 DoT 和 DoH 两种。

DoT (DNS over TLS) 意味着信道会基于 TLS(SSL) 进行加密传输，而 DoH（DNS over HTTPS）则是基于 HTTPS / HTTP2 进行数据加密传输的。当然，除了这些以外，还新推出了一个叫做 DoQ 的（DNS over QUIC）

从 DoT 到 DoH 到 DoQ，为什么会产生不同的设计和演进呢？

DoQ 的产生相对的比较好理解，毕竟我们可能已经读过太多关于 HTTP2 究竟还有哪些待解决的问题，而 DoQ 又改善了其中的哪些点这类的文章：比如「减少 TCP 三次握手及 TLS 握手时间」、「改进拥塞控制」等等，关于 QUIC 暂不在本文的讨论范围中，因此不做过多赘述。

而从 DoT 到 DoH 的演进和选择则更让人迷惑：加密一下不就够了，为什么还需要基于 HTTP 协议呢，HTTP 协议设计的更为复杂，不够轻量，仿佛会增加通信的成本，增加数据包的大小（比如存在一些不必要的 HTTP Headers）。

他们同时产生并且不被淘汰的原因更多的是安全隐私之间的取舍，TLS 使用 853 端口，而 HTTPS 使用 443 端口，试想一下，当我们需要进行针对性的流量审计时，如果我们有一个明确的端口号特征，是不是更容易受到管控和监听？

而如果使用 443 流量，DNS 查询的流量就被混在了万千普通 HTTPS 连接中，对于用户来说，隐私加密性更高。

加密了通道，我们就可以避免在 DNS 查询期间被偷天换日了。

HTTPDNS

但是很明显，上面所有的防御手段并不能防止所谓的 DNS 劫持——如果作妖的不是中间商，而是服务器本身呢？

而 HTTPDNS 选择绕过 DNS 本身，直击灵魂深处：使用 HTTP + IP Port 请求 HTTPDNS 服务器，由它直接返回内容，减少中间商赚差价的情况。

回忆一下我们原来的链路设计，假设完全没用缓存，需要经过 10 步，用户才能最终拿到 IP。（请见上一篇文章：DNS 科普·从 DNS 到 DNS 劫持）

而在 HTTPDNS 中，假设我们的 HTTPDNS 服务器 IP 为 6.6.6.6，只要告诉他需要查询的域名（codesky.me），HTTP Response 中就会告诉你对应的 IP。

当然，这本身并不是 DNS 协议的一部分，而是为了避免劫持污染问题应运而生的一项「应用服务」。因此在实际使用 HTTPDNS 时，往往会同时提供一些注入：「SDK」、「软件」等工具，来保证「先请求 HTTPDNS 服务器，再带着 IP 直达业务链接」。
如果我们用 curl 来模拟请求，相当于用户从原来的一次：

curl https://codesky.me/search

变成了：

curl https://6.6.6.6?domain=codesky.me # 返回 1.2.3.4
curl https://1.2.3.4/search -H "Host: codesky.me" # 直接用 IP-Port 访问

总结

说完了这一部分，DNS 的科普之旅暂时告一段落，由于近期工作比较忙，跑医院也比较多，MySQL 笔记只整理了 40%，正在努力。

如果有其他前后端方面希望我讨论（科普）的话题，欢迎留言。

参考资料

• DNS over Dedicated QUIC Connections：https://datatracker.ietf.org/doc/html/rfc9250