CN107896257B - 部署客户端子系统功能的方法、装置、设备和介质 - Google Patents
部署客户端子系统功能的方法、装置、设备和介质 Download PDFInfo
- Publication number
- CN107896257B CN107896257B CN201711328098.3A CN201711328098A CN107896257B CN 107896257 B CN107896257 B CN 107896257B CN 201711328098 A CN201711328098 A CN 201711328098A CN 107896257 B CN107896257 B CN 107896257B
- Authority
- CN
- China
- Prior art keywords
- client
- partition
- address
- dns
- query request
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/45—Network directories; Name-to-address mapping
- H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
- H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/09—Mapping addresses
- H04L61/10—Mapping addresses of different types
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/09—Mapping addresses
- H04L61/25—Mapping addresses of the same type
- H04L61/2503—Translation of Internet protocol [IP] addresses
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明公开了部署客户端子系统功能的方法、装置、设备和介质。该方法包括:本地DNS依据发送DNS查询请求的客户端地址,得到客户端的分区;本地DNS判断DNS查询请求在客户端的分区中是否为第一次请求;若是,本地DNS取出客户端的分区对应的分区映射地址;本地DNS向权威服务器发送更新的DNS查询请求;权威服务器基于客户端的分区对应的分区映射地址,确定解析地址;本地DNS缓存应答报文,发送给客户端;若不是第一次请求且距上次请求时间未超过TTL,本地DNS在缓存分区中查询应答报文,发送给客户端。根据本发明实施例提供的在域名系统中部署客户端子系统功能的方法、装置、设备和计算机可读存储介质,能够降低相关服务器的资源消耗。
Description
技术领域
本发明涉及计算机领域,尤其涉及一种在域名系统中部署客户端子系统功能的方法、装置、设备和计算机可读存储介质。
背景技术
随着用户的飞速增长,很多互联网内容提供商普遍使用内容分发网络(ContentDelivery Network,CDN)为用户提供内容服务。互联网内容提供商一般通过权威服务器实现CDN的调度。权威服务器能够对同一个域名根据用户网络拓扑位置返回不同的域名系统(Domain Name System,DNS)解析地址,将用户访问调度到最优化的CDN内容节点。
在DNS报文的扩展报头中增加一种新的选项,在该选项中携带初始发起DNS请求者的地址信息,选项中内容可以被递归服务器接力传递到权威服务器。权威服务器由此获得初始发起DNS请求者的地址信息,进而根据该地址信息能够准确识别该用户的网络拓扑位置。上述增加选项的解决方案称为客户端子系统(EDNS Client Subnet,ECS)。
按照ECS协议,权威服务器通过应答报文中的ECS信息指定该应答生效的用户源地址段。对于互联网协议第四版(Internet Protocol version4,IPv4),ECS信息使用地址前24位,而对于互联网协议第六版(IPv6),ECS信息使用地址前56位。
根据ECS缓存算法,同一个域名每个用户地址段至少需要一个缓存条目。对于一个省一级的互联网服务提供商(Internet Service Provider,ISP),用户IPv4源地址条目数一般能够达到几百到上千条,而对于一个全国性的ISP,用户IPv4源地址条目数一般能够达到几千到上万条。
来自不同用户地址段的同一个域名查询请求都需要进行递归查询。这样递归查询量大幅上升,对相关服务器的资源消耗大幅上升。
发明内容
本发明实施例提供了一种在域名系统中部署客户端子系统功能的方法、装置、设备和计算机可读存储介质,能减少同一个域名的缓存条目数量,降低相关服务器的资源消耗,同时还能够实现资源的精准调度。
根据本发明实施例的一方面,提供一种在域名系统中部署客户端子系统功能的方法,该方法包括:
本地域名系统DNS依据发送DNS查询请求的客户端地址所属的分区地址段进行匹配,得到客户端的分区;
本地DNS判断客户端发送的DNS查询请求在客户端的分区中是否为第一次请求;
若客户端发送的DNS查询请求在客户端的分区中是为第一次请求,则本地DNS基于预设的分区与分区映射地址的唯一映射关系,取出客户端的分区对应的分区映射地址;
本地DNS向权威服务器发送更新的DNS查询请求,更新的DNS查询请求包括客户端的分区对应的分区映射地址;
权威服务器基于客户端的分区对应的分区映射地址,确定客户端发送的DNS查询请求的解析地址,发送包括解析地址的应答报文;
本地DNS在客户端的分区对应的缓存分区中缓存应答报文,并发送给客户端;
若客户端发送的DNS查询请求在客户端的分区中不是第一次请求并且距上次请求时间未超过生存周期,本地DNS在客户端的分区对应的缓存分区中查询应答报文,并将查询到的应答报文发送给客户端;
若客户端发送的DNS查询请求在客户端的分区中不是第一次请求并且距上次请求时间超过生存周期,本地DNS设定客户端发送的DNS查询请求在客户端的分区中为第一次请求。
在一个实施例中,分区根据行政区域和/或用户类别进行划分;其中,用户类别包括移动上网用户、家庭宽带上网用户或专线上网用户。
在一个实施例中,分区地址段包括一个行政区域内所有网络拓扑位置相同的地址段。
在一个实施例中,分区映射地址包括互联网协议第四版IPv4公网地址、未分配给用户的空余地址、或互联网协议第六版IPv6地址。
在一个实施例中,本地DNS包括前端缓存模块和ECS后端递归模块。
在一个实施例中,唯一映射关系由DNS运营方公开发布,和/或由DNS运营方与权威服务器协商。
在一个实施例中,分区地址段包括公网地址和/或私有地址。
在一个实施例中,在本地DNS依据发送DNS查询请求的客户端地址所属的分区地址段进行匹配,得到客户端的分区之前,还包括:
本地DNS确定客户端发送的DNS查询请求是ECS查询请求。
根据本发明实施例的另一方面,提供一种在域名系统中部署客户端子系统功能的装置,该装置包括:
匹配模块,用于本地DNS依据发送DNS查询请求的客户端地址所属的分区地址段进行匹配,得到客户端的分区;
判断模块,用于本地DNS判断客户端发送的DNS查询请求在客户端的分区中是否为第一次请求;
获取模块,用于若客户端发送的DNS查询请求在客户端的分区中是为第一次请求,则本地DNS基于预设的分区与分区映射地址的唯一映射关系,取出客户端的分区对应的分区映射地址;
发送模块,用于本地DNS向权威服务器发送更新的DNS查询请求,更新的DNS查询请求包括客户端的分区对应的分区映射地址;
确定模块,用于权威服务器基于客户端的分区对应的分区映射地址,确定客户端发送的DNS查询请求的解析地址,发送包括解析地址的应答报文;
缓存模块,用于本地DNS在客户端的分区对应的缓存分区中缓存应答报文,并发送给客户端;
查询模块,用于若客户端发送的DNS查询请求在客户端的分区中不是第一次请求并且距上次请求时间未超过生存周期,本地DNS在客户端的分区对应的缓存分区中查询应答报文,并将查询到的应答报文发送给客户端;
设定模块,用于若客户端发送的DNS查询请求在客户端的分区中不是第一次请求并且距上次请求时间超过生存周期,本地DNS设定客户端发送的DNS查询请求在客户端的分区中为第一次请求。
根据本发明实施例的再一方面,提供一种在域名系统中部署客户端子系统功能的设备,该设备包括:处理器以及存储有计算机程序指令的存储器;
处理器执行计算机程序指令时实现本发明实施例提供的在域名系统中部署客户端子系统功能的方法。
根据本发明实施例的再一方面,提供一种计算机可读存储介质,计算机可读存储介质上存储有计算机程序指令,计算机程序指令被处理器执行时实现本发明实施例提供的在域名系统中部署客户端子系统功能的方法。
本发明实施例中的在域名系统中部署客户端子系统功能的方法、装置、设备和计算机可读存储介质,通过源地址变换的映射技术,在DNS载源查询过程中使用恒定的分区映射地址代替分区内多变的用户源地址,并将查询到的应答报文缓存在相应的缓存分区中,从而能够大幅降低递归流量、减少相关服务器的资源消耗,同时还能够实现资源的精准调度。
附图说明
为了更清楚地说明本发明实施例的技术方案,下面将对本发明实施例中所需要使用的附图作简单地介绍,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1示出本发明一实施例在域名系统中部署客户端子系统功能的方法的流程示意图;
图2示出本发明一实施例在域名系统中部署客户端子系统功能的装置的结构示意图;
图3示出本发明一实施例在域名系统中部署客户端子系统功能的设备的硬件结构示意图。
具体实施方式
下面将详细描述本发明的各个方面的特征和示例性实施例,为了使本发明的目的、技术方案及优点更加清楚明白,以下结合附图及实施例,对本发明进行进一步详细描述。应理解,此处所描述的具体实施例仅被配置为解释本发明,并不被配置为限定本发明。对于本领域技术人员来说,本发明可以在不需要这些具体细节中的一些细节的情况下实施。下面对实施例的描述仅仅是为了通过示出本发明的示例来提供对本发明更好的理解。
需要说明的是,在本文中,诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括……”限定的要素,并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
根据Google公司提出的ECS协议,权威服务器虽然能够获得初始发起DNS请求者的地址信息,但是对于来自不同用户地址段的同一个域名的查询请求,本地DNS需要对其分别进行递归查询和缓存,从而导致资源消耗大幅上升、缓存条目大量膨胀。并且,在上网用户呈爆发式增长和CDN不断细化的背景下,权威服务器基于ECS协议调度资源的准确度也在不断下降。针对于此,本发明提供了一种在域名系统中部署客户端子系统功能的方法,通过源地址变换的映射技术,在DNS载源查询过程中使用恒定的分区映射地址代替调度单元(即分区)内多变的用户源地址,用一个分区实现同一个调度单元下所有客户端IP地址段解析结果的缓存归并。
为了清楚地展示本发明实施例的方案和有益效果,在具体展开说明本发明实施例之前,首先对一些术语进行解释:
ECS:Google公司在【RFC7871】中描述的通过增加一种EDNS选项,实现在DNS报文中携带初始发起DNS请求者地址信息的方案。
客户端(Client):末端解析器,递归解析器(即后端递归模块)或者转发解析器(即前端缓存模块)的客户端。
末端解析器(Stub Resolver):遵循【RFC1034】中5.3.1章节的描述,在客户端的一个简单DNS协议实现。作为转发解析器或递归解析器的客户端。
权威服务器(Authoritative Nameserver):一个或多个DNS区的权威名字服务器。权威服务器一般不会直接和末端解析器或终端用户通信,而是和递归解析器通信。具体描述见【RFC1035】,第6章节。
递归解析器(Recursive Resolver):沿着域授权链为客户端进行域名解析的名字服务器。递归解析器经常使用缓存来加快对客户端查询的应答速度。具体描述见【RFC1035】,第7章节。
转发解析器(Forwarding Resolver):不自己进行迭代解析,而是将请求转发给其他递归解析器进行迭代解析的名字服务器,具体描述见【RFC2308】,第1章节。
图1示出了本发明一实施例在域名系统中部署客户端子系统功能的方法的流程图。参照图1,本发明实施例在域名系统中部署客户端子系统功能的方法主要包括S110至S160(包括S130-1和S130-2)。
在一些实施例中,在S110之前还包括ECS查询请求判断步骤。本地DNS接收到客户端发送的DNS查询请求,首先判断客户端发送的DNS查询请求是否为ECS查询请求。
其中,本地DNS包括前端缓存模块、ECS后端递归模块和普通后端递归模块。前端缓存模块承担转发解析器的功能,ECS后端递归模块和普通后端递归模块承担递归解析器的功能。在此需要说明的是,ECS后端递归模块用于对ECS查询请求(即需要携带用户地址的DNS查询请求)进行递归解析,普通后端递归模块用于对普通的DNS查询请求(即不需要携带用户地址的DNS查询请求)进行递归解析。并且在该步骤中,由本地DNS中的前端缓存模块来判断客户端发送的DNS查询请求是否为ECS查询请求。
在一些实施例中,在前端缓存模块确定客户端发送的DNS查询请求不是ECS查询请求(即普通的DNS查询请求)后,则将该DNS查询请求转发给普通后端递归模块。普通后端递归模块接收到该DNS查询请求后,继续将其转发给权威服务器进行递归查询。然后,权威服务器对该DNS查询请求进行解析,并将得到的应答报文返回给普通后端递归模块和前端缓存模块。最后,前端缓存模块将接收到的应答报文缓存在公共分区,并发送给客户端。
在前端缓存模块确定客户端发送的DNS查询请求是ECS查询请求后,则执行S110至S160。
在此需要说明的是,由于S110至S160中针对的对象是ECS查询请求。因此,在S110至S160中涉及的本地DNS的动作是指前端缓存模块或ECS后端递归模块的动作。
S110,本地域名系统DNS依据发送DNS查询请求的客户端地址所属的分区地址段进行匹配,得到客户端的分区。具体过程如下:
本地DNS将发送DNS查询请求的客户端的地址与分区地址段进行匹配,得到发送DNS查询请求的客户端所属的分区地址段。然后,本地DNS根据发送DNS查询请求的客户端所属的分区地址段以及分区地址段与分区的对应关系,得到客户端的分区(即客户端所属的分区)。
在一些实施例中,分区可以根据业务模型来进行规划。具体地,分区可以根据行政区域进行划分、可以根据用户类别进行划分,当然也可以根据行政区域和用户类别进行划分。其中,用户类别包括移动上网用户、家庭宽带上网用户或专线上网用户。
进一步地,一个分区地址段是一个分区中所有用户(客户端)地址的集合,且一个分区地址段中的各个地址互不重叠。其中,用户的地址可以是公网地址,也可以是私有地址,同时用户的地址不能重复使用,即一个用户地址只能唯一划分到一个分区地址段。并且,一个分区地址段对应一个分区。
作一个示例,分区根据行政区域进行划分。则一个分区地址段包括一个行政区域内所有网络拓扑位置相同的地址段。作一个具体的示例,以目前使用最广泛的CDN分发为例进行说明。在上网用户比较集中的省份,一些提供视频服务的内容服务商不再仅限于在省中心机房部署资源节点,已经开始将资源节点向地市机房下沉。例如,中国移动自建CDN随着扩容建设也在逐步将内容资源分发到地市级别。在这样的背景下,分区可以根据地市进行划分,即以一个地市划为一个分区。此时,一个分区地址段包含的就是一个地市的全部IP地址段。
在一些实施例中,每个分区及对应分区地址段的信息可以由人工静态配置到本地DNS中。因此,当运营商对用户源地址段进行调整(例如新增IP地址)时,可能会出现未及时更新本地DNS中分区配置的情况。在这样的情况下,对于部分用户(例如新增用户),本地DNS找不到其所属的分区地址段,进而无法得到这部分用户所属的分区。针对于此,在本地DNS中可以增加一个默认分区。对于找不到所属分区地址段的用户,本地DNS将其归属到默认分区,即这部分用户所属的分区为默认分区。
为了便于理解,作一个具体的示例,以江苏移动规划本地DNS的调度单元为地市级别进行说明。由于普通DNS查询请求和ECS查询请求共用一个前端缓存模块,则本地DNS中的前端缓存模块包括15个分区,分别为南京分区、苏州分区、无锡分区、常州分区、镇江分区、南通分区、徐州分区、扬州分区、泰州分区、盐城分区、淮安分区、连云港分区、宿迁分区、默认分区以及公共分区。其中,前14个分区是为ECS查询请求设置的。具体地:前13个分区分别对应一个分区地址段。例如,南京分区对应南京分区的分区地址段,且南京分区的分区地址段包括的是南京所有用户地址的集合。而对于发送ECS查询请求的用户,当其不属于上述13个分区中的任何一个时,则该用户属于默认分区。公共分区则是为普通的DNS查询请求设置的。另外,由于普通的DNS查询请求有一个独立的普通后端递归模块。因此,本地DNS中的ECS后端递归模块包括14个分区,分别为南京分区、苏州分区、无锡分区、常州分区、镇江分区、南通分区、徐州分区、扬州分区、泰州分区、盐城分区、淮安分区、连云港分区、宿迁分区以及默认分区。
进一步地,当中国移动自建CDN在江苏省的某几个区县也部署了资源节点时,则可以对这几个区县所属的地市分区进行进一步地划分。例如,中国移动自建CDN在南京市的所有区县都布置了资源节点、在苏州市的两个区县布置了资源节点,而在江苏省其他区县都未布置资源节点。在这种情况下,可以对南京分区和苏州分区进行进一步地划分(即增设二级分区)。作一个示例,以一个区县设置为一个二级分区,则在南京分区中再划分出11个二级分区,分别为鼓楼区、玄武区、秦淮区、建邺区、浦口区、栖霞区、雨花台区、江宁区、六合区、溧水区和高淳区,在苏州分区中再划分出2个分区,分别为姑苏区和吴江区,对其余的地市(江苏省中除去南京和苏州的其他地市)分区则不再进行划分。当然,也可以将南京分区中的若干个二级分区合并为一个二级分区,即将南京的几个区县合并设置为一个二级分区。例如,鼓楼分区和玄武分区合并为一个二级分区。在此还需要说明四点:其一,一个用户地址不能同时属于两个或两个以上的二级分区(即二级分区不能交叉);其二,一个用户地址可以不属于任何二级分区;其三,一个用户地址可以同时属于二级分区以及该二级分区所属的地市分区。其四,一个二级分区必须被包含在一个地市分区中。
当在一部分区县设置资源节点时,如果一步到位的将每个地市分区拆分到区县,分区的数量将会大大增加,从而映射地址配置和维护会变得非常麻烦,而通过二级分区的方法既能够简化ECS的配置,还可以提高调度的精准性以及灵活性。
S120,本地DNS判断客户端发送的DNS查询请求(即域名)在客户端的分区中是否为第一次请求。
具体地,本地DNS接收到客户端发送的DNS查询请求后,判断该请求在该客户端所属的分区中是否被查询过。
若客户端发送的DNS查询请求在客户端的分区中是为第一次请求,即客户端发送的DNS查询请求在客户端的分区中未被查询过,则执行步骤S130至S160。
S130,本地DNS基于预设的分区与分区映射地址的唯一映射关系,取出客户端的分区对应的分区映射地址。
在一些实施例中,每个分区(不包括公共分区)使用唯一映射地址进行指代,即为每个分区分配唯一的分区映射地址。其中,可以选取每个分区地址段中的一个合法公网IP地址作为该分区的分区映射地址。但分区映射地址的取值并不受限于使用本分区内的合法IPv4公网地址,可以是未分配给用户使用的空余地址,也可以是IPv6地址。选取IPv6地址作为分区映射地址,有利于细化调度的粒度。
进一步地,预设的分区与分区映射地址的唯一映射关系可以由DNS运营方公开发布,可以由DNS运营方与权威服务器共同协商,也可以由DNS运营方与权威服务器共同协商好之后,再由DNS运营方公开发布。DNS运营方通过公开发布、友好协商的方式来将映射关系告知各大CP、CDN厂商,能够使权威服务器准确识别分区映射地址代表的分区用户,从而让权威服务器具备主动精准调度的基础能力。
S140,本地DNS向权威服务器发送更新的DNS查询请求。其中,更新的DNS查询请求包括客户端的分区对应的分区映射地址。
在一些实施例中,客户端发送的DNS查询请求中未携带客户端地址信息。则本地DNS在客户端发送的DNS查询请求中增加该客户端的分区对应的分区映射地址,得到更新的DNS查询请求,并将更新的DNS查询请求发送给权威服务器。具体包括:
首先,本地DNS基于网络层的IP取出发送查询请求的客户端的地址,并将客户端的地址与分区地址段进行匹配,得到该客户端所属的分区地址段。其次,本地DNS根据分区地址段与分区的对应关系,得到该客户端的分区。然后,本地DNS根据分区与分区映射地址的唯一映射关系,取出客户端的分区对应的分区映射地址。最后,本地DNS在原始的DNS查询请求(即客户端发送的DNS查询请求)中增加客户端的分区对应的分区映射地址信息,得到更新的DNS查询请求,并将更新的DNS查询请求发送给权威服务器。其中,客户端地址前缀长度(SOURCE PREFIX-LENGTH)设置为32,客户端地址前缀(ADDRESS)设置为该客户端的分区对应的分区映射地址。
在一些实施例中,客户端发送的DNS查询请求中携带了客户端地址信息。则本地DNS取出该客户端的分区对应的分区映射地址,替换原始DNS查询请求中的客户端地址,得到更新的DNS查询请求,并将更新的DNS查询请求发送给权威服务器。具体可以通过以下任意一种方式来实现:
第一种:首先,本地DNS基于网络层的IP取出发送查询请求的客户端的地址,并将客户端的地址与分区地址段进行匹配,得到该客户端所属的分区地址段。其次,本地DNS根据分区地址段与分区的对应关系,得到该客户端的分区。然后,本地DNS根据分区与分区映射地址的唯一映射关系,取出客户端的分区对应的分区映射地址。最后,本地DNS用客户端的分区对应的分区映射地址替换原始DNS查询请求中的客户端地址,得到更新的DNS查询请求,并将更新的DNS查询请求发送给权威服务器。其中,客户端地址前缀长度(SOURCEPREFIX-LENGTH)设置为32,客户端地址前缀(ADDRESS)设置为该客户端的分区对应的分区映射地址。
第二种:首先,本地DNS从客户端发送的DNS查询请求中取出客户端的地址,并将客户端的地址与分区地址段进行匹配,得到该客户端所属的分区地址段。其次,本地DNS根据分区地址段与分区的对应关系,得到该客户端的分区。然后,本地DNS根据分区与分区映射地址的唯一映射关系,取出客户端的分区对应的分区映射地址。最后,本地DNS把原始DNS查询请求中的客户端地址替换为客户端的分区对应的分区映射地址,得到更新的DNS查询请求,并将更新的DNS查询请求发送给权威服务器。其中,客户端地址前缀长度(SOURCEPREFIX-LENGTH)设置为32,客户端地址前缀(ADDRESS)设置为该客户端的分区对应的分区映射地址。
由于发送给权威服务器的请求报文中使用的是用户所属分区的分区映射地址,因此只有直接接收用户查询请求的本地DNS知道用户的真实地址。并且,由于分区映射地址和用户地址没有关联,因此用户的隐私得到了有效的保障。
S150,权威服务器基于客户端的分区对应的分区映射地址,确定客户端发送的DNS查询请求的解析地址,发送包括解析地址的应答报文。
在该步骤中,由于更新的DNS查询请求中包含客户端发送的DNS查询请求和客户端的分区对应的分区映射地址,因此权威服务器在接收到更新的DNS查询请求时,会根据查询请求和分区映射地址确定出客户端发送的DNS查询请求的解析地址。进而,权威服务器根据客户端发送的DNS查询请求的解析地址及分区映射地址构造应答报文,并将应答报文返回给本地DNS。
上述已经指出权威服务器预先得知了分区与分区映射地址之间的关系,因此权威服务器依据分区映射地址可以实现精准的资源调度。并且,由于权威服务器预先得知了分区与分区映射地址之间的关系,因此在将用户调度至就近的服务节点(即确定客户端的解析地址)时,能够大大简化权威服务器的工作量。
同时,上述还指出了分区地址段包括私有地址且一个分区地址段对应一个分区,则当用户地址为私有地址时,本地DNS也可以得到该用户的分区,从而权威服务器依据分区映射地址就能够对该用户实现精准的资源调度。因此,对于地址为私有地址的用户,权威服务器也能够实现精准的资源调度。
另外,由于权威服务器依据分区映射地址调度资源,因此只要分区映射地址不改变,就无需对权威服务器进行任何调整,从而能够简化权威服务器的配置和维护难度。例如当互联网提供商(Internet Service Provider,ISP)变更了终端用户的网络地址及网络拓扑位置时,ISP管理人员只需及时调整本地DNS上的分区地址段配置即可,无需对权威服务器进行同步更新。
S160,本地DNS在客户端的分区对应的缓存分区中缓存应答报文,并发送给客户端。
在该步骤中,本地DNS接收到权威服务器返回的应答报文后,依据分区映射地址将该应答报文缓存到与客户端的分区对应的缓存分区中。并且,本地DNS根据发送DNS查询请求的客户端的IP地址、客户端发送查询请求的端口号以及DNS查询请求的编号,将应答报文发送给客户端。其中,如果客户端发送的查询请求中没有携带客户端的地址信息,则去除应答报文中的分区映射地址信息,并发送给客户端。如果客户端发送的查询请求中携带客户端的地址信息,则将应答报文中的分区映射地址修改为客户端的IP地址,并发送给客户端。
由于本地DNS依据分区映射地址将应答报文缓存到与客户端的分区对应的缓存分区中,因此同一分区中的同一查询请求的应答报文在相应的缓存分区中只有一份缓存,从而能够大大压缩缓存条目的数量、缓解缓存条目的膨胀。
因此,当本地DNS接收到一个客户端发送的DNS查询请求时,若该请求在客户端所在的分区中未被查询过,则通过上述步骤S130至S160来进行递归查询。
若客户端发送的DNS查询请求在客户端的分区中不是第一次请求,并且距上次请求时间未超过生存周期(Time To Live,TTL),则执行步骤S130-1。即,客户端发送的DNS查询请求在客户端的分区中被查询过,并且客户端发送DNS查询请求的时间距上次查询该DNS查询请求的时间没有超过生存周期,则执行步骤S130-1。换句话说,若客户端发送的DNS查询请求在客户端的分区中被查询过,并且对应客户端发送的DNS查询请求的应答报文还在有效期内,则执行步骤S130-1。
S130-1,本地DNS在客户端的分区对应的缓存分区中查询应答报文,并将查询到的应答报文发送给客户端。具体地:
在该步骤中,本地DNS查询到应答报文后,本地DNS根据发送DNS查询请求的客户端的IP地址、客户端发送查询请求的端口号以及DNS查询请求的编号,将查询到的应答报文发送给客户端。同样,如果客户端发送的查询请求中没有携带客户端的地址信息,则去除应答报文中的分区映射地址信息,并发送给客户端。如果客户端发送的查询请求中携带客户端的地址信息,则将应答报文中的分区映射地址修改为客户端的IP地址,并发送给客户端。
另外,若客户端发送的DNS查询请求在客户端的分区中不是第一次请求,并且距上次请求时间超过生存周期,则执行步骤S130-2。
S130-2,本地DNS设定客户端发送的DNS查询请求在客户端的分区中为第一次请求。具体地:
若客户端发送的DNS查询请求在客户端的分区中不是第一次请求,但客户端发送DNS查询请求的时间距上一次查询该DNS查询请求的时间已超过了生存周期(即客户端发送的域名的解析记录在本地DNS中已经不存在了),则本地DNS认定为客户端发送的DNS查询请求在客户端的分区中是第一次被查询,通过上述步骤S130至S160来进行递归查询。
在某一DNS查询请求的应答报文有效期内,当同一分区的用户对该DNS查询请求进行再次查询时,本地DNS可以直接将该DNS查询请求的应答报文发送给用户,无需再次向权威服务器发送递归请求。因此,能够大幅降低递归流量,减少前端缓存模块、ECS后端递归模块以及权威服务器的资源消耗。
本发明实施例在域名系统中部署客户端子系统功能的方法,使用恒定的分区映射地址代替分区内多变的用户源地址来进行DNS载源查询,并将查询到的应答报文缓存在相应的缓存分区中。由于权威服务器能够准确识别分区映射地址代表的分区,且同一分区的用户对同一域名进行查询时可以直接使用缓存分区中的应答报文进行应答,无需再次进行递归请求。因此,本发明实施例在域名系统中部署客户端子系统功能的方法,能够大幅降低递归流量、减少相关服务器的资源消耗,同时还能够实现资源的精准调度。
下面结合图2详细介绍本发明实施例的在域名系统中部署客户端子系统功能的装置。图2示出了根据本发明另一实施例提供的在域名系统中部署客户端子系统功能的装置的结构示意图。如图2所示,在域名系统中部署客户端子系统功能的装置200包括:
匹配模块210,用于本地DNS依据发送DNS查询请求的客户端地址所属的分区地址段进行匹配,得到客户端的分区。
在一些实施例中,分区可以根据业务模型来进行规划。具体地,分区可以根据行政区域进行划分、可以根据用户类别进行划分,当然也可以根据行政区域和用户类别进行划分。其中,用户类别包括移动上网用户、家庭宽带上网用户或专线上网用户。
在一些实施例中,分区地址段可以包括一个行政区域内所有网络拓扑位置相同的地址段。进一步地,分区地址段可以包括公网地址,也可以包括私有地址。另外,本地DNS包括前端缓存模块和ECS后端递归模块。
判断模块220,用于本地DNS判断客户端发送的DNS查询请求在客户端的分区中是否为第一次请求。
获取模块230,用于若客户端发送的DNS查询请求在客户端的分区中是为第一次请求,则本地DNS基于预设的分区与分区映射地址的唯一映射关系,取出客户端的分区对应的分区映射地址。
在一些实施例中,分区映射地址可以选取每个分区地址段中的一个合法公网IP地址作为该分区的分区映射地址。但分区映射地址的取值并不受限于使用本分区内的合法IPv4公网地址,可以是未分配给用户使用的空余地址,也可以是IPv6地址。
进一步地,预设的分区与分区映射地址的唯一映射关系可以由DNS运营方公开发布,可以由DNS运营方与权威服务器共同协商,也可以由DNS运营方与权威服务器共同协商好之后,再由DNS运营方公开发布。
发送模块240,用于本地DNS向权威服务器发送更新的DNS查询请求,更新的DNS查询请求包括客户端的分区对应的分区映射地址。
确定模块250,用于权威服务器基于客户端的分区对应的分区映射地址,确定客户端发送的DNS查询请求的解析地址,发送包括解析地址的应答报文。
缓存模块260,用于本地DNS在客户端的分区对应的缓存分区中缓存应答报文,并发送给客户端。
查询模块270,用于若客户端发送的DNS查询请求在客户端的分区中不是第一次请求并且距上次请求时间未超过生存周期,本地DNS在客户端的分区对应的缓存分区中查询应答报文,并将查询到的应答报文发送给客户端。
设定模块280,用于若客户端发送的DNS查询请求在客户端的分区中不是第一次请求并且距上次请求时间超过生存周期,本地DNS设定客户端发送的DNS查询请求在客户端的分区中为第一次请求。
在一些实施例中,在域名系统中部署客户端子系统的装置200还包括:
ECS查询请求确定模块,用于本地DNS确定客户端发送的DNS查询请求是ECS查询请求。
根据本发明实施例的在域名系统中部署客户端子系统功能的装置的其他细节与以上结合图1描述的根据本发明实施例的在域名系统中部署客户端子系统功能的方法类似,在此不再赘述。
通过本发明实施例提供的在域名系统中部署客户端子系统功能的装置,不仅能够减少相关服务器的资源消耗,还能够实现资源的精准调度。
结合图1和图2描述的根据本发明实施例的在域名系统中部署客户端子系统功能的方法和装置可以由在域名系统中部署客户端子系统功能的设备来实现。图3是示出根据发明实施例的在域名系统中部署客户端子系统功能的设备的硬件结构300示意图。
如图3所示,本实施例中的在域名系统中部署客户端子系统功能的设备300包括输入设备301、输入接口302、中央处理器303、存储器304、输出接口305、以及输出设备306。其中,输入接口302、中央处理器303、存储器304、以及输出接口305通过总线310相互连接,输入设备301和输出设备306分别通过输入接口302和输出接口305与总线310连接,进而与在域名系统中部署客户端子系统功能的设备300的其他组件连接。
具体地,输入设备301接收来自外部的输入信息,并通过输入接口302将输入信息传送到中央处理器303;中央处理器303基于存储器304中存储的计算机可执行指令对输入信息进行处理以生成输出信息,将输出信息临时或者永久地存储在存储器304中,然后通过输出接口305将输出信息传送到输出设备306;输出设备306将输出信息输出到在域名系统中部署客户端子系统功能的设备300的外部供用户使用。
也就是说,图3所示的在域名系统中部署客户端子系统功能的设备也可以被实现为包括:存储有计算机可执行指令的存储器;以及处理器,该处理器在执行计算机可执行指令时可以实现结合图1和图2描述的在域名系统中部署客户端子系统功能的方法和装置。
在一个实施例中,图3所示的在域名系统中部署客户端子系统功能的设备300包括:存储器304,用于存储程序;处理器303,用于运行存储器中存储的程序,以执行本发明实施例在域名系统中部署客户端子系统功能的方法。
本发明实施例提供的在域名系统中部署客户端子系统功能的设备,能够在减少相关服务器资源消耗的同时还实现资源的精准调度。
本发明实施例还提供一种计算机可读存储介质,该计算机可读存储介质上存储有计算机程序指令;该计算机程序指令被处理器执行时实现本发明实施例提供的在域名系统中部署客户端子系统功能的方法。
需要明确的是,本发明并不局限于上文所描述并在图中示出的特定配置和处理。为了简明起见,这里省略了对已知方法的详细描述。在上述实施例中,描述和示出了若干具体的步骤作为示例。但是,本发明的方法过程并不限于所描述和示出的具体步骤,本领域的技术人员可以在领会本发明的精神后,作出各种改变、修改和添加,或者改变步骤之间的顺序。
以上所述的结构框图中所示的功能块可以实现为硬件、软件、固件或者它们的组合。当以硬件方式实现时,其可以例如是电子电路、专用集成电路(ASIC)、适当的固件、插件、功能卡等等。当以软件方式实现时,本发明的元素是被用于执行所需任务的程序或者代码段。程序或者代码段可以存储在机器可读介质中,或者通过载波中携带的数据信号在传输介质或者通信链路上传送。“机器可读介质”可以包括能够存储或传输信息的任何介质。机器可读介质的例子包括电子电路、半导体存储器设备、ROM、闪存、可擦除ROM(EROM)、软盘、CD-ROM、光盘、硬盘、光纤介质、射频(RF)链路,等等。代码段可以经由诸如因特网、内联网等的计算机网络被下载。
还需要说明的是,本发明中提及的示例性实施例,基于一系列的步骤或者装置描述一些方法或系统。但是,本发明不局限于上述步骤的顺序,也就是说,可以按照实施例中提及的顺序执行步骤,也可以不同于实施例中的顺序,或者若干步骤同时执行。
以上所述,仅为本发明的具体实施方式,所属领域的技术人员可以清楚地了解到,为了描述的方便和简洁,上述描述的系统、模块和单元的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。应理解,本发明的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本发明揭露的技术范围内,可轻易想到各种等效的修改或替换,这些修改或替换都应涵盖在本发明的保护范围之内。
Claims (11)
1.一种在域名系统中部署客户端子系统功能的方法,其特征在于,包括:
本地域名系统DNS依据发送DNS查询请求的客户端地址所属的分区地址段进行匹配,得到所述客户端的分区;其中,所述客户端地址为公网地址或私有地址;
所述本地DNS判断所述客户端发送的DNS查询请求在所述客户端的分区中是否为第一次请求;
若所述客户端发送的DNS查询请求在所述客户端的分区中是为第一次请求,则所述本地DNS基于预设的分区与分区映射地址的唯一映射关系,取出所述客户端的分区对应的分区映射地址;
所述本地DNS向权威服务器发送更新的DNS查询请求,所述更新的DNS查询请求包括所述客户端的分区对应的分区映射地址;
所述权威服务器基于所述客户端的分区对应的分区映射地址,确定所述客户端发送的DNS查询请求的解析地址,发送包括所述解析地址的应答报文;
所述本地DNS在所述客户端的分区对应的缓存分区中缓存所述应答报文,并发送给所述客户端;
若所述客户端发送的DNS查询请求在所述客户端的分区中不是第一次请求并且距上次请求时间未超过生存周期,所述本地DNS在所述客户端的分区对应的缓存分区中查询应答报文,并将查询到的应答报文发送给所述客户端;
若所述客户端发送的DNS查询请求在所述客户端的分区中不是第一次请求并且距上次请求时间超过所述生存周期,所述本地DNS设定所述客户端发送的DNS查询请求在所述客户端的分区中为第一次请求。
2.根据权利要求1所述在域名系统中部署客户端子系统功能的方法,其特征在于,所述分区根据行政区域和/或用户类别进行划分;其中,所述用户类别包括移动上网用户、家庭宽带上网用户或专线上网用户。
3.根据权利要求2所述在域名系统中部署客户端子系统功能的方法,其特征在于,所述分区地址段包括一个行政区域内所有网络拓扑位置相同的地址段。
4.根据权利要求1所述在域名系统中部署客户端子系统功能的方法,其特征在于,所述分区映射地址包括互联网协议第四版IPv4公网地址、未分配给用户的空余地址、或互联网协议第六版IPv6地址。
5.根据权利要求1所述在域名系统中部署客户端子系统功能的方法,其特征在于,所述本地DNS包括前端缓存模块和ECS后端递归模块。
6.根据权利要求1所述在域名系统中部署客户端子系统功能的方法,其特征在于,所述唯一映射关系由DNS运营方公开发布,和/或由DNS运营方与所述权威服务器协商。
7.根据权利要求1所述在域名系统中部署客户端子系统功能的方法,其特征在于,所述分区地址段包括公网地址和/或私有地址。
8.根据权利要求1所述在域名系统中部署客户端子系统功能的方法,其特征在于,在所述本地DNS依据发送DNS查询请求的客户端地址所属的分区地址段进行匹配,得到所述客户端的分区之前,还包括:
本地DNS确定客户端发送的DNS查询请求是ECS查询请求。
9.一种在域名系统中部署客户端子系统功能的装置,其特征在于,所述装置包括:
匹配模块,用于本地DNS依据发送DNS查询请求的客户端地址所属的分区地址段进行匹配,得到所述客户端的分区;其中,所述客户端地址为公网地址或私有地址;
判断模块,用于所述本地DNS判断所述客户端发送的DNS查询请求在所述客户端的分区中是否为第一次请求;
获取模块,用于若所述客户端发送的DNS查询请求在所述客户端的分区中是为第一次请求,则所述本地DNS基于预设的分区与分区映射地址的唯一映射关系,取出所述客户端的分区对应的分区映射地址;
发送模块,用于所述本地DNS向权威服务器发送更新的DNS查询请求,所述更新的DNS查询请求包括所述客户端的分区对应的分区映射地址;
确定模块,用于所述权威服务器基于所述客户端的分区对应的分区映射地址,确定所述客户端发送的DNS查询请求的解析地址,发送包括所述解析地址的应答报文;
缓存模块,用于所述本地DNS在所述客户端的分区对应的缓存分区中缓存所述应答报文,并发送给所述客户端;
查询模块,用于若所述客户端发送的DNS查询请求在所述客户端的分区中不是第一次请求并且距上次请求时间未超过生存周期,所述本地DNS在所述客户端的分区对应的缓存分区中查询应答报文,并将查询到的应答报文发送给所述客户端;
设定模块,用于若所述客户端发送的DNS查询请求在所述客户端的分区中不是第一次请求并且距上次请求时间超过所述生存周期,所述本地DNS设定所述客户端发送的DNS查询请求在所述客户端的分区中为第一次请求。
10.一种在域名系统中部署客户端子系统功能的设备,其特征在于,所述设备包括:处理器以及存储有计算机程序指令的存储器;
所述处理器执行所述计算机程序指令时实现如权利要求1-8任意一项所述的在域名系统中部署客户端子系统功能的方法。
11.一种计算机可读存储介质,其特征在于,所述计算机可读存储介质上存储有计算机程序指令,所述计算机程序指令被处理器执行时实现如权利要求1-8任意一项所述的在域名系统中部署客户端子系统功能的方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201711328098.3A CN107896257B (zh) | 2017-12-13 | 2017-12-13 | 部署客户端子系统功能的方法、装置、设备和介质 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201711328098.3A CN107896257B (zh) | 2017-12-13 | 2017-12-13 | 部署客户端子系统功能的方法、装置、设备和介质 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN107896257A CN107896257A (zh) | 2018-04-10 |
CN107896257B true CN107896257B (zh) | 2021-08-27 |
Family
ID=61807394
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201711328098.3A Active CN107896257B (zh) | 2017-12-13 | 2017-12-13 | 部署客户端子系统功能的方法、装置、设备和介质 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN107896257B (zh) |
Families Citing this family (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110505317A (zh) * | 2018-05-17 | 2019-11-26 | 阿里巴巴集团控股有限公司 | 域名解析方法及装置 |
CN111193672B (zh) * | 2019-12-06 | 2023-05-26 | 新浪技术(中国)有限公司 | 一种流量精细化调度的方法及系统 |
CN110995872B (zh) * | 2019-12-25 | 2020-07-17 | 中国传媒大学 | 边缘缓存网络能量消耗计算方法、系统、装置 |
CN114363287B (zh) * | 2020-10-13 | 2022-12-20 | 中国电信股份有限公司 | 域名递归查询方法、装置、递归服务器以及dns系统 |
CN114598677B (zh) * | 2020-11-20 | 2024-06-28 | 中国电信股份有限公司 | Cdn调度方法及系统、智能网卡、电子设备 |
CN115086275B (zh) * | 2021-03-12 | 2024-03-08 | 中国电信股份有限公司 | 报文处理方法、装置、介质及电子设备 |
CN114827083A (zh) * | 2022-04-14 | 2022-07-29 | 中国电信股份有限公司 | 域名解析方法、系统以及ecs递归服务器 |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105376344A (zh) * | 2015-11-26 | 2016-03-02 | 中国互联网络信息中心 | 一种与源地址相关的递归域名服务器的解析方法及系统 |
CN106790530A (zh) * | 2016-12-21 | 2017-05-31 | 北京云端智度科技有限公司 | 域名服务的跟踪和聚合方法 |
Family Cites Families (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10530734B2 (en) * | 2014-12-16 | 2020-01-07 | Verisign, Inc. | Balancing visibility in the domain name system |
US10079800B2 (en) * | 2015-10-14 | 2018-09-18 | Nominum, Inc. | Client subnet efficiency by equivalence class aggregation |
-
2017
- 2017-12-13 CN CN201711328098.3A patent/CN107896257B/zh active Active
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105376344A (zh) * | 2015-11-26 | 2016-03-02 | 中国互联网络信息中心 | 一种与源地址相关的递归域名服务器的解析方法及系统 |
CN106790530A (zh) * | 2016-12-21 | 2017-05-31 | 北京云端智度科技有限公司 | 域名服务的跟踪和聚合方法 |
Also Published As
Publication number | Publication date |
---|---|
CN107896257A (zh) | 2018-04-10 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN107896257B (zh) | 部署客户端子系统功能的方法、装置、设备和介质 | |
US11909639B2 (en) | Request routing based on class | |
US10148612B2 (en) | Method and system for increasing speed of domain name system resolution within a computing device | |
US7991910B2 (en) | Updating routing information based on client location | |
US20070253377A1 (en) | Apparatus and method for name resolution in an aggregation of mobile networks | |
CN107786678B (zh) | 域名解析方法、装置及系统 | |
US8161135B2 (en) | Device identification number based name service | |
WO2010057192A1 (en) | Request routing and updating routing information utilizing client location information | |
CN111327714A (zh) | 域名递归查询方法、系统以及服务器、dns系统 | |
US20090024761A1 (en) | Method, system and application for service addressing | |
CN115668889A (zh) | 用于可变长度地址(vla)网络的域名系统(dns)服务 | |
CN109819059B (zh) | 管理网络设备的方法、装置、设备及存储介质 | |
Angel et al. | A hierarchical mapping system approach for ID-to-Locator resolution |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |