DNS 域名劫持

dns

DNS

DNS（Domain Name System）域名解析系统

权威DNS

开发者可以在权威DNS上配置、变更、删除具体域名的对应解析结果信息
比如：dnspod，阿里云解析

递归DNS

递归DNS又称为Local DNS，它没有域名解析结果的决定权，但代理了用户向权威DNS获取域名解析结果的过程

公共DNS

公共DNS是递归DNS的一种特例，它是一种全网开放的递归DNS服务，而传统的递归DNS信息一般由运营商分发给用户。

域名

根域、顶级域、二级域
DNS系统一般采用树状结构进行组织，以www.boohee.com为例，com为顶级域名，boohee为二级域名，www为三级域名，域名树状组织结构如下图所示。

DNS解析过程

1、192.168.1.74 在浏览器访问 http://www.boohee.com
2、192.168.1.74 检查本地 hosts 文件中是否存在 www.boohee.com 对应的 IP
3、若无，192.168.1.74 继续检查本地 DNS 缓存中是否存在 www.boohee.com 对应的 IP
4、若无， 192.168.1.74 向本地 DNS 服务器发起 DNS 查询请求
5、路由器接收到 DNS 查询请求后，检查路由器 DNS 缓存
6、若无，路由器以外网地址 58.246.136.4 向本地 DNS 服务器 （ISP DNS）发起 DNS 查询请求
7、ISP DNS 接收到 DNS 查询请求后，发现自己不是权威 DNS ，且无对应的缓存数据，于是将请求转发给 其他 DNS 服务器
8、其他 DNS 服务器 接收到请求后，一样发现自己不是权威 DNS，且无对应的缓存数据，于是开始进行 DNS 迭代查询：将请求发送给 根域名服务器
9、根域名服务器 接收到请求后，将 顶级域名服务器 (.com) IP 发送给 其他 DNS 服务器
10、其他 DNS 服务器 根据 IP 将 DNS 查询请求发送给 顶级域名服务器
11、顶级域名服务器 接收到请求后，将 二级域名服务器 (boohee.com) IP 发送给 其他 DNS 服务器
12、其他域名服务器 根据 IP 将 DNS 查询请求发送给 二级域名服务器
13、二级域名服务器 接收到请求后，发现自己是权威 DNS 服务器，于是将 www.boohee.com 映射的 IP 140.207.194.83 发送给 其他域名服务器
14、其他域名服务器 接收到解析结果后，将 140.207.194.83 逐层返回传递下去，最终直至 192.168.1.74
15、192.168.1.74 接收到 www.boohee.com 解析结果 140.207.194.83 ，根据 IP 与 www.boohee.com 建立 TCP 连接，然后发起 HTTP 请求主页内容

/etc/hosts

早期网络尚未流行且计算机数量不多时，/etc/hosts 倒是还够用的，但自从 90 年代网络热门化后，单一档案 /etc/hosts 的联网问题就发生上面讲的状况啦！为了解决这个日益严重的问题，柏克利大学发展出另外一套阶层式管理主机名对应 IP 的系统， 我们称它为 Berkeley Internet Name Domain, BIND,这也是目前全世界使用最广泛的领域名系统 (Domain Name System, DNS)

传统的域名解析面临的问题

通过上面的介绍，我们已经了解了域名解析的基本概念和整体流程，那传统的域名解析存在一些什么问题了？

域名劫持

域名劫持一直是困扰许多开发者的问题之一，它的主要表现是域名A应该返回的DNS解析结果IP1被恶意替换为了IP2，导致A的访问失败或访问了一个不安全的站点。

黑客攻击

1、黑客侵入了宽带路由器并对终端用户的Local DNS进行篡改，指向黑客自己伪造的Local DNS
2、由于DNS解析主要是基于UDP协议，攻击者还可以监听终端用户的域名解析请求，并在Local DNS返回正确结果之前将伪造的DNS解析响应传递给终端用户

缓存污染

域名解析请求时，Local DNS首先会查找缓存，如果缓存命中就会直接返回缓存结果，不再进行递归DNS查询。这时候如果Local DNS针对部分域名的缓存进行更改，比如将缓存结果指向第三方的广告页，就会导致用户的访问请求被引导到这些广告页地址上。
对比第一种攻击，缓存污染往往能带来更明显的群体伤害
这类缓存污染行为往往是间歇性、局部性发生的，没有明显的规律，导致开发者很难对其进行量化、评估、预防

tips：
HTTPS 是不可以避免域名劫持的问题.
why？

调度不精准

对于类似CDN域名访问这类需要按地域、运营商进行智能解析调度的场景，精准调度的诉求是十分强烈的。
部分Local DNS供应商为了降低运营成本，会将请求到自己节点的域名解析请求转发给其他供应商的Local DNS节点

如果不同运营商之间相隔很远，那用户分配到的CDN节点就相距很远，大大增加业务访问延迟，同时CDN白用了

Local DNS的布署情况同样影响着域名智能解析的精准性。

部分运营商Local DNS的布点受成本因素制约分布并不均匀，比如在东部地区部署比较密集，但在西部地区部署比较稀疏。

解析生效滞后

在某些特定的情况下，开发者对域名解析结果变更的生效时间非常敏感，比如服务器受到攻击，需要切换业务IP。但是各个地区的运营商服务器质量参差不齐，甚至有些运营商为了节省开支忽略了域名解析结果的TTL时间限制，导致用户在权威DNS变更的解析结果全网生效的周期非常漫长（有的最长生效时间甚至高达48小时）。这类延迟生效可能直接导致用户业务访问的异常。

延迟大

DNS首次查询或缓存过期后的查询，需要递归遍历多个DNS服务器以获取最终的解析结果，这增加了网络请求的前置延时时间。特别是在移动互联网场景下，移动网络质量参差不齐，弱网环境的RTT（往返时间Round Trip Time）时间可能高达数百毫秒，对于一次普通的业务请求而言，上述延时是非常沉重的负担，另一方面，弱网环境下的解析超时、解析失败等现象屡见不鲜

HTTPDNS

为了解决传统域名解析的问题（忍得不能再忍的鹅厂）腾讯公司的GSLB 团队推出了一种全新的域名解析调度系统：HttpDNS。HttpDNS是为移动客户端量身定做的基于Http协议和域名解析的流量调度解决方案，专治LocalDNS解析异常以及流量调度不准。

HttpDNS基本原理

HttpDNS的原理非常简单，主要有两步：
A、客户端直接访问HttpDNS接口，获取业务在域名配置管理系统上配置的访问延迟最优的IP。（基于容灾考虑，还是保留次选使用运营商LocalDNS解析域名的方式）
B、客户端向获取到的IP后就向直接往此IP发送业务协议请求。以Http请求为例，通过在header中指定host字段，向HttpDNS返回的IP发送标准的Http请求即可。

HttpDNS优势

防域名劫持

HTTPDNS使用HTTP协议进行域名解析，代替现有基于UDP的DNS协议，域名解析请求直接发送到HTTPDNS服务端，从而绕过运营商的Local DNS

精准调度

HTTPDNS在递归解析实现上优化了与权威DNS的交互，通过edns-client-subnet协议将终端用户的IP信息直接交付给权威DNS，这样权威DNS就可以忽略Local DNS IP信息，根据终端用户的IP信息进行精准调度，避免Local DNS的坐标干扰

实时生效