全面理解DNS及HTTPDNS

说明

在移动场景下，DNS 解析开销是整个网络请求中不可忽略的一部分。在弱网环境下，基于 UDP 的 LocalDNS 解析非常容易出现解析超时的问题；即使解析成功，也可能消耗数百毫秒乃至更多时间，这对业务请求的整体耗时非常不利，直接影响用户体验。

对于一个大众化的应用而言，DNS 优化在整个应用网络优化中所占的权重很大。接下来我们将从以下几个方面全面理解 DNS，相信这对开发中的网络优化会有不小的帮助。

DNS
- 认识 DNS
- DNS 解析相关概念
  - DNS 域名层次结构
  - 权威 DNS
  - 递归 DNS
  - 公共 DNS
  - 转发 DNS
- 域名解析记录方式
- 域名解析过程
DNS 解析存在的问题
- DNS 劫持
- DNS 解析域名时缓存解析结果
- 转发解析
全局负载均衡 GSLB
- 智能 DNS
HTTPDNS
- 什么是 HTTPDNS
- HTTPDNS 的特性
- 如何支持 HTTPS
常见问题
- 主机是如何知道 DNS 服务器的 IP 地址的？
- 为什么 DNS 采用 UDP 协议？

1. DNS

1.1 认识 DNS

DNS（Domain Name System，域名系统）是一种组织成域层次结构的计算机和网络服务命名系统。它用于 TCP/IP 网络，所提供的服务是用来将主机名和域名转换为 IP 地址的工作。

作为网络通信的最靠前的一个环节，其在整个网络通信过程中的重要性不言而喻。

iOS 10 之后，Apple 提供的原生 HTTP 请求方法能返回 HTTP 请求各个阶段的时间指标，其中就包含 DNS 解析时间。

1.2 DNS 解析相关概念

1.2.1 DNS 域名层次结构

DNS 是一种分层结构，在整个互联网中组成一个树状系统。顶层是系统的根域名，下层为 TLD（Top Level Domain）以及二级域名，叶子就构成了所谓的 FQDN（Fully Qualified Domain Names）。根域名通常使用 . 来表示，其实际上也是由域名组成。全世界目前有 13 组域名根节点，由少数几个国家进行管理，而国内仅有几台根节点镜像。

1.2.2 权威 DNS

权威 DNS 是经过上一级授权对域名进行解析的服务器，同时它可以把解析授权转授给其他人。例如，COM 顶级服务器可以授权 xxorg.com 这个域名的权威服务器为 NS.ABC.COM，同时 NS.ABC.COM 还可以把授权转授给 NS.DDD.COM，这样 NS.DDD.COM 就成了 ABC.COM 实际上的权威服务器了。平时我们解析域名的结果都源自权威 DNS。

示例：阿里云云解析 https://wanwang.aliyun.com/domain/dns

1.2.3 递归 DNS

递归 DNS 又称为 Local DNS，它没有域名解析结果的决定权，但代理了用户向权威 DNS 获取域名解析结果的过程。递归 DNS 上有缓存模块，当目标域名存在缓存解析结果并且 TTL（Time To Live，有效生存时间）未过期时，递归 DNS 会返回缓存结果；否则，递归 DNS 会一级一级地查询各个层级域名的权威 DNS，直至获取最终完整域名的解析结果。

示例：我们自己的电脑、运营商提供的 DNS 服务器等。

1.2.4 公共 DNS

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

在 DNS 的解析过程中，用户向递归 DNS 发起请求，递归 DNS 向权威 DNS 请求解析结果，可以说递归 DNS 起到一种转发的作用。ISP DNS 就是递归 DNS；同时一些个人或互联网服务提供商也会架设自己的递归 DNS 开放给所有人使用，称为公共 DNS。

运营商	Anycast 节点	官网	DNS IP
南京信风公共 DNS	南京、济南、芝加哥	www.114dns.com	114.114.114.114 114.114.115.115
阿里云公共 DNS	成都、深圳、杭州	www.alidns.com	223.5.5.5 223.6.6.6
Google Public DNS	Google 36 个数据中心	developers.google.com/speed/public-dns/	8.8.8.8 8.8.4.4

全国 DNS 汇总：www.114dns.com/DNS_List.html
IPIP 工具：tools.ipip.net/dns.php

1.2.5 转发 DNS

可以理解为递归 DNS 和用户之间的一个中转站，它不提供直接解析域名的服务，它将请求转发给递归 DNS，然后将递归 DNS 的结果转发回来，也提供缓存作用。比如，日常家用的路由器，它的 DNS 服务器一般都是 192.168.1.1，只是转发给递归 DNS。

1.3 域名解析记录方式

域名解析记录主要分为 A 记录、MX 记录、CNAME 记录、NS 记录和 TXT 记录：

A 记录：A 代表 Address，用来指定域名对应的 IP。例如将 www.hello.com 指定到 113.112.3.xxx。A 记录可以将多个域名解析到一个 IP 地址，但是不能将一个域名解析到多个 IP 地址（注：实际可通过轮询实现负载均衡，但单条记录通常对应一个 IP）。
MX 记录：Mail Exchange，就是可以将某个域名下的邮件服务器指向自己的 Mail Server。
CNAME 记录：Canonical Name，即别名解析。所谓别名解析就是可以为一个域名设置一个或者多个别名，如将 aaa.com 解析到 bbb.net、将 ccc.com 也解析到 bbb.net，其中 bbb.net 分别是 aaa.com 和 ccc.com 的别名。
NS 记录：为某个域名指定 DNS 解析服务器，也就是这个域名由指定的 IP 地址的 DNS 服务器解析。
TXT 记录：为某个主机名或域名设置说明，如可以为 ucloud.cn 设置 TXT 记录为“中立安全可信赖”这样的说明。

1.4 域名解析过程

以下是在终端中 dig 百度显示的具体过程：

macdeiMac:~ ethan$ dig +trace www.baidu.com 

; <<>> DiG 9.10.6 <<>> +trace www.baidu.com
;; global options: +cmd
.            1615    IN    NS    a.root-servers.net.
.            1615    IN    NS    g.root-servers.net.
.            1615    IN    NS    f.root-servers.net.
.            1615    IN    NS    l.root-servers.net.
.            1615    IN    NS    m.root-servers.net.
.            1615    IN    NS    j.root-servers.net.
.            1615    IN    NS    k.root-servers.net.
.            1615    IN    NS    c.root-servers.net.
.            1615    IN    NS    b.root-servers.net.
.            1615    IN    NS    d.root-servers.net.
.            1615    IN    NS    i.root-servers.net.
.            1615    IN    NS    e.root-servers.net.
.            1615    IN    NS    h.root-servers.net.
;; Received 239 bytes from 114.114.114.114#53(114.114.114.114) in 10 ms

com.            172800    IN    NS    a.gtld-servers.net.
com.            172800    IN    NS    b.gtld-servers.net.
com.            172800    IN    NS    c.gtld-servers.net.
com.            172800    IN    NS    d.gtld-servers.net.
com.            172800    IN    NS    e.gtld-servers.net.
com.            172800    IN    NS    f.gtld-servers.net.
com.            172800    IN    NS    g.gtld-servers.net.
com.            172800    IN    NS    h.gtld-servers.net.
com.            172800    IN    NS    i.gtld-servers.net.
com.            172800    IN    NS    j.gtld-servers.net.
com.            172800    IN    NS    k.gtld-servers.net.
com.            172800    IN    NS    l.gtld-servers.net.
com.            172800    IN    NS    m.gtld-servers.net.
com.            86400    IN    DS    30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
com.            86400    IN    RRSIG    DS 8 1 86400 20191112050000 20191030040000 22545 . Sr1g7h+DSqi+ekBQQS2ZBc/jt0zL+IR+Od/R9TnMjcy8Mw9RxLrMY2pm 1VYNqL5cAME1stSAfRUKwjD/vixnCeVLoJ6idCFOZeB+t/tTFQF/jfk1 td66pW9V/WgLIvslAwEZjidVeUFYERc7hZXr10BgzryZthizHISimuiQ qBjoIQN/uYULTnmePkIW07mnJXc9/AVZrjeI1AmvYC7wE0uR7DWNg1Ig dL4DaLDOM30qN7FBAD7K091uEgctpdxd/8G5XoYclSqroN4G6RibvkWT /vPCFRUzoaxembT5tR7gIz7gxdhN1r8NBD468JTG180MNUvb16Z/87U6 7UkMrg==
;; Received 1173 bytes from 192.58.128.30#53(j.root-servers.net) in 77 ms

baidu.com.        172800    IN    NS    ns2.baidu.com.
baidu.com.        172800    IN    NS    ns3.baidu.com.
baidu.com.        172800    IN    NS    ns4.baidu.com.
baidu.com.        172800    IN    NS    ns1.baidu.com.
baidu.com.        172800    IN    NS    ns7.baidu.com.
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q1GIN43N1ARRC9OSM6QPQR81H5M9A  NS SOA RRSIG DNSKEY NSEC3PARAM
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20191103044815 20191027033815 12163 com. U/FwNWeuKzR/uT2X/8Cf9TQmnaMdWf6XwBrFIIOCQ/kfKaOExEiT8LSQ 13OaEjtvFOOlIPK0XIbsL+dgGPYb/UV6sipBeQ1n8KuK18m3bYk47Ely oe+3VVp0zaiXt9DZrmRRenBB13o0DPqCbRHAHq1pj5zG5VkMufu9L/TT g80XlNukAMcu4GrV4VP8OimOQxz7HJbadci2oYn3beiHqQ==
HPVV2B5N85O7HJJRB7690IB5UVF9O9UA.com. 86400 IN NSEC3 1 1 0 - HPVVN3Q5E5GOQP2QFE2LEM4SVB9C0SJ6  NS DS RRSIG
HPVV2B5N85O7HJJRB7690IB5UVF9O9UA.com. 86400 IN RRSIG NSEC3 8 2 86400 20191105055359 20191029034359 12163 com. J5Dq0lGkcejjg1vPqWDBvNYaAhqFF3Ck8trKj4tgW5Z1bmoXsHGU6/Cl y3GlLfzb49xjiXzxVLCuAQJ9uLuKSX5cn+kesc8rwYqcVXU4nXbD5jzo u3CK2yHD3FqPDCOKlMSNy3KKkL03bB3DfmvAae/qQs7xSe6VTpCkR6v/ lo3UA/pMfTYBjSIOvR2KmpM9yFLmN5LXAQW3rNH8sW91BA==
;; Received 761 bytes from 192.26.92.30#53(c.gtld-servers.net) in 241 ms

www.baidu.com.        1200    IN    CNAME    www.a.shifen.com.
a.shifen.com.        1200    IN    NS    ns2.a.shifen.com.
a.shifen.com.        1200    IN    NS    ns3.a.shifen.com.
a.shifen.com.        1200    IN    NS    ns4.a.shifen.com.
a.shifen.com.        1200    IN    NS    ns5.a.shifen.com.
a.shifen.com.        1200    IN    NS    ns1.a.shifen.com.
;; Received 239 bytes from 180.76.76.92#53(ns7.baidu.com) in 10 ms

通过上面命令我们可以看到 DNS 解析的逐步过程，其中最后一步我们可以看到 www.baidu.com 被 CNAME 到 www.a.shifen.com，所以我们再查一下 www.a.shifen.com 即可看到其 IP。

;; Received 215 bytes from 220.181.33.31#53(ns2.baidu.com) in 28 ms

www.a.shifen.com.    300    IN    A    180.101.49.12
www.a.shifen.com.    300    IN    A    180.101.49.11
a.shifen.com.        1200    IN    NS    ns4.a.shifen.com.
a.shifen.com.        1200    IN    NS    ns5.a.shifen.com.
a.shifen.com.        1200    IN    NS    ns1.a.shifen.com.
a.shifen.com.        1200    IN    NS    ns2.a.shifen.com.
a.shifen.com.        1200    IN    NS    ns3.a.shifen.com.
;; Received 236 bytes from 180.76.76.95#53(ns5.a.shifen.com) in 9 ms

然后我们再用 nslookup 命令查看一下百度的 IP 是不是上面显示的两个：

macdeiMac:~ ethan$ nslookup www.baidu.com
Server:        114.114.114.114
Address:    114.114.114.114#53

Non-authoritative answer:
www.baidu.com    canonical name = www.a.shifen.com.
Name:    www.a.shifen.com
Address: 180.101.49.11
Name:    www.a.shifen.com
Address: 180.101.49.12

图示 DNS 解析 baidu 的过程：

终端向 Local DNS 发起域名解析请求。
Local DNS 在获取到域名请求后，首先从 Root hints 获取根域名服务器的地址（Root hints 包含了互联网 DNS 根服务器的地址信息）。
获取到了根域名服务器地址后，Local DNS 向根域名服务器发起 DNS 解析请求，根域名服务器返回顶级域名服务器地址（com 或者 cn 或者其它）。
随后 Local DNS 向 com 域名服务器发起解析请求，并得到 baidu.com 二级域名服务器地址。
Local DNS 向 baidu.com 二级域名服务器发起解析请求，并最终获取到了 www.baidu.com 的 IP 地址信息。
Local DNS 将递归查询获得的 IP 地址信息缓存并返回给客户端。

2. DNS 解析存在的问题

有时候我们在访问百度或者在应用中发出一个 HTTP 请求时，如果 DNS 解析被劫持，我们可能最终访问到的不是我们想要访问的服务器。

2.1 运营商劫持

DNS 劫持就是通过劫持了 DNS 服务器，通过某些手段取得某域名的解析记录控制权，进而修改此域名的解析结果，导致对该域名的访问由原 IP 地址转入到修改后的指定 IP。其结果就是对特定的网址不能访问或访问的是假网址，从而实现窃取资料或者破坏原有正常服务的目的。

2.2 DNS 解析域名时缓存解析结果

我们在开发中有时候会遇到这样的情况：你是一个联通用户，你在手机浏览器中输入 baidu.com，由一个 LocalDNS 服务器向百度权威服务器查应该访问哪一台服务器，权威把结果返回给 LocalDNS 服务器，LocalDNS 服务器返回结果给用户。

如果当 LocalDNS 缓存的有 baidu.com 对应的结果，那么它就不会向百度的权威服务器查询其对应的 IP，而是直接返回缓存中的结果。如果此时权威服务器中的 baidu.com 对应的 IP 发生了变化，LocalDNS 没有及时更新，这样会导致用户访问不到服务器。

2.3 转发解析

你用手机访问 baidu.com 时，会到当前运营商的 DNS 服务器查，然后运营商的 DNS 服务再去百度权威服务器去查，最终把权威服务器中的正确 IP 返回。

上面是正常的情况，但是如果当前运营商（比如联通）的 LocalDNS 不访问百度权威 DNS 服务器，而是直接访问了其它运营商（比如电信）的 LocalDNS 服务器，有些小的运营商就是通过这样做来降低成本。如果电信的 LocalDNS 对非自家 IP 的访问限制了速度，那么很明显会影响你的 DNS 解析时间。如果你应用中的某些服务需要运营商信息 ISP（例如：智能 DNS、CDN 等服务），这会造成影响。

下面截图是我手机的网络环境（NetPing 开源地址：github.com/mediaios/net-diagnosis）：

我直接 ping 百度的地址，然后用 Wireshark 抓包结果，正常结果如下：

如果发生了转发则逻辑如下：

3. 全局负载均衡 GSLB

GSLB 是 Global Server Load Balance 的缩写，即全局负载均衡。目的是实现互联网上不同地域的服务器间的流量调配，保证使用户的请求能被离用户最近或者服务质量更好的服务器来处理，从而确保服务质量。

