1. 前言

本文介绍DNS相关内容和DNS相关安全风险，最后整理当前DNS安全相关方案。

2. DNS简介

DNS是一个域名系统。早期人们访问一个网站，需要输入该网站的IP地址，IP地址不好记忆，又容易输错，于是就有了域名。

有了域名之后，人们只需要输入域名，就能访问目标网站。虽然在浏览器中输入的是域名，但实际上是访问了目标网站的IP地址，怎么做到的呢？答案是DNS解析。它作为将域名和IP地址相互映射的一个分布式数据库，能够使人更方便地访问互联网。

在互联网发展早期，主机和 IP 地址信息存储在由斯坦福研究所 [SRI] 维护的文本文件 [HOSTS.TXT] 中。当新计算机加入网络或旧计算机修改其详细信息时，人们必须联系 SRI 并手动更新此文件。任何需要计算机 IP 地址的人也必须联系 SRI 并获取更新的文件。这带来了一个大问题，因为它会在工作日五点关闭，而在节假日不开放。这使得获取文件的工作变得非常困难。于是保罗·莫卡派乔斯提出了一个分布式动态命名系统，本质上是今天的 DNS。DNS 的出现解决了分布式数据库的这个问题。

DNS（域名系统）可以简单地理解为一个全球化分布式数据库，将Web站点URL和一个IP地址相匹配，控制着Internet上所有传输流的路由，包括几十亿记录，平均每天对几十亿的查询作出应答并接受来自上百万用户的上百万次更新。

DNS使用TCP和UDP端口53。

浏览器缓存——》系统hosts文件——》本地DNS解析器缓存——》本地域名服务器（本地配置区域资源、本地域名服务器缓存)——》根域名服务器——》主域名服务器——》下一级域名域名服务器 客户端——》本地域名服务器（递归查询) 本地域名服务器—》DNS服务器的交互查询是迭代查询。

3.DNS安全相关问题

3.1 DNS劫持（偷）

由于恶意攻击者控制了你的网关或其他中间网络设备，当你发送了一个查找freebuf.com的IP的请求的时候，中间人拦截住，并返回给你一个恶意网址的IP,你的浏览器就会把这个IP当做你想要访问的域名的IP!!这个IP是攻击者搭建的一个模仿了目标网站前端界面的界面，当你在该界面输入用户名密码或者付款操作的时候，就会中招。

由于DNS劫持导向的界面的ＵＲＬ是完全正确的，因此 这类攻击一般极难分辨！

3.1.1 本地DNS劫持

客户端侧发生的DNS劫持统称为本地DNS劫持。本地DNS劫持可能是：

1. 黑客通过木马病毒或者恶意程序入侵PC，篡改DNS配置(hosts文件，DNS服务器地址，DNS缓存等)。
2. 黑客利用路由器漏洞或者破击路由器管理账号入侵路由器并且篡改DNS配置。
3. 一些企业代理设备（如Cisco Umbrella intelligent proxy）针对企业内部场景对一些特定的域名做DNS劫持解析为指定的结果。

3.1.2 DNS解析路径劫持

DNS解析过程中发生在客户端和DNS服务器网络通信时的DNS劫持统一归类为DNS解析路径劫持。

DNS请求转发：通过技术手段(中间盒子，软件等)将DNS流量重定向到其他DNS服务器。

DNS请求复制：利用分光等设备将DNS查询复制到网络设备，并先于正常应答返回DNS劫持的结果。

DNS请求代答：网络设备或者软件直接代替DNS服务器对DNS查询进行应答。

3.1.3 篡改DNS权威记录

篡改DNS权威记录 我们这里指的黑客非法入侵DNS权威记录管理账号，直接修改DNS记录的行为。黑客黑入域名的管理账户，篡改DNS权威记录指向自己的恶意服务器以实现DNS劫持。

3.2 DNS放大攻击（打）

这种 DDoS 攻击是基于反射的大规模分布式拒绝服务 (DDoS) 攻击，其中，攻击者利用开放 DNS 解析器的功能产生大量流量，使目标服务器或网络不堪重负，导致服务器及其周围基础设施无法访问。

所有放大攻击都利用攻击者和目标 Web 资源之间的带宽消耗差异。当消耗差异经过多次请求而被放大时，所产生的流量可导致网络基础设施中断。通过发送小型请求来导致大规模响应，恶意用户就能达到四两拨千斤的效果。当通过某个僵尸网络中的每个自动程序都发出类似请求来使这种放大效果倍增时，攻击者既能躲避检测，又能收获攻击流量大增的好处。

在 DNS 放大攻击中，其中一个机器人好比是一个心怀恶意的青少年打电话给一家餐厅，说“我要每样东西点一份，请给我回电话，告诉我整个订单”。当餐厅询问回电号码时，提供的是目标受害者的电话号码。然后目标会接到来自餐厅的电话，提供其并未请求的大量信息。

由于每个自动程序向开放 DNS 解析器提出请求时都提供欺骗性 IP 地址，也就是目标受害者的真实源 IP 地址，目标随后会收到来自 DNS 解析器的响应。为了产生大量流量，攻击者会以某种方式来构造请求，以便让 DNS 解析器产生尽可能大的响应。因此，目标接收攻击者的初始流量的放大结果，其网络被虚假流量堵塞，导致拒绝服务。

3.3 DNS缓存污染（骗）

目前DNS采用UDP协议传输查询和应答数据包，采用简单信任机制，对首先收到的DNS应答数据包仅进行原查询包发送IP地址、端口和ID的确认，而不会对数据包的合法性做任何分析，若匹配，则接受其为正确应答数据包，继续DNS解析过程，并且丢弃后续到达的所有应答数据包。攻击者可以仿冒权威DNS服务器向缓存DNS服务器发送伪造应答包，力争抢先完成应答以污染DNS缓存。若攻击者发送的伪造应答包在权威名字服务器发送的正确应答包之前到达缓存DNS服务器，并与原查询包IP地址、端口、ID相匹配，就能够成功污染DNS缓存。DNS递归服务器向该域的权威服务器发送查询。正是在这一点上，攻击者用大量伪造的响应来淹没正常应答，每个伪造的响应都有不同的伪造ID号。如果攻击者成功注入伪造响应，则递归DNS服务器将为权威服务器缓存错误的IP。对受感染域的递归DNS服务器的未来 DNS 查询将导致所有请求被转发到攻击者控制器权威解析器，使攻击者能够提供恶意响应，而无需为每个新 DNS 记录注入假条目。

GFW(Great Wall of China)至少使用了两种DNS劫持机制：

1，GFW对国内DNS服务器进行了缓存污染， 这种污染体现在使用国内DNS服务器对twitter进行解析会得到稳定的、虚假的IP地址；

2，GFW会拦截和应答试图从国内发往国外的DNS解析请求（也可能是对国外DNS服务器 的应答进行了篡改）。

4. DNS安全措施

传统的 DNS 是一个【比较古老】的协议。最早的草案可以追溯到1983年。1987年定稿之后，基本上没啥变化。算起来，它的年龄比俺博客的很多读者都要大。

设计 DNS 的时候，互联网基本上还是个玩具。那年头的互联网协议，压根儿都没考虑安全性，DNS 当然也不例外。所以 DNS 的交互过程全都是【明文】滴，既无法做到“保密性”，也无法实现“完整性”。

缺乏“保密性”就意味着 — — 任何一个能【监视】你上网流量的人，都可以【看到】你查询了哪些域名。直接引发的问题就是隐私风险。

缺乏“完整性”就意味着 — — 任何一个能【修改】你上网流量的人，都可以【篡改】你的查询结果。直接引发的问题就是“DNS 欺骗”（也叫“DNS 污染”或“DNS 缓存投毒”）

4.1 DNSSEC

这玩意儿是“Domain Name System Security Extensions”的缩写。在今天介绍的4个协议中，DNSSEC 是最早诞生的（1997）。从最先的 RFC 2065 进化为 RFC 2535，再到 RFC 4033、RFC 4034、RFC 4035。

在今天介绍的4个协议中，DNSSEC 也是最早大规模部署的。在2010年的时候，所有根域名服务器都已经部署了 DNSSEC。到了2011年，若干顶级域名（.org 和 .com 和 .net 和 .edu）也部署了 DNSSEC。

当初设计 DNSSEC 的一个考虑是“尽可能兼容 DNS 协议”。所以 DNSSEC 只是在 DNS 协议的基础上增加了一个【数字签名机制】。

有了数字签名，如果域名查询的结果被人篡改了，DNSSEC 客户端就可以通过【校验签名】，判断查询结果是假的。套用信息安全的行话 — — DNSSEC 实现了【完整性】（也叫“不可篡改性”）。

由于 DNSSEC 引入了【数字签名】，就需要有【公私钥对】。私钥是保密的，用来生成签名；公钥是公开的，用来验证签名。DNSSEC 客户端可以向 DNSSEC 服务器发出请求，获得一个 DNSKEY 记录，里面含公钥；然后用这个公钥校验每次的查询结果。

