几乎所有需要网络连接的应用都会依赖域名系统(Domain Name System,DNS)。域名解析服务通常作为一次网络连接的先导,将人们便于记忆的计算机名称解析成计算机适合处理的网络地址。因此DNS稳定服务是上述网络应用正常运行的前提,地位举足轻重。
DNS的设计和架构让人叹为观止,但是在实际应用中也存在着多种多样的问题,特别是处于国内的网络环境中。近来,业界出现了一种HTTPDNS的解决方案,可以有效的解决DNS实际应用中面临的一些问题。那么什么是HTTPDNS,它和DNS相比有哪些差别?它的工作原理是什么?为什么能解决上述问题?目前部署的HTTPDNS服务有哪些优势?要回答上面这些问题,首先还需要科普一下DNS的基本概念和工作原理。
DNS是如何运行的
DNS其实是一个以域名(Domain Name)为索引,存储域名对应主机信息的数据库。每个域名由字符标签(label)和点号(.)间隔组成,全体域名构成了域名空间,这个域名空间可以看做是一颗由域名标签逆向生成的树。树的根节点是长度为0的空标签。节点所代表的域名是从节点本身开始,沿路径向上并由点号分隔路径上各个标签生成的字符串。比如下图的 jr.jd.com.,但出于简便通常会将最后的点号省略。
域名空间中任意一颗子树可以称作域(domain)。根节点的子节点对应的域称作顶级域(top-level domain)或一级域。顶级域的下一层是二级域,如上图的jd.com域。
DNS这个数据库还是分布式的,不同域名对应的信息可能被不同的主体管理并存储在各自的DNS服务器上。一台DNS服务器一般只存储域名空间中有着公共父节点的一部分域名对应的信息,这一部分域名被划分为一个区域(zone)。具体的组织形式类似于文件系统目录树的硬盘挂载,不同的是在DNS中,这种“挂载”行为被称作授权(delegation)。当京东欲管理jd.com域时,应向上一级域也就是com域的管理者申请,在被授权之后,京东自己新的区域才能接管这个域的域名解析,而区域所在的DNS服务器也被称作jd.com域的权威DNS。
在实际应用中,域名解析的模型大体如下:
DNS是一个C/S架构的系统,对某一域名的解析由Client端的解析器(resolver)发起。Client端在接入网络时,通常会由DHCP得到一台DNS服务器的IP,这台服务器叫做本地DNS(Local DNS),一般由运营商部署,上面除了配置根服务器的IP外不配置任何域名解析信息。以上图为例:
1. 解析器发起递归请求,意在响应中应含有最终解析结果。
2. DNS服务器收到请求后首先会检查自己是否能够解析jr.jd.com,否则就会查看自己是否知道能够解析jr.jd.com域的服务器地址,如果不知道就会继续查看自己是否知道能够解析jd.com域的服务器地址,否则再查看是否知道能够解析com域的服务器地址。
3. 一旦知道就会向该服务器发起迭代请求,如果都不知道,则会向配置的根服务器发起关于jr.jd.com的迭代请求。
4. 因为在授权过程中,根服务器会被告知com服务器的地址。而迭代请求意味着响应中可不携带jr.jd.com的最终解析结果而仅包含将查询指向另一服务器的指示。根服务器在执行第2步的逻辑之后,最终会向Local DNS返回com服务器的地址。
5. Local DNS向com服务器请求jr.jd.com,与第4步类似,com服务器返回jd.com服务器的地址。
6. Local DNS接着向jd.com服务器请求jr.jd.com,根据第2步的逻辑,因为jd.com服务器自己就可以解析jr.jd.com,响应中会返回最终解析结果。
7. Local DNS将该结果附在递归请求的响应中返回给解析器。
按照这种逻辑,越靠近根的服务器压力越大。为了降低这种开销,Local DNS会做一层缓存。每次迭代请求的结果会缓存在Local DNS本地一段时间,具体时长遵循权威DNS上基于该域名所配置的TTL。因此,短期内通过该Local DNS请求www.baidu.com这样的域名,就会跳过上述过程的第4步。
DNS在当前应用中面临的问题
域名劫持
攻击者在用户在访问正常服务时,通过影响该服务的DNS解析结果将服务恶意引向其他地址,用户正常访问服务时,却被引向了广告页面或者钓鱼网站等。域名解析作为互联网访问的第一跳,劫持的价值最大。遗憾的是,DNS协议缺乏安全保护,劫持的代价很小。
比如进行DHCP欺骗,在终端接入网络时,使得终端上的DNS地址配置为“黑色DNS”的IP,随心所欲的控制域名解析结果;还有攻击者在局域网中通过ARP欺骗伪装成出口网关,当局域网内正常用户访问外网服务时,截取DNS请求,返回欺骗性的解析结果;或者更直接的侵入网络监听,当发现有特定DNS请求时,迅速回复该DNS请求的欺骗性应答,这对于UDP基础上的明文传输代价并不高,在攻击者距离用户比真实DNS更近时有很高成功率。另外,当前国内骨干网间结算的方式甚至使有的运营商为了保证流量本网转发,直接修改Local DNS上的解析结果。
智能解析不精准
智能解析是指DNS服务器根据一定的策略,对同一域名作出各不相同的解析应答。通过DNS智能解析,可以对业务流量进行全局的调度。
在最常见的情况下,服务提供者若要提高业务访问的质量,应在多地、多AS域内部署服务集群,并将业务访问引导至距离用户最近的集群上。由于edns-client-subnet协议的支持程度并不高,权威DNS一般通过Local DNS的出口IP来判断用户当前的地理位置以及运营商信息,结合GSLB策略,将最合适该用户的业务集群地址作为解析结果返回给用户。
该方案的关键在于权威DNS要能够通过Local DNS的出口IP准确识别用户的信息,但实际上这严重依赖于运营商Local DNS的具体部署。在上图中,如果用户Local DNS B不按照常规流程由自己向权威DNS发起迭代查询,而将查询请求转发给Local DNS A,或者干脆用户B的Local DNS就是Local DNS A(比如云南用户没有被分配放在西南地区的Local DNS,而被分配了个放在北京的Local DNS),那么都会造成用户B的流量被调度到业务集群A上,而这在上图中并非最优的业务访问。
解析变更生效慢
为降低权威DNS一侧的解析压力,Local DNS上通常会有一层缓存。Local DNS会将此前的查询结果缓存一段时间,这段时间内如果Local DNS再收到同样的解析请求,会将缓存的结果作为解析应答。因此在缓存有效的时间段内,如果权威DNS的解析内容发生,该Local DNS所服务的用户是不感知的。
一些运营商为了节省流量结算费用,将缓存有效期强制延长甚至数小时之久。显而易见,这会导致业务提供者基于DNS解析的全局流量调度灵敏性严重下降,在基于DNS解析的灾备切换场景中,还会导致对应用户长时间的业务不可用。
服务稳定性差
域名解析的第一步是访问Local DNS,由于Local DNS通常由网络运营商独立部署,其服务水平通常参差不齐。一些小运营商运维水平不高,硬件条件有限,其Local DNS普遍存在着可靠性不高,故障频发的问题。加之Local DNS的调度普遍存在着跨运营商网络,跨地域的问题,使得Local DNS与用户之间传输质量下降,进而难以提供稳定优质的域名解析服务。
HTTPDNS解决方案
上述问题的根源在于DNS协议本身安全性不高和Local DNS分布式部署带来的不可控因素。HTTPDNS就是针对于这两个方面进行改进的域名解析方案。它承载于HTTP协议之上,终端将HTTPDNS的服务IP固化在本地,直接向HTTPDNS服务器发起通信请求,从而绕过了运营商的Local DNS,并获取到最准确的域名解析结果。因为涉及到修改应用的域名解析过程,HTTPDNS当前主要应用在移动端域名解析上。
下图对HTTPDNS解决方案以及京东金融HTTPDNS的实现做了一个简单的说明:
HTTPDNS服务端由HTTPDNS-SERVER,HTTPDNS-WEB和HTTPDNS-DB构成。HTTPDNS-SERVER接受查询请求,解析域名并生成响应;HTTPDNS-WEB管理HTTPDNS-SERVER集群,提供HTTPDNS的运维管控功能;HTTPDNS-DB存储系统相关数据。运维人员通过HTTPDNS管控平台下发解析配置,m.jdjr.com的解析配置规则被写入数据库之后,会通过HTTPDNS-WEB同步到所有HTTPDNS-SERVER节点上。HTTPDNS-SERVER集群承担着域名解析工作,并对外暴露IP地址2.2.2.2。
客户端中固化了HTTPDNS服务IP(2.2.2.2),在有关于域名m.jdjr.com的业务应用时,携带查询域名m.jdjr.com直接向HTTPDNS服务地址发起HTTPDNS解析请求。服务器在响应中答复m.jd.com的地址为4.4.4.4;客户端收到之后,向业务服务器4.4.4.4发起业务协议请求。以HTTP请求为例,通过在header中指定host字段为m.jdjr.com,向4.4.4.4发送标准的HTTP请求即可。
另外,基于容灾的考虑,HTTPDNS解决方案仍保留了传统域名解析的流程,在HTTPDNS不可用的极端条件下,域名解析仍然能够通过传统域名解析方案来完成。
HTTPDNS产品的技术优势
安全防劫持
HTTPDNS域名解析方案最突出的优势在于其防域名劫持的能力。
域名劫持的场景有相当一部分是运营商充当主角。由于HTTPDNS解析请求被直接发往服务提供方的HTTPDNS服务器,绕过运营商的Local DNS,天然避免了Local DNS上域名解析缓存被更改所导致的域名劫持。
其次,HTTP协议基于TCP。对UDP的报文欺骗仅仅需要在真正的响应包到达前回复欺骗性的响应包即可;TCP为了确保端到端的可靠传输,会对所发送出的每个数据包都分配序列编号,收发双方利用序列号来确认数据包的先后顺序,因此,对TCP的报文欺骗还需要监听并伪造网络数据包的序列号,报文欺骗代价更大。
更进一步,采用HTTP协议传输仍可以保留现有的关于HTTP的安全机制,如HTTPDNS服务本身可提供HTTPS接口或者在HTTP传输的基础上加入私有的安全机制。
京东金融的HTTPDNS实现就提供了多种安全接口,除了使用基本的HTTP明文传输之外,还提供了HTTPS接口。能够在正式的数据通信前认证服务器的身份,并在应用层加密整个域名解析的通信过程,达到防窃听、防冒充、防篡改的效果。在此基础之上,产品还接入了独立的签名服务,实现了通过携带签名信息达到防篡改、防域名劫持的查询接口。
Client端在有域名解析需求时,向HTTPDNS服务的该接口发起域名查询请求,HTTPDNS在完成域名解析生成HTTP响应报文之后,还会对报文做一次签名操作,考虑到签名私钥安全性,HTTPDNS产品实现具备向独立的签名服务器请求签名的能力。Client端在收到携带签名的报文时,如果成功解签,则认为该报文未被第三方篡改过,并信任其中的域名查询结果。
上述的安全机制保证了在通信过程中,即使中间人在网络层以下截获报文,也无法有效篡改通信内容,使其劫持域名的代价极大,基本成为不可能。多种安全机制的接口应用可以根据自身的安全需求和成本考虑选择性接入。
智能解析调度精准
造成传统DNS智能解析不精准的根源在于部署混乱的Local DNS,以及edns-client-subnet协议的支持程度不高。HTTPDNS解析方案由于绕过了部署混乱的Local DNS,从终端一直到HTTPDNS服务器的网络层之上,服务提供方完全不依赖于第三者。服务提供方可以基于这个属性,根据请求中携带的多元化的信息,比如用户的地理位置或者软件版本等,更加精准的进行流量调度,更方便精细地优化用户行为。
京东金融HTTPDNS服务支持请求中携带用户IP,基于最新的IP地址库,使得服务器能够精准的判断用户所在网络的地理位置和运营商信息,在目标域名对应的IP集合中,选取最优业务节点的地址返回给客户端,让客户端就近访问业务节点。同时,业务也可以自己将调度逻辑与HTTPDNS返回结果相结合,比如指定版本访问指定业务IP等。
上图对利用HTTPDNS进行流量精准调度做了举例说明。由于国内网络跨网访问质量较差,业务服务器被同时部署在两个运营商的网络上——在中国移动网络上部署了服务节点A(2.2.2.2)和在中国电信网络上部署了节点B(3.3.3.3),当客户端有关于m.jdjr.com的业务应用时,可直接向HTTPDNS服务地址(1.1.1.1)请求其域名解析服务,请求中带上用户当前IP地址。当中国移动网络接入的用户A发起请求时,客户端将当前移动IP(5.5.5.5)作为cip参数传递给HTTPDNS,HTTPDNS基于IP库信息,识别出5.5.5.5属于中国移动网络,则向用户A回复了移动网络下m.jdjr.com的服务器地址2.2.2.2。同样,联通用户B(6.6.6.6)从HTTPDNS所获取的IP是3.3.3.3。从而使客户端获得了关于m.jdjr.com的最优业务访问。
解析变更直接生效
HTTPDNS另一个优势是能够实现域名解析变更秒级迅速生效。前文说了,出于降低权威DNS的服务压力和解析时延的目的,Local DNS上会做一层缓存,缓存有效时长TTL由该域名权威DNS配置。但是由于配置和策略参差不齐,许多Local DNS并不遵循域名TTL设置的缓存时长而强制延长缓存有效时间。HTTPDNS域名解析方案从服务器到终端保持独立,应用层上不对第三方产生依赖,服务器与终端直接通信。Client端能够获取HTTPDNS服务器上关于目标域名的最新解析结果。
在京东金融的HTTPDNS实现中,一次域名变更的数据流如上图所示。HTTPDNS-WEB管控提供配置下发接口,在数据校验完成并写入数据库之后,该数据将通过管控节点迅速同步至所有的HTTPDNS-SERVER服务节点上。终端发起查询后,所收到的响应不会来自于不可控的第三方缓存,而是HTTPDNS-SERVER基于最新域名配置信息的解析应答。
在一些业务场景中,对域名解析变更的生效时间比较敏感,比如服务器故障,希望通过域名解析快速切走流量时,HTTPDNS解析的快速生效就显得非常有意义。
稳定可靠
作为业务访问的前置环节,在HTTPDNS的实际部署中,还需要考虑HTTPDNS服务本身的高可用性。业务服务方自己运维部署的HTTPDNS能够规避大大小小的运营商运维水平参差不起而形成的服务短板。
京东金融HTTPDNS服务多节点多运营商线路部署,地理容灾;同时,每个服务节点都由多台服务器组成服务集群,保证了服务的高可用性。根据服务质量,大陆大部分用户自动选择部署在大陆对应运营商的服务节点,港澳地区海外用户自动选择香港节点,均由最优的HTTPDNS节点提供解析服务。当某节点改造下线或临时故障时,服务将平滑切换到原次优节点;同时,后续有新节点部署上线时,新建节点也能够被自主发现,无需终端和服务端做任何改造,平滑的加入服务节点参与服务。
平均解析时延低
对于解析时延,可以从理想条件下和实际情况下两个维度来评估。传统DNS解析的时延包括与Local DNS之间UDP包的往返时间和多次迭代查询的往返时间;而HTTPDNS解析时延主要由TCP建链以及HTTP数据包的往返传输产生。
实际应用中,网络质量对解析时延的影响往往更大。如果接入网络部署水平较差,Local DNS网络糟糕,比如存在跨网访问Local DNS的情况,那么域名解析时间将会大大增加。HTTPDNS方案中不存在部署质量差的Local DNS,在接入网络部署水平较差的条件下,解析时延将会明显降低。
但在网络条件良好的理想情况下,HTTPDNS虽然节约了多次迭代查询所产生的延时开销,相较于实际网络中传统DNS大多承载在UDP上,却增加了TCP建链的时间开销。因此如果两者都处于正常部署的理想条件网络,就某一次查询而言,HTTPDNS并不会在传统DNS的基础上节约出非常明显的时间。
但是HTTPDNS解决方案的优势在于终端可以根据应用场景,对HTTPDNS的解析结果做多种多样的缓存优化操作。京东金融HTTPDNS的SDK就集成了多种这样的缓存优化,能够根据策略对一些热点域名提前解析缓存,以及在用户切换接入网络或者用户地理位置发生较大变动等特定条件下自动刷新缓存。应用在嵌入SDK之后,能够摒除一些与HTTPDNS域名解析相关的逻辑,使得HTTPDNS的使用接近于透明化,同时在上层业务一旦需要域名解析时,又可以0时延直接提供最精准的解析结果。当然,缓存时间由HTTPDNS服务端合理配置,附在解析应答中,作为应用自己可控地刷新缓存的参考,兼顾解析变更的生效时间。
HTTPDNS作为一种较新的域名解析方案,实现成本低,改造动作小。域名解析所采用的协议,包括安全需求较高的接口,都是基于目前已有且非常完善成熟的协议体系。其请求和响应的构造简单清晰,不涉及过多的下层细节。接入HTTPDNS的应用还可以嵌入产品提供的SDK,通过简单调用,就能够解决当前域名解析业务的诸多痛点。同时,其架构的灵活可控也使得HTTPDNS具备了高扩展性。其与传统DNS相得益彰,在移动端上已经得到了非常广泛的应用。
> > > 本 期 推 荐 < < <
客官慢走,青山不改,绿水长流,咱们后会有期!