能通过判断服务器的负载，包括 CPU 占用、带宽占用等数据，决定服务器的可用性，同时能判断用户（访问者）与服务器间的链路状况，选择链路状况最好的服务器。因此 GSLB 是对服务器和链路进行综合判断来决定由哪个地点的服务器来提供服务，实现异地服务器群服务质量的保证。

3.1 智能 DNS

智能 DNS 是 GSLB 的一种应用。

4. HTTPDNS

4.1 什么是 HTTPDNS

HTTPDNS 使用 HTTP 与 DNS 服务器交互，代替传统的基于 UDP 的 DNS 协议，域名解析请求直接发送到 HTTPDNS 服务端，从而绕过运营商的 Local DNS。

4.2 HTTPDNS 的特性

4.2.1 防止域名劫持

由于 HTTPDNS 是通过 IP 直接请求 HTTP 获取服务器 A 记录地址，不存在向本地运营商询问 domain 解析过程，所以从根本避免了劫持问题。

4.2.2 精准调度

HTTPDNS 能够直接获取到用户的 IP 地址，从而实现精确定位与导流。

4.2.3 用户连接失败率下降

通过算法降低以往失败率过高的服务器排序，通过时间近期访问过的数据提高服务器排序，通过历史访问成功记录提高服务器排序。

原来的请求地址为 [apis.juhe.cn/simpleWeather/query?city=上海&key=...](http://apis.juhe.cn/simpleWeather/query?city=%E4%B8%8A%E6%B5%B7&key=5be112d55b4fe1fc620b4a662904b4d8)，通过 HTTPDNS 替换域名后最终的结果如下：

4.3 HTTPDNS 对 HTTPS 的支持

发送 HTTPS 请求首先要进行 SSL/TLS 握手，握手过程大致如下：

客户端发起握手请求，携带随机数、支持算法列表等参数。
服务端收到请求，选择合适的算法，下发公钥证书和随机数。
客户端对服务端证书进行校验，并发送随机数信息，该信息使用公钥加密。
服务端通过私钥获取随机数信息。
双方根据以上交互的信息生成 session ticket，用作该连接后续数据传输的加密密钥。

上述过程中，和 HTTPDNS 有关的是第 3 步，客户端需要验证服务端下发的证书，验证过程有以下两个要点：

客户端用本地保存的根证书解开证书链，确认服务端下发的证书是由可信任的机构颁发的。
客户端需要检查证书的 domain 域和扩展域，看是否包含本次请求的 host。

如果上述两点都校验通过，就证明当前的服务端是可信任的，否则就是不可信任，应当中断当前连接。

当客户端使用 HTTPDNS 解析域名时，请求 URL 中的 host 会被替换成 HTTPDNS 解析出来的 IP，所以在证书验证的第 2 步，会出现 domain 不匹配的情况，导致 SSL/TLS 握手不成功。因此，在使用 HTTPDNS 配合 HTTPS 时，需要在客户端进行特殊的证书校验配置（例如手动指定 Host 或使用 SNI 扩展）。

5. 常见问题

5.1 主机是如何知道 DNS 服务器的 IP 地址的？

通过 DHCP 动态获得，或者手工配置的。

DHCP 协议：DHCP（Dynamic Host Configuration Protocol，动态主机配置协议）通常被应用在大型的局域网络环境中，主要作用是集中的管理、分配 IP 地址，使网络环境中的主机动态的获得 IP 地址、Gateway 地址、DNS 服务器地址等信息，并能够提升地址的使用率。

5.2 为什么 DNS 采用 UDP 协议？

TCP 通信过程太复杂并且开销大，一次 TCP 交换需要 9 个包：三个连接包，四个断开包，一个 request 包，一个响应包。

UDP 通信过程简单，只需要一个查询包和一个响应包。

说明：本文部分内容基于 2019 年左右的技术环境编写（如提及 iOS 10 特性），部分链接或数据可能随时间发生变化，请以最新官方文档为准。

本文地址：https://1diff.fun/archives/quan-mian-li-jie-dns-ji-httpdns.html

如果对本文有什么问题或疑问都可以在评论区留言，我看到后会尽量解答。