我们正在研究的下一代智能媒体网络课题中，网络传输环节有一个问题需要解决，即终端如何能够就近接入分布在全球各地的媒体节点，这用到了HTTP DNS这项技术。恰好在阿里云栖社区上，读到一篇关于DNS域名解析优化的文章，对此讲解的挺清楚。写一篇学习笔记，一些文字或图片引自该问斩个。原文链接：《移动互联网时代，如何优化你的网络 —— 域名解析篇》
域名(Domain Name)是由一串用点分隔的名字组成的某台计算机或某组计算机的标识，域名通过DNS（Domain Name System）服务转化为服务器的IP地址，以便应用通过IP进行寻址和通信，这个过程称之为域名解析
作为互联网络通信的最前端环节，域名解析非常重要。在基于传统浏览器的B/S场景下，域名解析由浏览器内核实现，应用不用关心域名解析的细节。也正因为这种透明性，一旦域名解析系统出现问题，甚至遭到黑客的劫持，应用开发者几乎无计可施
而进入移动互联网时代（包括基于浏览器的富客户端应用），实际上是一种C/S架构，这赋予了应用开发者较大的定制空间。开发者甚至可以渗透到应用底层网络实现当中，对域名解析环节的优化变为了可能
一些DNS中的关键概念
树状域名结构
DNS系统采用树状管理结构，以blog.csdn.net为例，.net是顶级域名，csdn为二级域名，blog为三级域名，以此类推
权威DNS
权威DNS是最终决定解析结果的服务器，是解析结果的权威，可以在权威DNS上配置、更改、删除具体域名的解析结果。比如阿里云解析就是权威DNS服务提供商
递归DNS
递归DNS又称为Local DNS，它没有域名解析的决定权，但能够代理用户向权威DNS进行域名解析的请求。递归DNS上有缓存模块，当缓存中包含解析目标并且TTL未过期时（TTL是域名的有效生存时间，若缓存时间超过TTL，递归DNS需要重新向权威DNS获取解析结果），递归DNS会返回缓存结果，否则递归DNS会逐级查询各个层级域名的权威DNS，直至获取最终完整域名的解析结果
公共DNS
公共DNS是递归DNS的一种特例，它是一种向全网开放的递归DNS服务，而传统的递归DNS信息一般由运营商分发给用户（还记得曾经手工在IP配置中指定DNS地址么）。一个比较典型的公共DNS是Google提供的的8.8.8.8（看来老外也喜欢吉利的数字），可以通过在操作系统配置文件中用公共DNS来代替Local DNS完成域名解析流程
注：在实际的使用过程中，我们通常不需要手工指定Local DNS地址。运营商会通过DHCP协议将Local DNS地址分配给我们的计算机
以访问“www.csdn.net”为例，一次域名的递归查询解析的具体过程如下：
1）终端向Local DNS发起“www.csdn.net”的访问请求
2）Local DNS收到请求后，从Root Hints获取根域名服务器地址，并向“Root DNS Server”发起解析请求，Root DNS Server返回“net”顶级域名服务器IP地址
3）Local DNS向“Net DNS Server”发起域名解析请求，Net DNS Server返回“csdn.net”二级域名服务器IP地址
4）Local DNS向“CSDN DNS Server”发起域名解析请求，CSDN DNS Server返回最终的“www.csdn.net”的IP地址
5）Local DNS将递归查询获取的IP地址返回给终端
注：Local DNS服务器包含缓存模块，在实际域名解析过程中Local DNS服务器会首先查询缓存，缓存命中且解析结果TTL未过期的情况下直接返回，否则才启动递归查询的流程
传统域名解析（Local DNS）可能存在的问题
第一、域名劫持：本来域名A应该返回的DNS解析结果的IP1被恶意替换为了IP2，导致对A的访问失败或访问了一个不安全的站点。有两种可能的劫持方式：
1）攻击Local DNS周边：一方面，黑客侵入了宽带路由器并将终端用户指定的Local DNS篡改为黑客自己伪造的Local DNS；另一方面，由于DNS解析主要是基于UDP协议，攻击者可以监听终端用户的域名解析请求，并在Local DNS返回正确结果之前将伪造的DNS解析响应传递给终端用户，进而控制终端用户的域名访问行为
2）攻击Local DNS缓存：最常碰到的域名劫持现象是缓存污染。由于Local DNS在接收到域名解析请求时首先会查找缓存，如果命中就会直接返回缓存结果，不再进行递归DNS查询。如果黑客将缓存结果指向第三方的广告页，就会导致用户的访问请求被引导到这些广告页地址上
第二种针对Local DNS缓存的污染往往能带来更明显的群体伤害，比如某个省份某个运营商的用户群可能因为该地区Local DNS的缓存污染而导致群体性访问服务异常。而且这类缓存污染行为往往是间歇性、局部性发生的，没有明显的规律，导致开发者很难对其进行量化、评估、预防
第二、调度不精准：有这样一种场景，为了应用后续的访问性能，用户希望的初始的DNS解析结果带有地域或运营商性质，比如CDN。传统的域名解析方式可能存在两类问题：
1）部分Local DNS供应商为了降低运营成本，会将发给自己的域名解析请求转发给其他供应商的Local DNS节点，如下图所示，用户请求解析的是cdn.aliyun.com，分配给用户的是Local DNS A，该DNS节点为了节省成本，把该次请求转发给了另一运营商的Local DNS B。而最终的权威DNS在进行域名解析时可能会根据Local DNS的IP信息进行智能调度（比如采用地理位置就近接入的调度策略），分配与Local DNS B 78.29.29.1相同运营商并且地理位置最近的CDN节点78.29.29.2，然而这个CDN节点对于终端135.35.35.1并不是最优的CDN节点，他们分属不同的运营商，并且地理位置上可能相隔很远。这类解析转发行为会严重影响域名解析的精准性并对用户业务访问延迟带来影响
2）除了解析转发对调度精准性带来的影响外，Local DNS的布署情况同样影响着域名智能解析的精准性。受成本因素制约，部分运营商Local DNS部署分布并不均匀，比如在东部地区部署比较密集，在西部地区部署比较稀疏。当一位西藏用户准备访问CDN节点时，我们预期他应该会被调度到西藏的CDN节点A上以实现就近接入和访问加速。但由于Local DNS的资源有限，西部地区的终端用户被统一调度到青海的Local DNS B上，这时候权威DNS根据Local DNS B的IP进行CDN域名的智能解析，并将青海的CDN节点B返回给西藏用户，导致西藏地区用户的网络访问延迟上升。另一种情况是Local DNS的分配甚至并非遵循就近原则，比如有实际案例显示西藏用户甚至被分配了北京的Local DNS节点C，导致西藏的用户在进行CDN资源访问时被调度到了北京的CDN节点C上，类似的由于调度精度的缺失带来的访问体验的影响是非常严重的
第三、解析生效滞后：
Local DNS是由各个地区不同运营商独立部署的，服务质量参差不齐。在对域名解析缓存的处理上，各个独立节点的实现策略也有区别，比如部分节点为了节省开支忽略了域名解析结果的TTL时间限制，导致用户在权威DNS进行解析变更，但解析结果在全网生效的周期非常漫长（最长生效时间甚至高达48小时）。部分业务场景下开发者对域名解析结果变更的生效时间非常敏感，比如当业务服务器受到攻击时，我们需要最快速地将业务IP切换到另一组集群上，如果全网解析生效不够迅速，可能直接导致用户业务访问的异常，造成严重事故
第四、延迟大：
DNS首次查询或缓存过期后的查询，需要递归遍历多个DNS服务器以获取最终的解析结果，这增加了网络请求的前置延时时间。特别是在移动互联网场景下，移动网络质量参差不齐，弱网环境的RTT时间可能高达数百毫秒，对于一次普通的业务请求而言，上述延时是非常沉重的负担。另一方面，弱网环境下的解析超时、解析失败等现象屡见不鲜，如何合理优化DNS解析对于整体网络访问质量的提升至关重要
域名解析的解决方案：HTTP DNS
HTTP DNS使用HTTP协议进行域名解析，代替现有Local DNS基于UDP的DNS协议。域名解析请求直接发送到HTTP DNS服务端，绕过运营商的Local DNS。基于HTTP协议的设计可以适用于几乎所有的网络环境，同时保留了鉴权、HTTPS等更高安全性的扩展能力，避免恶意攻击劫持行为。而商业化的HTTP DNS服务（比如阿里和腾讯的HTTP DNS）对缓存管理有严格的安全保障，避免了类似Local DNS的缓存污染的问题
第一、精准调度问题的解决
传统域名解析的调度精准性问题，本质根源在于Local DNS的部署和分配机制上。由于碎片化的管理方式，服务质量难以得到保障。而HTTP DNS与权威DNS的交互时，通过edns-client-subnet协议（https://datatracker.ietf.org/doc/rfc7871）将终端用户的IP信息直接传递给权威DNS，权威DNS根据终端用户的IP信息，而不是传统的Local DNS IP信息进行精准调度，这样避免看了Local DNS的坐标干扰
第二、解析实时性问题的解决
和精准调度一样，由于传统Local DNS在不同区域的独立提供和独立维护，服务质量参差不齐，因此存在比较明显的解析变更全网生效滞后问题，而商业化的HTTP DNS服务严格遵循DNS TTL限制进行缓存更新（一般都有专门的同步方案进行保证），能够大大减少滞后性问题
结语：HTTP DNS本质上是将原本分布在各地，由不同DNS供应商（主要就是运营商）提供的参差不齐的DNS服务质量，利用协议，转化为由统一DNS服务提供商提供的更短接、更有保障的DNS服务能力。当然利用HTTP DNS，也要符合具体服务提供者的操作规范和编程规范，这里面也有较多良好的实践模式，在后面的学习中再进行总结
晚安……
