CN109936632B - 一种应用于dns权威服务器的cname加速方法 - Google Patents
一种应用于dns权威服务器的cname加速方法 Download PDFInfo
- Publication number
- CN109936632B CN109936632B CN201910172536.4A CN201910172536A CN109936632B CN 109936632 B CN109936632 B CN 109936632B CN 201910172536 A CN201910172536 A CN 201910172536A CN 109936632 B CN109936632 B CN 109936632B
- Authority
- CN
- China
- Prior art keywords
- server
- dns
- cname
- domain name
- name
- 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
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明公开了一种应用于DNS权威服务器的CNAME加速方法,包括:所查询域名托管的权威服务器设置多级CNAME,本地名称服务器将DNS查询请求发至所查询域名托管的权威服务器,如果存在多级CNAME,权威服务器会内部迭代查询CNAME,找到最终的CNAME记录或A记录,将找到的CNAME记录或A记录返回给本地名称服务器,本地名称服务器将DNS域名查询结果缓存并返回给用户。本发明方法,通过权威服务器内部自动进行的多级CNAME查询,可以使远端递归服务器直接获取到查询结果,而无需进行多次迭代查询,极大提升了递归服务器的查询效率,同时也降低了解析时延。
Description
技术领域
本发明涉及DNS权威服务器技术领域,具体涉及一种应用于DNS权威服务器的CNAME加速方法。
背景技术
DNS(Domain Name System,域名系统)最早于1982年有保罗·莫卡派乔斯发明;原始的技术规范在882号因特网标准草案(RFC 882)中发布。1987年发布的第1034和1035号草案修正了DNS技术规范,并且废除了之前的地882和883号草案。在此之后对因特网标准草案的修改基本上没有涉及到DNS技术规范部分的改动。
现今在DNS系统中,常见的资源记录类型有以下几种:
一、主机记录(A记录):于RFC 1035中定义,A记录是用于指定主机(或域名)对应的IP地址记录;
二、别名记录(CNAME记录):于RFC 1035中定义,CNAME记录用于将多个别名绑定在一个A记录上;
三、域名服务器记录(NS记录):于RFC 1035中定义,用来指定哪些域名是由哪些DNS服务期解析的;
四、IPv6主机记录(AAAA记录):于RFC 3596中定义,于A记录对应将域名解析到指定的IPv6的IP上。
DNS一般查询流程如图1所示,包括以下步骤:
1)客户端向本机配置的本地名称服务器发出DNS域名查询请求;
2)本地名称服务器收到请求,先查询本地的缓存,如果有该域名的缓存,则本地名称服务器将DNS域名查询结果缓存并返回给用户,结束本次DNS域名查询;如果没有该域名的记录,本地名称服务器再以DNS客户端的角色发送与步骤1)中一样的DNS域名查询请求至根名称服务器;根名称服务器收到DNS请求后,把所请求的DNS域名中顶级域所对应的顶级域名称服务器A名称及地址返回给本地名称服务器;
3)本地名称服务器根据根名称服务器返回的顶级域名称服务器A地址,向对应的顶级域名称服务器A发送与步骤1)中一样的DNS域名查询请求;顶级域名称服务器A在收到DNS查询请求后,把所请求的DNS域名中下一级子域所对应的名称服务器名称及地址返回给本地名称服务器,根据逐级授权机制,最终本地名称服务器获取到所查询域名的权威服务器;
4)本地名称服务器将DNS查询请求发至所查询域名托管的权威服务器,权威服务器将DNS请求结果返回给本地名称服务器;
5)重复步骤1)至4),直至权威服务器将客户端需要的DNS请求结果返回给本地名称服务器,本地名称服务器将DNS域名查询结果缓存并返回给用户,结束本次DNS域名查询;
基于上述步骤,我们发现在多级CNAME的情况下,一次DNS查询会经历多次重复的迭代查询,极大影响了查询效率以及响应时延,影响用户体验,而该场景在普通CDN(Content Delivery Network,即内容分发网络)业务中会频繁出现,于是为了更好地处理这种场景,本发明提出了一种应用于DNS权威服务器的CNAME加速方法。
发明内容
本发明提供了一种应用于DNS权威服务器的CNAME加速方法,解决了多级CNAME导致一次DNS查询经历多次重复的迭代查询动作,从而影响解析效率、增加权威服务器的压力问题。
一种应用于DNS权威服务器的CNAME加速方法,包括以下步骤:
1)客户端向本机配置的本地名称服务器发出DNS域名查询请求;
2)本地名称服务器收到请求,先查询本地的缓存,如果有该域名的缓存,则本地名称服务器将DNS域名查询结果缓存并返回给用户,结束本次DNS域名查询;如果没有该域名的记录,本地名称服务器再以DNS客户端的角色发送与步骤1)中一样的DNS域名查询请求至根名称服务器;根名称服务器收到DNS请求后,把所请求的DNS域名中顶级域所对应的顶级域名称服务器A名称及地址返回给本地名称服务器;
3)本地名称服务器根据根名称服务器返回的顶级域名称服务器A地址,向对应的顶级域名称服务器A发送与步骤1)中一样的DNS域名查询请求;顶级域名称服务器A在收到DNS查询请求后,把所请求的DNS域名中下一级子域所对应的名称服务器名称及地址返回给本地名称服务器,根据逐级授权机制,最终本地名称服务器获取到所查询域名的权威服务器;
4)所查询域名托管的权威服务器设置多级CNAME,本地名称服务器将DNS查询请求发至所查询域名托管的权威服务器,如果存在多级CNAME,权威服务器会内部迭代查询CNAME,找到最终的CNAME记录或A记录,将找到的CNAME记录或A记录返回给本地名称服务器,本地名称服务器将DNS域名查询结果缓存并返回给用户。
本发明中,本地名称服务器迭代查询到权威名称服务器的DNS请求返回的是CNAME,权威名称服务器内部能够自动查询CNAME的结果并返回给客户端,包括托管在权威服务器的不同域的跨域CNAME查询。
步骤4)中,所查询域名托管的权威服务器设置多级CNAME,具体包括:配置多级CNAME,同步到各个的所查询域名托管的权威服务器。
现有的同步方式一般为DNS服务器的同步方式。数据中心部署主DNS服务器,同时在多个地区部署从DNS服务器,通过主DNS服务器向多个从DNS服务器发送同步数据。这种传统的同步方式首先是同步速度较慢,而且主DNS服务器的压力会比较大(同时更新新的DNS记录,处理DNS请求,发送DNS同步数据)。
本发明中,同步到各个的所查询域名托管的权威服务器,具体包括:
I)通过在数据中心部署主redis集群和redis哨兵,通过redis哨兵实时监控主redis集群服务状态出现故障做到及时的故障转移;
II)部署多台从redis服务器,主redis集群将主redis的数据发送给从redis服务器,将从redis同步;
III)所查询域名托管的权威服务器从从redis服务器获取并更新数据,数据包括多级CNAME、A记录、AAAA记录等。
所查询域名托管的权威服务器则均匀分布在各个地区,每个权威服务器只需要获取最近的从redis服务器的数据即可。
步骤II)中,边缘(不属于数据中心的主机)以及中心部署多台从redis同步主redis的数据,DNS服务器则均匀分布在各个地区,每个DNS服务器只需要获取最近的从redis服务器的数据即可。
如果存在多级CNAME,权威服务器会内部迭代查询CNAME,查询CNAME的限制最大层级数为6级,如果CNAME查询到6级之后还没有得到相应的A记录或者AAAA记录,那么权威服务器(即权威名称服务器)会将CNAME返回给客户端。查询CNAME的限制最大层级数为6级,能够保证权威服务器的解析效率,并且避免权威服务器的压力。
权威服务器会内部迭代查询CNAME,具体包括:
A、用户的DNS请求迭代查询到使用的权威服务器上;
B、权威服务器先识别用户所在的地区以及运行商信息;
C、权威服务器带着地区以及运行商信息以及用户的DNS请求进行内部查询。
步骤C中,内部查询包括:
a、将DNS记录用redis哈希(hash)结构存储起来;
b、查询多级CNAME的过程中,该条CNAME会存在多个域,根据带权轮询算法选取CNAME;
c、查询到A记录,根据权威服务器带着地区以及运行商信息,返回跟权威服务器带着地区以及运行商信息最相关的结果,作为最佳结果。
步骤b可以缓解某个域下压力过大。
在常规的DNS协议下,DNS记录要以某种格式存储下来而这种传统的存储形式解析起来比较复杂,查询的时间复杂度较高
本发明改变了原有的DNS记录存储格式,将这些记录用类似字典的形式存储起来,即采用redis哈希(hash)结构存储,这样服务器查询的速度会大大加快,当然我们能够采取这样的格式取决于我们特殊的DNS数据同步方式。
本发明同时实现了CNAME和A记录的负载均衡以及智能调度功能。
本发明实现了CNAME与A记录的负载均衡。本发明本身实现了契合DNS查询场景的带权循环调度算法,通过认为可配置的方式实现了CNAME与A记录的负载均衡。
该项发明集成并调用实时更新的基于用户IP地理位置信息以及运营商归属地的地址库,能够保证返回的结果尽可能的靠近发送DNS请求的客户端所属地。
与现有技术相比,本发明具有如下优点:
本发明大大减少了客服端访问权威名称服务器的频率,减少了顶级域名称服务器以及权威名称服务器的压力。
本发明大大减少了多级CNAME下客户端递归查询的次数,减少了DNS的解析时间。
本发明极大提升了客户端体验及安全性,缩短打开网页时间的同时,降低被劫持的风险。
本发明的应用于DNS权威服务器的CNAME加速方法,通过权威服务器内部自动进行的多级CNAME查询,可以使远端递归服务器直接获取到查询结果,而无需进行多次迭代查询,降低了远端递归服务器与权威服务器的交互次数,极大提升了递归服务器的查询效率,同时也降低了解析时延。
附图说明
图1为现有技术中一般DNS查询流程的示意图;
图2为本发明应用于DNS权威服务器的CNAME加速方法实现的DNS查询流程的示意图;
图3为本发明中CNAME加速内部实现流程的示意图;
图4为本发明数据同步机制的示意图;
图5为现有技术中常规数据同步机制的示意图。
具体实施方式
如图1所示,为现有技术中一般DNS查询流程的示意图。
如图2所示,为本发明一种应用于DNS权威服务器的CNAME加速方法,包括以下步骤:
1)客户端向本机配置的本地名称服务器发出DNS域名查询请求;
2)本地名称服务器收到请求,先查询本地的缓存,如果有该域名的缓存,则本地名称服务器将DNS域名查询结果缓存并返回给用户,结束本次DNS域名查询;如果没有该域名的记录,本地名称服务器再以DNS客户端的角色发送与步骤1)中一样的DNS域名查询请求至根名称服务器;根名称服务器收到DNS请求后,把所请求的DNS域名中顶级域所对应的顶级域名称服务器A名称及地址返回给本地名称服务器;
3)本地名称服务器根据根名称服务器返回的顶级域名称服务器A地址,向对应的顶级域名称服务器A发送与步骤1)中一样的DNS域名查询请求;顶级域名称服务器A在收到DNS查询请求后,把所请求的DNS域名中下一级子域所对应的名称服务器名称及地址返回给本地名称服务器,根据逐级授权机制,最终本地名称服务器获取到所查询域名的权威服务器;
4)所查询域名托管的权威服务器设置多级CNAME,本地名称服务器将DNS查询请求发至所查询域名托管的权威服务器,如果存在多级CNAME,权威服务器会内部迭代查询CNAME,找到最终的CNAME记录或A记录,将找到的CNAME记录或A记录返回给本地名称服务器,本地名称服务器将DNS域名查询结果缓存并返回给用户。
如图3所示,为本发明中CNAME加速内部实现流程,权威服务器会内部迭代查询CNAME,具体包括:
A、用户的DNS请求迭代查询到使用的权威服务器上;
B、权威服务器先识别用户所在的地区以及运行商信息;
C、权威服务器带着地区以及运行商信息以及用户的DNS请求进行内部查询。
步骤C中,内部查询包括:
a、将DNS记录用redis哈希(hash)结构存储起来;
b、查询多级CNAME的过程中,该条CNAME会存在多个域,根据带权轮询算法选取CNAME;
c、查询到A记录,根据权威服务器带着地区以及运行商信息,返回跟权威服务器带着地区以及运行商信息最相关的结果,作为最佳结果。
图3对本发明进行更全面的描述:
首先用户的DNS请求迭代查询到使用的权威服务器上。权威服务器先识别用户所在的地区以及运行商信息,然后权威服务器带着这些信息进行内部查询。
以xxx.upyun.com的DNS请求为例子。
该DNS服务器发现xxx.upyun.com属于upyun.com的域。
于是该DNS服务器便往upyun.com域下面的记录开始查寻找。
在常规的DNS协议下,DNS记录要以某种格式存储下来而这种传统的存储形式解析起来比较复杂,查询的时间复杂度较高。
本发明改变了原有的DNS记录存储格式,将这些记录用类似字典的形式[redis哈希(hash)结构,采用KV键值对]存储起来,这样权威服务器查询的速度会大大加快,当然我们能够采取这样的格式取决于我们特殊的DNS数据同步方式(下面会详细介绍)。
由于本发明内部还实现了CNAME负载均衡(为了缓解某个域下的压力过大,我们会将一个域下的域名CNAME到另一个域下或者是该域的其他域名下面)DNS权威服务器会获取到多个域名a.upyun.com,b.upyun.com,c.upcdn.net,d.ialloc.com。该DNS权威服务器会根据带权轮询算法选取CNAME。
如果拿取到了c.upcdn.net,即使upcdn.net与upyun.com已经不属于同一个域下了但是只要是托管与该DNS权威服务器的域都能继续查询直到得到相应记录,获取多个域名如61.152.73.208,111.62.9.80,111.62.9.72。本发明实现的DNS记录存储形式保证了不同域之间的切换查询高效迅速。
最终在返回结果选择上我们还会依据用户的地理位置以及运营商信息返回最佳结果。
同时该项发明还优化了DNS服务器的同步形式,如下图4中所示。配置多级CNAME,同步到各个的所查询域名托管的权威服务器。同步到各个的所查询域名托管的权威服务器,具体包括:
I)通过在数据中心部署主redis集群和redis哨兵,通过redis哨兵实时监控主redis集群服务状态出现故障做到及时的故障转移;
II)部署多台从redis服务器,主redis集群将主redis的数据发送给从redis服务器,将从redis同步;
III)所查询域名托管的权威服务器从从redis服务器获取并更新数据,数据包括多级CNAME、A记录、AAAA记录等。
所查询域名托管的权威服务器则均匀分布在各个地区,每个权威服务器只需要获取最近的从redis服务器的数据即可。
对于DNS权威服务器,架构上不会只部署一台,只部署一台会导致某些地区DNS请求响应太慢,所以一般DNS权威服务器的部署都会覆盖多个地区,然而当DNS权威服务器覆盖范围变大的时候同步数据就变得比较困难。
图5是一般DNS服务器的同步方式。数据中心部署主DNS服务器,同时在多个地区部署从DNS服务器,通过主DNS服务器向多个从DNS服务器发送同步数据。这种传统的同步方式首先是同步速度较慢,而且主DNS服务器的压力会比较大。同时更新新的DNS记录,处理DNS请求,发送DNS同步数据。
如图4所示,本发明采用了不同的同步方式,通过在数据中心部署主redis集群,通过redis哨兵实时监控主redis服务状态做到及时的状态转移。边缘以及中心部署多台从redis同步主redis的数据,DNS服务器则均匀分布在各个地区,每个DNS服务器只需要获取最近的从redis服务器的数据即可。这种设计主要利用了redis的读写高效性确保了同步的高速。同步的高速使得我们能够对CNAME做一些灵活的调整加速DNS查询。
本发明利用了redis中的hash结构(hash是一个string类型的field和value的映射表)来存储DNS记录,使得DNS服务器能够快速查找到相应记录。相对来说DNS协议中的DNS记录形式就显得笨重不易处理。
本发明的同步实现中并没有所谓的主从DNS服务器,不会出现单台DNS服务器压力过大导致DNS查询速度变慢的情况。
Claims (2)
1.一种应用于DNS权威服务器的CNAME加速方法,其特征在于,包括以下步骤:
1)客户端向本机配置的本地名称服务器发出DNS域名查询请求;
2)本地名称服务器收到请求,先查询本地的缓存,如果有该域名的缓存,则本地名称服务器将DNS域名查询结果缓存并返回给用户,结束本次DNS域名查询;如果没有该域名的记录,本地名称服务器再以DNS客户端的角色发送与步骤1)中一样的DNS域名查询请求至根名称服务器;根名称服务器收到DNS请求后,把所请求的DNS域名中顶级域所对应的顶级域名称服务器A名称及地址返回给本地名称服务器;
3)本地名称服务器根据根名称服务器返回的顶级域名称服务器A地址,向对应的顶级域名称服务器A发送与步骤1)中一样的DNS域名查询请求;顶级域名称服务器A在收到DNS查询请求后,把所请求的DNS域名中下一级子域所对应的名称服务器名称及地址返回给本地名称服务器,根据逐级授权机制,最终本地名称服务器获取到所查询域名的权威服务器;
4)所查询域名托管的权威服务器设置多级CNAME,本地名称服务器将DNS查询请求发至所查询域名托管的权威服务器,如果存在多级CNAME,权威服务器会内部迭代查询CNAME,找到最终的CNAME记录或A记录,将找到的CNAME记录或A记录返回给本地名称服务器,本地名称服务器将DNS域名查询结果缓存并返回给用户;
所查询域名托管的权威服务器设置多级CNAME,具体包括:配置多级CNAME,同步到各个的所查询域名托管的权威服务器;
同步到各个的所查询域名托管的权威服务器,具体包括:
I)通过在数据中心部署主redis集群和redis哨兵,通过redis哨兵实时监控主redis集群服务状态出现故障做到及时的故障转移;
II)部署多台从redis服务器,主redis集群将主redis的数据发送给从redis服务器,将从redis同步;
III)所查询域名托管的权威服务器从从redis服务器获取并更新数据,数据包括多级CNAME、A记录、AAAA记录;
权威服务器会内部迭代查询CNAME,具体包括:
A、用户的DNS请求迭代查询到使用的权威服务器上;
B、权威服务器先识别用户所在的地区以及运行商信息;
C、权威服务器带着地区以及运行商信息以及用户的DNS请求进行内部查询,内部查询包括:
a、将DNS记录用redis哈希结构存储起来;
b、查询多级CNAME的过程中,该条CNAME会存在多个域,根据带权轮询算法选取CNAME;
c、查询到A记录,根据权威服务器带着地区以及运行商信息,返回跟权威服务器带着地区以及运行商信息最相关的结果,作为最佳结果。
2.根据权利要求1所述的方法,其特征在于,步骤4)中,如果存在多级CNAME,权威服务器会内部迭代查询CNAME,查询CNAME的限制最大层级数为6级。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201910172536.4A CN109936632B (zh) | 2019-03-07 | 2019-03-07 | 一种应用于dns权威服务器的cname加速方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201910172536.4A CN109936632B (zh) | 2019-03-07 | 2019-03-07 | 一种应用于dns权威服务器的cname加速方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN109936632A CN109936632A (zh) | 2019-06-25 |
CN109936632B true CN109936632B (zh) | 2021-12-21 |
Family
ID=66986698
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201910172536.4A Active CN109936632B (zh) | 2019-03-07 | 2019-03-07 | 一种应用于dns权威服务器的cname加速方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN109936632B (zh) |
Families Citing this family (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111010462A (zh) * | 2019-12-30 | 2020-04-14 | 互联网域名系统北京市工程研究中心有限公司 | 基于TRANS记录的IPv6域名解析方法 |
CN112291339B (zh) * | 2020-10-28 | 2022-09-23 | 平安科技(深圳)有限公司 | 基于云解析的全局负载均衡方法及系统 |
CN112671866B (zh) * | 2020-12-15 | 2022-11-25 | 牙木科技股份有限公司 | Dns分流解析方法、dns服务器及计算机可读存储介质 |
CN112995357B (zh) * | 2021-04-21 | 2021-07-23 | 腾讯科技(深圳)有限公司 | 基于云托管服务的域名管理方法、装置、介质及电子设备 |
CN114422476B (zh) * | 2021-12-28 | 2023-09-22 | 互联网域名系统北京市工程研究中心有限公司 | 防止cname缓存污染的方法及装置 |
CN116095172B (zh) * | 2023-01-09 | 2024-08-02 | 域铭科技(成都)有限公司 | 缓存刷新方法、装置、设备和存储介质 |
Citations (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2009087620A2 (en) * | 2008-01-07 | 2009-07-16 | Neocleus Israel Ltd. | Data distribution using dns |
CN103037028A (zh) * | 2012-12-10 | 2013-04-10 | 中国科学院计算机网络信息中心 | 一种支持变体域名dns解析实现的方法及系统 |
CN105516391A (zh) * | 2015-12-25 | 2016-04-20 | 互联网域名系统北京市工程研究中心有限公司 | 一种基于cname的dns域名解析方法 |
CN105681491A (zh) * | 2016-04-08 | 2016-06-15 | 网宿科技股份有限公司 | 一种域名解析加速方法、系统和装置 |
CN106301966A (zh) * | 2016-10-25 | 2017-01-04 | 北京云端智度科技有限公司 | 一种基于域名的按比例分配流量的方法 |
CN106453692A (zh) * | 2016-11-28 | 2017-02-22 | 腾讯科技(深圳)有限公司 | 一种域名解析方法、装置和系统 |
CN106657432A (zh) * | 2016-11-17 | 2017-05-10 | 中国移动通信集团江苏有限公司 | 域名解析方法及装置 |
CN108243266A (zh) * | 2016-12-27 | 2018-07-03 | 阿里巴巴集团控股有限公司 | 别名记录处理方法、配置方法及装置 |
CN108900648A (zh) * | 2018-06-13 | 2018-11-27 | 网宿科技股份有限公司 | 一种控制多cname流量比例的方法和装置 |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9031996B2 (en) * | 2010-03-15 | 2015-05-12 | Salesforce.Com | System, method and computer program product for creating a plurality of CNAMES for a website |
-
2019
- 2019-03-07 CN CN201910172536.4A patent/CN109936632B/zh active Active
Patent Citations (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2009087620A2 (en) * | 2008-01-07 | 2009-07-16 | Neocleus Israel Ltd. | Data distribution using dns |
CN103037028A (zh) * | 2012-12-10 | 2013-04-10 | 中国科学院计算机网络信息中心 | 一种支持变体域名dns解析实现的方法及系统 |
CN105516391A (zh) * | 2015-12-25 | 2016-04-20 | 互联网域名系统北京市工程研究中心有限公司 | 一种基于cname的dns域名解析方法 |
CN105681491A (zh) * | 2016-04-08 | 2016-06-15 | 网宿科技股份有限公司 | 一种域名解析加速方法、系统和装置 |
CN106301966A (zh) * | 2016-10-25 | 2017-01-04 | 北京云端智度科技有限公司 | 一种基于域名的按比例分配流量的方法 |
CN106657432A (zh) * | 2016-11-17 | 2017-05-10 | 中国移动通信集团江苏有限公司 | 域名解析方法及装置 |
CN106453692A (zh) * | 2016-11-28 | 2017-02-22 | 腾讯科技(深圳)有限公司 | 一种域名解析方法、装置和系统 |
CN108243266A (zh) * | 2016-12-27 | 2018-07-03 | 阿里巴巴集团控股有限公司 | 别名记录处理方法、配置方法及装置 |
CN108900648A (zh) * | 2018-06-13 | 2018-11-27 | 网宿科技股份有限公司 | 一种控制多cname流量比例的方法和装置 |
Also Published As
Publication number | Publication date |
---|---|
CN109936632A (zh) | 2019-06-25 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN109936632B (zh) | 一种应用于dns权威服务器的cname加速方法 | |
CN111245972B (zh) | 一种域名解析方法、装置、介质及设备 | |
US20190081922A1 (en) | Method and system for increasing speed of domain name system resolution within a computing device | |
US20130227141A1 (en) | Method for accessing content in networks and a corresponding system | |
US20230216884A1 (en) | Method for minimizing the risk and exposure duration of improper or hijacked dns records | |
US20170163482A1 (en) | Method of Provisioning Network Elements | |
US7499998B2 (en) | Arrangement in a server for providing dynamic domain name system services for each received request | |
US20060265516A1 (en) | Generic top-level domain re-routing system | |
CN109819068B (zh) | 用户终端及其区块链域名解析方法、计算机设备、计算机可读存储介质 | |
WO2012152765A1 (en) | A method for dns resolution of content requests in a cdn service | |
CN112468309B (zh) | 基于智能合约的域名管理系统 | |
EP2311228A2 (en) | Methods, systems, and computer readable media for throttling traffic to an internet protocol (ip) network server using alias hostname identifiers assigned to the ip network server with a domain name system (dns) | |
CN104468853A (zh) | 一种域名解析方法、服务器及系统 | |
CN110933156A (zh) | 一种域名解析的方法及装置 | |
CN105282269A (zh) | 一种本地dns根服务器的配置方法和服务方法 | |
CN107896257A (zh) | 部署客户端子系统功能的方法、装置、设备和介质 | |
CN112738288A (zh) | Dns域名解析方法、dns服务器、gslb系统及域名解析系统 | |
CN116170403B (zh) | 基于Handle系统的去中心化域名解析方法及装置 | |
CN111371914A (zh) | Ip库生成方法、域名解析方法、电子设备和可读存储介质 | |
CN111711706B (zh) | Dns递归请求方法及系统 | |
CN107222588A (zh) | 一种提高dns可用性的方法及系统 | |
CN111698341A (zh) | Dns权威响应方法及系统 | |
EP2019535A1 (en) | Requester-aware domain name system | |
US10536429B2 (en) | Conveying information in hostname in a content delivery network (CDN) | |
CN111447297B (zh) | IPv4、IPv6的DNS统一接入的管理方法及系统 |
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 |