优点：DNSSEC 应该是最成熟的，多数公共的域名服务器也都支持它。

缺点：虽然 DNSSEC 最成熟，但它有个天生的缺陷 — — 【没有】考虑到【保密性】。

DNSSEC 虽然对传输的数据做了数字签名，但是【没有】进行加密。这就意味着 — — 任何能监视你网络流量的人，也可以看到你通过 DNSSEC 查询了哪些域名。隐私风险大大滴！

Chrome 曾经在 14 版本支持过 DNSSEC，后来又【移除】了；而 Firefox 官方从未支持过 DNSSEC 协议。

4.2 DNSCrypt

 DNSCrypt。这个协议是由 Frank Denis 和 Yecheng Fu（付业成）两人设计的。

这个协议从来【没有】提交过 RFC（征求意见稿），要想看它的协议实现，只能去它的官网（链接在“这里”）。

历史上有过两个版本，分别称：Version 1 和 Version 2。如今主要使用“版本2”

优点：前面俺提到 DNSSEC 协议强调兼容性。而 DNSCrypt 则完全是另起炉灶搞出来的协议。在这个协议中，域名的“查询请求”与“响应结果”都是加密的。这就是它比 DNSSEC 高级的地方。

换句话说，DNSCrypt 既能做到【完整性】，也能做到【保密性】；相比之下，DNSSEC 只能做到【完整性】。

如前所述，DNSCrypt 同时支持【完整性】与【保密性】。在隐私方面完胜 DNSSEC。

在下层协议方面，DNSCrypt 同时支持 TCP 和 UDP，显然比 DNSSEC 灵活（DNSSEC 只支持 UDP）。

缺点：DNSCrypt 最大的缺点就是前面提到的：从未提交过 RFC。没有 RFC 也就无法通过 IETF（互联网工程任务组）进行标准化。一个无法标准化的协议，其生命力要打很大的折扣。

另一个比较小的缺点是 — — 虽然 DNSCrypt 协议是加密的，但可以被识别出来。换句话说：如果有人监控你的流量，可以识别出哪些流量属于 DNSCrypt 协议。

4.3 DoT

DNS over TLS”有时也被简称为【DoT】。DoT 已经正式发布了 RFC（参见 RFC 7858 和 RFC 8310）。

从时间上看，RFC7858 是2016年发布的，RFC8310 是今年（2018）发布的；显然，这个协议出现得比较晚（相比前面提到的 DNSSEC 和 DNSCrypt）。顾名思义，DNS over TLS 就是基于 TLS 隧道之上的域名协议。由于 TLS 本身已经实现了【保密性】与【完整性】，因此 DoT 自然也就具有这两项特性。DoT 的信任链依赖于 TLS，而 TLS 的信任链靠的是 CA 证书体系。

优点：相比 DNSSEC，DoT 具备了【保密性】；相比 DNSCrypt，DoT 已经标准化。

缺点：支持 DoT 的客户端还不够多。Dot默认使用853端口，在终端容易被识别。

4.4 DoH

“DNS over HTTPS”有时也被简称为【DoH】。

顾名思义，DNS over HTTPS 就是基于 HTTPS 隧道之上的域名协议。而 HTTPS 又是“HTTP over TLS”。所以 DoH 相当于是【双重隧道】的协议。

与 DoT 类似，DoH 最终也是依靠 TLS 来实现了【保密性】与【完整性】。DoH 类似于 DoT，最终是靠 TLS 所使用的“CA 证书体系”来实现信任链。

优点：基本上，DoT 具备的优点，DoH 也具备。

相比 DoT，DoH 还多了一个优点：

由于 DoH 是基于 HTTP 之上。而主流的编程语言都有成熟的 HTTP 协议封装库；再加上 HTTP 协议的使用本身很简单。因此，要想用各种主流编程语言开发一个 DoH 的客户端，是非常容易滴。

由于 DoH 协议是完全包裹在 TLS 里面，即使有人监视你的上网流量，也无法判断 — — 哪些 HTTP流量是用于域名查询，哪些 HTTP 用于网页传输。换句话说，DoH 协议的流量无法被【单独识别】出来。

缺点：

相比 DoT，DoH 还有一个小缺点 — — 由于 DoH 比 DoT 多了一层（请对比两者的协议栈），所以在性能方面，DoH 会比 DoT 略差。

5.常见加密DNS

阿里DNS 阿里公共DNS (alidns.com)

腾讯DNS DoH 与 DoT 说明 - DNSPod 服务与支持

360DNS 360安全DNS

Google DNS DNS-over-HTTPS (DoH)  |  Public DNS  |  Google Developers