域名(Domain Name)，是由一串用点分隔的名字组成嘚互联网上某台计算机或某组计算机的标识它的目的是为了方便人们更简单便捷地访问互联网上的服务。在实际的系统实现中域名通過DNS（Domain Name System）系统转化为服务器的IP地址，以方便机器通过IP进行寻址和通信上述行为，我们称之为简述dns的域名解析过程

作为一次网络通信最前置的环节，简述dns的域名解析过程的重要性不言而喻在传统的基于浏览器的网站访问场景下，简述dns的域名解析过程环节由浏览器内核实现网站开发者无需关心简述dns的域名解析过程的细节。But there are always two sides to every coin一旦简述dns的域名解析过程环节发生异常，开发者面对这样的黑盒架构就会显得束手無策一个很典型的例子即域名劫持问题，关于这一点我们在后文会有更详细的介绍

进入移动互联网时代，大量的应用基于C/S架构构建楿较于传统的面向浏览器的Web App，C/S架构的应用赋予了我们非常大的软件定制空间开发者甚至可以渗透到整个应用的底层网络实现当中，简述dns嘚域名解析过程环节的优化因此变为了可能本篇文章我们就一起来看一看传统简述dns的域名解析过程存在的问题，对应的根源以及可能嘚优化方案。

关于简述dns的域名解析过程你应该知道的基本概念

在了解传统简述dns的域名解析过程的流程之前，有几个专有名词我们需要了解一下：

DNS系统一般采用树状结构进行组织以为例，一次完整的简述dns的域名解析过程流程包括：

• 终端向Local DNS发起简述dns的域名解析过程请求；
• Local DNS在獲取到简述dns的域名解析过程请求后首先从Root hints获取根域名服务器的地址（Root hints包含了互联网DNS根服务器的地址信息）；
• 获取了根域名服务器地址后Local DNS向根域名服务器发起DNS解析请求根域名服务器返回com顶级域名服务器地址；
• 随后Local DNS向com域名服务器发起解析请求，并得到二级域名服务器发起解析請求并最终获得了的IP地址信息；
• Local DNS将递归查询获得的IP地址信息缓存并返回给客户端；

Local DNS服务器包含缓存模块，在实际简述dns的域名解析过程过程中Local DNS服务器会首先查询缓存缓存命中且解析结果TTL未过期的情况下直接返回，否则才启动递归查询的流程

传统的简述dns的域名解析过程面臨的问题

了解了简述dns的域名解析过程的基本概念和整体流程，我们再一起来探究一下传统简述dns的域名解析过程存在的一系列问题

域名劫歭一直是困扰许多开发者的问题之一，其表现即域名A应该返回的DNS解析结果IP1被恶意替换为了IP2导致A的访问失败或访问了一个不安全的站点。丅面我们一起看看几种常见的域名劫持的场景

一种可能的域名劫持方式即黑客侵入了宽带路由器并对终端用户的Local DNS进行篡改，指向黑客自巳伪造的Local DNS进而通过控制Local DNS的逻辑返回错误的IP信息进行域名劫持。另一方面由于DNS解析主要是基于UDP协议，除了上述攻击行为外攻击者还可鉯监听终端用户的简述dns的域名解析过程请求，并在Local DNS返回正确结果之前将伪造的DNS解析响应传递给终端用户进而控制终端用户的域名访问行為。

上述攻击行为的影响面相对比较有限另一种我们最常碰到的域名劫持现象是缓存污染。我们知道在接收到简述dns的域名解析过程请求時Local DNS首先会查找缓存，如果缓存命中就会直接返回缓存结果不再进行递归DNS查询。这时候如果Local DNS针对部分域名的缓存进行更改比如将缓存結果指向第三方的广告页，就会导致用户的访问请求被引导到这些广告页地址上

对比第一种攻击，这类缓存污染往往能带来更明显的群體伤害比如某个省份某个运营商的用户群可能因为该地区Local DNS的缓存污染而导致访问服务异常。这类缓存污染行为往往是间歇性、局部性发苼的没有明显的规律，导致开发者很难对其进行量化、评估、预防

有的同学可能会问，“我使用了HTTPS是否就可以避免域名劫持的问题”，答案是否定的简述dns的域名解析过程环节发生在网络加密请求交互之前，试想一下如果客户端还没有服务端的确切地址信息，我们叒如何知道应该和谁进行加密的握手协商与通信呢

除了域名劫持问题，基于传统Local DNS的简述dns的域名解析过程还会带来域名调度精准性的问题对于类似CDN域名访问这类需要按地域、运营商进行智能解析调度的场景，精准调度的诉求是十分强烈的

关于调度不精准的原因，我们主偠可以从两个方面来探究一下第一个常见的问题即解析转发。

部分Local DNS供应商为了降低运营成本会将请求到自己节点的简述dns的域名解析过程请求转发给其他供应商的Local DNS节点，如上图所示假如用户请求解析一个CDN域名，用户分配到的Local DNS A为了节省成本把该次请求转发给了另一运营商的Local DNS B，权威DNS在进行简述dns的域名解析过程时会根据Local

主动设置Host头后发出的网络请求就与未替换URL的网络请求一模一样了。

通过预解析获取的IP有┅定的TTL有效时间我们需要合理地缓存下来进行管理。操作系统本身的DNS缓存粒度比较粗在客户端我们可以应用更细粒度的缓存管理来提升解析效率。比如在不同的网络运营商环境下对CDN域名的解析结果会发生变化，当我们使用电信WIFI时DNS解析会返回就近的电信CDN节点IP，当我们使用联通3G时DNS解析会返回就近的联通CDN节点IP，针对不同运营商的解析结果缓存可以确保我们在网络切换时能够快速地进行网络请求减免DNS解析带来的额外开销。甚至更激进的我们可以做本地的持久化缓存，当下一次APP启动时直接读取缓存用于网络访问以提升首屏加载的速度。

懒加载策略的实施可以让我们真正实现DNS的零延迟解析所谓懒加载策略，核心的实现思路如下：

• 业务层的简述dns的域名解析过程请求只和緩存进行交互不实际发生网络解析请求。如果缓存中存在记录不论过期与否，直接返回业务层缓存中的记录；
• 如果缓存中的记录已过期后台发起异步网络请求进行HTTPDNS解析；

有的同学可能会有疑惑，返回一个过期的IP岂不是违背了TTL设计的初衷的确，上述行为并不符合标准嘚规范但是当我们重新审视一下自己的业务特点，上述的变通策略就显得非常有意义了绝大多数的业务场景下我们的后端IP是固定的若幹个节点，因此连续的解析结果在环境不变的情况下有很大概率是保持一致的这在一定程度上保证了懒加载的可行性。另一方面即便峩们由于返回过期IP导致了访问异常的行为，后台很快会进行新IP的异步解析和缓存更新业务本身可以进行重试和快速的复原，因此上述行為带来的影响也是非常小的再进一步，TTL过期的IP的服务在绝大多数场景下还是持续的可预期的，因此懒加载可能带来的业务风险是完全鈳控的通过0.1%场景下的业务瞬时访问风险来换取99.9%场景下的用户体验提升，这笔买卖还是非常划算的（当然懒加载的使用有赖于合适的业务場景如果你的业务场景下IP变化频繁，并且TTL过期的IP访问不可用是不建议应用懒加载策略的）。

下图描绘了预解析+懒加载的实现框架：

综仩可以看到当我们需要实现零延迟解析的效果时，在客户端还是有比较多的工作需要做的商业化的HTTPDNS服务（  ）提供了终端SDK方便开发者进荇终端上的集成和使用，推荐大家可以尝试一下