CN104079683B - 一种授权域名服务器直接响应的域名解析方法及系统 - Google Patents
一种授权域名服务器直接响应的域名解析方法及系统 Download PDFInfo
- Publication number
- CN104079683B CN104079683B CN201410334670.7A CN201410334670A CN104079683B CN 104079683 B CN104079683 B CN 104079683B CN 201410334670 A CN201410334670 A CN 201410334670A CN 104079683 B CN104079683 B CN 104079683B
- Authority
- CN
- China
- Prior art keywords
- dns
- enhancing
- module
- domain name
- 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
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
一种授权域名服务器直接响应的域名解析方法,包括:应用模块发出DNS解析请求,所述DNS解析请求携带了域名;增强DNS请求模块接收所述应用模块发送的域名系统DNS解析请求,解析出所述DNS解析请求携带的域名,确定所述域名是否在白名单中;所述增强DNS请求模块向DNS服务器发送查询请求,并将所述DNS服务器返回的解析结果提交给所述应用模块。该方法可以保证DNS解析结果的准确性和可靠性。
Description
技术领域
本发明涉及一种授权域名服务器直接响应的域名解析方法及系统。
背景技术
在IP(Internet Protocol,互联网协议)网络中,域名系统(Domain Name System,DNS)是因特网最关键的基础服务之一,为众多网络应用提供根本性支撑,其主要功能是将易于人们记忆的域名(Domain Name)与网络可识别的IP地址作转换。域名和IP地址之间的转换称为域名解析,执行域名解析的网络主机可以称为DNS服务器。通过域名系统DNS服务器的查询服务,可以找到所需站点或资源的入口,进而对站点或资源进行访问。
现有技术中,DNS提供三种域名解析方式:本地查询、缓存查询和迭代查询。
如果用户通过某ISP(Internet Service Provider,互联网服务提供商)接入了互联网,那么这个ISP就会给该用户分配一个DNS服务器(这个DNS服务器不是权威服务器)。
如果该ISP(Internet Service Provider,互联网服务提供商)的接入用户在浏览器中输入某网站域名,则接入用户发起域名解析请求,其中携带该网站域名。
本地查询:该ISP的DNS服务器,一般称为本地DNS服务器接收到该域名解析请求,首先执行本地查询,在本地域名数据库中查询该网站域名对应的IP地址,本地域名数据库中存储了归属本DNS服务器解析的本地域名和IP地址的对应关系,如果该网站域名是本地域名,则本地DNS服务器直接将查询到的IP地址返回给接入用户;
缓存查询:如果该网站域名不是本地域名,本地DNS服务器接着执行缓存查询,在本DNS服务器的缓存中查询解析记录(缓存中一般以解析记录的形式保存最近一段时间内通过迭代查询方式解析过的非本地域名及其对应的IP地址),如果在缓存中有该网站域名相关的解析记录,则本地DNS服务器直接将查询到的IP地址返回给接入用户(该IP地址,会被标记为非权威服务器的应答)。
迭代查询:如果在缓存中没有该网站域名相关的解析记录,本地DNS服务器通过向根域名服务器提交迭代查询,获取该网站域名所属的域的权威域名服务器地址,本地DNS服务器向权威域名服务器查询该网站域名的IP地址;
由权威域名服务器返回该网站域名的IP映射关系给本地DNS服务器,本地DNS服务器将结果保存到本地缓存,并保持TTL时间,同时将结果应答给客户端。
例如,客户端发起访问请求www.163.com:
1.应用模块(例如,可以为应用程序,或硬件)调用操作系统的DNS查询程序(DNS查询程序可以查看本地hosts文件,发现没有www.163.com的IP映射关系)将请求发送给本地DNS服务器。
2.本地DNS服务器不包含163.com的权威域,不存在对应的www记录,因此将请求转发到根域名服务器(假如a.root-servers.net.)。
3.根域名服务器会返回负责.com域解析的权威服务器(假如a.gtld-servers.net)给本地DNS服务器,这一级首先会返回的是顶级域名的权威域名服务器。本地DNS服务器再向.com域的权威域名服务器(假如a.gtld-servers.net)发送查询报文。
4..com域的权威域名服务器将负责.163.com域的权威域名服务器地址(如ns1.nease.net)给本地DNS服务器,本地DNS服务器再将请求发送给负责.163.com域的权威域名服务器地址(如ns1.nease.net)。
5.由负责.163.com域的权威域名服务器返回www.163.com的IP映射关系给本地DNS服务器。
6.本地DNS服务器将结果保存到本地缓存,并保持TTL时间,同时将结果应答给客户端。
7.当其他客户端再次向本地DNS服务器查询www.163.com时,在TTL时间内,本地DNS服务器不再向根域名服务器转发请求,而是直接从缓存中读取数据应答给客户端.如果已经超过TTL时间,则本地DNS服务器会再次经历一次上述2-6的过程。
通过以上策略以及解析过程可以看出该流程至少有如下几个弊端。
一、域名的管理者并不能确保自己可以有效的将自己的DNS解析结果传递给用户。
原因一,由于全程是明文传递也有可能有恶意攻击者给缓存DNS发送伪造的权威DNS应答报文,导致缓存DNS缓存了错误的数据。针对这个缺陷,Internet工程任务组(IETF)公布了一个域名系统安全扩展(DNSSEC,Domain Name System Security Extensions),DNSSEC协议要求明文传输,密文校验。但是遗憾的DNSSEC的推行进度缓慢,因为这需要全球的缓存DNS支持这个协议并使用它,并且需要大量的顶级域的权威DNS,而这些设备的管理员又分属于不同的机构、公司。目前仅部署在.org域名和.gov(美国政府域名)以及部分国家和地区顶级域(ccTLD),如:.se(瑞典域名)。根服务(root-servers.net)已经完成DNSSEC签名。
原因二,缓存DNS的管理者可以在这个流程中修改权威DNS管理者传递的数据。
二、权威DNS的管理员不能清楚的知道最终用户的IP地址,这会影响权威DNS管理员不能将用户的请求精准的调度到最优的应用服务。其原因是用户的请求是发送给缓存DNS的,而给权威DNS发送请求的通常不是最终用户的IP地址,而是缓存DNS的IP地址。
发明内容
本发明的目的在于,提供一种授权域名服务器直接响应的域名解析方法及系统。
用于解决问题的方案
为了实现上述目的,本发明创造提供一种授权域名服务器直接响应的域名解析方法,包括:
应用模块发出DNS解析请求,所述DNS解析请求携带了域名;
增强DNS请求模块接收所述应用模块发送的域名系统DNS解析请求,解析出所述DNS解析请求携带的域名,确定所述域名是否在白名单中;
所述增强DNS请求模块向DNS服务器发送查询请求,并将所述DNS服务器返回的解析结果提交给所述应用模块。
优选地,域名解析方法,
若所述域名在所述增强DNS请求模块白名单中,则所述增强DNS请求模块向DNS服务器发送查询请求,并将所述DNS服务器返回的解析结果提交给所述应用模块,包括:
所述增强DNS请求模块向指定的DNS服务器的增强权威DNS模块发送解析请求,
所述增强权威DNS模块判断用户来源,给出解析结果,
所述增强权威DNS模块向所述增强DNS请求模块发送所述解析结果,
所述增强DNS请求模块校验所述解析结果,校验无误后将所述解析结果提交给所述应用模块。
优选地,若所述域名不在所述增强DNS请求模块白名单中,则所述增强DNS请求模块将解析请求发送给预设(例如,操作系统配置)的缓存DNS服务器。
优选地,域名解析方法,
若所述域名在所述增强DNS请求模块白名单中,则所述增强DNS请求模块向DNS服务器发送查询请求,并将所述DNS服务器返回的解析结果提交给所述应用模块,包括:
所述增强DNS请求模块将查询请求通过DNSSEC或私有DNS协议向指定的DNS服务器的增强权威DNS模块发送解析请求,
所述增强权威DNS模块判断用户来源,给出最优解析结果,
所述增强权威DNS模块通过DNSSEC或私有DNS协议向所述增强DNS请求模块发送所述最优解析结果,
所述增强DNS请求模块按照DNSSEC或者私有协议校验所述最优解析结果,校验无误后将所述最优解析结果提交给所述应用模块。
优选地,域名解析方法,
所述白名单,由所述增强DNS请求模块进行策略配置,所述策略配置包括增强权威DNS服务器地址、DNSSEC公钥信息、指定域名信息。
本发明还提供一种授权域名服务器直接响应的域名解析系统,包括:增强DNS请求模块,用于对应用模块发出DNS解析请求,解析出所述DNS解析请求携带的域名,确定所述域名是否在白名单中,所述DNS解析请求携带了域名;用于向DNS服务器发送查询请求,并将所述DNS服务器返回的解析结果提交给所述应用模块。
优选地,域名解析系统,还包括设置在DNS服务器的增强权威DNS模块;所述增强DNS请求模块,还用于向所述指定的DNS服务器的增强权威DNS模块发送解析请求,所述增强权威DNS模块,用于判断用户来源,给出解析结果,并向所述增强DNS请求模块发送所述解析结果,所述增强DNS请求模块,用于校验所述解析结果,校验无误后将所述解析结果提交给所述应用模块。
优选地,所述的授权域名服务器直接响应的域名解析系统,包括白名单配置器,用于对所述白名单进行策略配置,所述策略配置包括增强权威DNS服务器地址、DNSSEC公钥信息、指定域名信息。
本发明还提供一种授权域名服务器直接响应的域名解析系统,包括:
增强权威DNS模块,设置在权威DNS上,用于对下述的增强DNS请求模块发送的DNS解析请求进行应答;
增强DNS请求模块,设置客户端上,用于根据客户端应用模块的信号,与所述增强权威DNS模块进行DNS解析通信。
优选地,域名解析系统,所述增强DNS请求模块,用于接收客户端应用模块的DNS请求信号,向所述增强权威DNS模块发送DNS解析请求,
在接收增强权威DNS模块返回的DNS解析结果后,进行校验后将所述DNS解析结果返回所述客户端应用模块。
优选地,域名解析系统,所述增强权威DNS模块与所述增强DNS请求模块之间,通过DNSSEC协议和/或私有DNS协议进行通信。
有益效果
1、针对配置的域名可以绕开缓存DNS的解析步骤,直接请求增强权威DNS服务器,不受缓存DNS的制约,将运营商的约束降到最低,域名或者应用所有者掌控域名的DNS解析结果可以准确的传递到应用中。
2、增强DNS直接和应用模块(例如,可以为应用程序,或硬件)交互,可以准确的判断用户的网络地址,进行精确调度。
3、可以保证DNS解析结果的准确性和可靠性。
附图说明
图1为本发明一实施例的流程示意图;
图2为本发明另一实施例的流程示意图;
图3为本发明又一实施例的流程示意图;
图4为本发明一实施例的解析业务流程示意图;
图5为本发明另一实施例的解析业务流程示意图。
具体实施方式
下面对本发明创造实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅是本发明创造部分实施例,而不是全部的实施例。基于本发明创造中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本发明创造保护的范围。
如图1所示,一种授权域名服务器直接响应的域名解析方法,包括:
步骤S100,应用模块发出DNS解析请求,所述DNS解析请求携带了域名;
步骤S200,增强DNS请求模块接收所述应用模块发送的域名系统DNS解析请求,解析出所述DNS解析请求携带的域名,确定所述域名是否在白名单中;
步骤S300,所述增强DNS请求模块向DNS服务器发送查询请求,并将所述DNS服务器返回的解析结果提交给所述应用模块。
优选地,如图2所示,若所述域名在所述增强DNS请求模块白名单中,则所述增强DNS请求模块向DNS服务器发送查询请求,并将所述DNS服务器返回的解析结果提交给所述应用模块,包括:
步骤S210,所述增强DNS请求模块向指定的DNS服务器的增强权威DNS模块发送解析请求,
步骤S220,所述增强权威DNS模块判断用户来源,给出解析结果,
步骤S230,所述增强权威DNS模块向所述增强DNS请求模块发送所述解析结果,
步骤S240,所述增强DNS请求模块校验所述解析结果,校验无误后将所述解析结果提交给所述应用模块。
优选地,如图3所示,若所述域名在所述增强DNS请求模块白名单中,则所述增强DNS请求模块向DNS服务器发送查询请求,并将所述DNS服务器返回的解析结果提交给所述应用模块,包括:
步骤S211,所述增强DNS请求模块将查询请求通过DNSSEC或私有DNS协议向指定的DNS服务器的增强权威DNS模块发送解析请求,
步骤S221,所述增强权威DNS模块判断用户来源,给出最优解析结果,
步骤S231,所述增强权威DNS模块通过DNSSEC或私有DNS协议向所述增强DNS请求模块发送所述最优解析结果,
步骤S241,所述增强DNS请求模块按照DNSSEC或者私有协议校验所述最优解析结果,校验无误后将所述最优解析结果提交给所述应用模块。
若所述域名不在所述增强DNS请求模块白名单中,则所述增强DNS请求模块将解析请求发送给预设(例如,操作系统配置)的缓存DNS服务器。
优选地,所述白名单,由所述增强DNS请求模块进行策略配置,所述策略配置包括增强权威DNS服务器地址、DNSSEC公钥信息、指定域名信息。
将应用模块(例如,可以为应用程序,或硬件)所有者管理的域名的DNS请求直接发送给自己所管理的权威DNS,而不是缓存DNS,从而避开由于缓存DNS代理所产生的如上描述的弊端。
系统至少包含2个关键模块:
增强权威DNS模块:增强权威DNS模块可以是一个安装服务器上的权威DNS软件,也可以是一个专有硬件,其主要提供DNS的权威应答,与传统的权威DNS不同的是传统的权威DNS只支持复合DNS协议的请求,而增强DNS需要可以支持DNSSEC协议或者一种DNS私有传输协议。用于和增强DNS请求模块进行带校验的或者加密的DNS数据交互,确保在数据交互过程中不会被其它第三方的数据干扰,影响数据的准确性。
增强DNS请求模块,增强DNS请求模块可以是SDK或以其它的形式被嵌入到手机应用,也可以是软件库的形式被其它应用软件调用。其主要作用是发送DNS请求,和传统的操作系统的DNS请求模块的区别在于该模块需要根据要求对每一个调用他的应用模块(例如,可以为应用程序,或硬件)进行专门的配置。同时该模块可以用传统的DNS请求模块的方式去请求缓存DNS服务器,也可以根据配置按照DNSSEC或者私有的DNS协议和增强权威DNS模块进行数据交互。该模块包含一个配置文件,配置哪些域的DNS请求需要到指定的增强权威DNS模块去解析,并配置DNSSEC或私有协议或其它相关配置,不是指定域的DNS请求直接调用操作系统默认的缓存DNS进行解析。
也有可能有其它的辅助模块,比如私有协议的认证同步模块等等,该模块根据私有DNS传输协议的需要而设置。
权威DNS的管理方或者应用的开发方通过该方案能够有效的将自己配置的数据传递给最终用户的应用,同时可以看到最终用户的IP地址,进行精准的资源调度。但是前提是必须修改应用模块(例如,可以为应用程序,或硬件)使其调用增强DNS请求模块进行DNS解析。
业务的流程如下:
1、应用模块(例如,可以为应用程序,或硬件)调用增强DNS请求模块进行DNS解析;
2、增强DNS模块判断用户请求域名是否在规则名单中;
3、若域名在规则名单中:则将请求通过DNSSEC或私有DNS协议发送至指定的增强权威DNS模块进行解析;增强权威DNS判断用户来源,给出最优解析结果;并将最优的结果通过DNSSEC或私有协议传送给增强DNS请求模块。DNS请求模块按照DNSSEC或者私有协议的要求进行数据的校验,如果数据无误,将解析的结果提交给应用模块(例如,可以为应用程序,或硬件);
5、若域名不在规则名单中:增强DNS请求模块则将请求发送给操作系统设定的缓存DNS,增强DNS请求模块获得缓存DNS的应答后,将结果传递给应用模块(例如,可以为应用程序,或硬件)。
上述流程该流程至少有2个优点
优点一:针对配置的域名可以绕开缓存DNS的解析步骤,直接请求增强权威DNS服务器,不受缓存DNS的制约,将运营商的约束降到最低,域名或者应用所有者掌控域名的DNS解析结果可以准确的传递到应用中;
优点二:增强DNS直接和应用程序交互,可以准确的判断用户的网络地址,进行精确调度。
本发明创造的一个应用在手机模块或手机应用的示例可以如下:
1、编写增强DNS请求模块的SDK程序,由于实例的应用程序是基于手机开发的APP应用,所以需要编写一个可被手机应用嵌入的SDK,方便手机应用程序调用。
2、将编写好的SDK程序嵌入名为DEMO的APP应用。在嵌入时同时做好相应的配置,DEMO应用程序需要调用自己的关键业务域名,demo.com。同时DEMO APP也有可能需要解析一些外部自己不关心的域名。同时DEMO APP使用DNSSEC协议和DEMO的权威服务器进行安全通讯,基于以上2点,需要给SDK配置策略,让DEMO.COM域名去找指定的权威服务器解析,同时配置和指定的权威服务器采用DNSSEC进行数据传送,同时需要配上获取DEMO.COM的DESSEC协议的公钥的IP地址,该公钥由DEMO.COM的权威DNS服务器生成,所以该IP地址通常就是权威DNS服务器本身,本实例中DEMO.COM的权威DNS服务器为安装了前文提到的增强权威DNS模块的一台服务器。
3、部署权威DNS服务器,本实例中该服务器安装了增强权威DNS模块,按照实例的实际情况,需要配置相应的域名对应的IP地址,同时需要在设备上通过DNSSEC的算法生成配对的公钥和私钥,将私钥同步给DEMO APP。为考虑系统健壮性,通常需要使用主辅两台设备做冗余。
如上所述的解析业务流程有以下两种可能,流程一是需要解析的域名不是SDK关注的DEMO.COM域名,流程二是需要解析的域名是SDK关注的DEMO.COM域名。
流程一如图4所示,步骤如下:
1.DEMO APP调用一个SDK不关注的域名请求,如www.baidu.com,这时应用程序调用SDK;
2.SDK通过判断认为该域名需要直接请求操作系统设置的缓存DNS服务器,于是请求缓存DNS服务器;
3.缓存服务器如果没有该记录数据会去根据递归流程找到增强DNS服务器,增强DNS服务器通过标准的DNS协议应答缓存DNS服务器;
4.缓存DNS服务器将获得结果返回给SDK;
5.SDK收到应答包并传递给DEMO APP。
流程二如图5所示,步骤如下:
1.DEMO APP调用一个SDK关注的域名请求如WWW.DEMO.COM,这时应用程序调用SDK;
2.SDK通过判断认为该域名需要通过使用DENSEC协议请求指定的权威DNS服务器,于是请求增强权威DNS服务器;
3.增强权威DNS服务器通过私钥对需要应答的数据进行重组生产符合DNSSEC的DNS应答报文,并将该报文发给SDK;
4.SDK收到报文后用自己的公钥和报文进行比对,如果符合要求则传递给DEMOAPP,如果不符合要求则丢弃报文。
本发明还提供一种授权域名服务器直接响应的域名解析系统,包括:增强DNS请求模块,用于对应用模块发出DNS解析请求,解析出所述DNS解析请求携带的域名,确定所述域名是否在白名单中,所述DNS解析请求携带了域名;用于向DNS服务器发送查询请求,并将所述DNS服务器返回的解析结果提交给所述应用模块。
优选地,所述的授权域名服务器直接响应的域名解析系统,包括白名单配置器,用于对所述白名单进行策略配置,所述策略配置包括增强权威DNS服务器地址、DNSSEC公钥信息、指定域名信息。
本发明提出一种域名查询的实现方法和系统,能够有效的将自己配置的数据传递给最终用户的应用,同时可以看到最终用户的IP地址,进行精准的资源调度。
该方法通过一个特有的增强DNS请求模块,和应用模块(例如,可以为应用程序,或硬件)紧密结合,达到解析过程中绕开缓存DNS的目的,同时可以和自己管理的增强权威服务器进行私有的加密协议传输,确保数据的安全。由于绕开了缓存DNS,所以增强权威DNS可以直接判断增强DNS解析模块的IP地址,重而判断出用户终端的IP地址。
本发明可应用于不限于如下几个方面:
1.移动互联网APP开发商或运营商,通过本发明描述的方法进行设计DNS解析系统,达到提升DNS安全和调度精准的问题。
2.物流网应用的开发商或运营商,通过本发明描述的方法进行设计DNS解析系统,达到提升DNS安全和调度精准的问题。
3.CDN厂家通过本发明描述的方法进行设计DNS解析系统,达到提升DNS安全和调度精准的问题。
4.权威DNS服务商通过本发明描述的方法进行设计DNS解析系统,达到提升DNS安全性和调度精准的问题。
以上所述,仅为本发明创造的具体实施方式,但本发明创造的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本发明创造揭露的技术范围内,可轻易想到变化或替换,都应涵盖在本发明创造的保护范围之内。因此,本发明创造的保护范围应所述以权利要求的保护范围为准。
Claims (3)
1.一种授权域名服务器直接响应的域名解析方法,其特征在于,包括:
应用模块发出DNS解析请求,所述DNS解析请求携带了域名;
增强DNS请求模块接收所述应用模块发送的域名系统DNS解析请求,解析出所述DNS解析请求携带的域名,确定所述域名是否在增强DNS请求模块白名单中;
若所述域名在所述增强DNS请求模块白名单中,所述增强DNS请求模块向DNS服务器发送查询请求,并将所述DNS服务器返回的解析结果提交给所述应用模块;
若所述域名在所述增强DNS请求模块白名单中,则所述增强DNS请求模块向DNS服务器发送查询请求,并将所述DNS服务器返回的解析结果提交给所述应用模块,包括:
所述增强DNS请求模块向指定的DNS服务器的增强权威DNS模块发送解析请求,
所述增强权威DNS模块判断用户来源,给出解析结果,
所述增强权威DNS模块向所述增强DNS请求模块发送所述解析结果,
所述增强DNS请求模块校验所述解析结果,校验无误后将所述解析结果提交给所述应用模块;
所述白名单,由所述增强DNS请求模块进行策略配置,所述策略配置包括增强权威DNS服务器地址、DNSSEC公钥信息、指定域名信息。
2.根据权利要求1所述的授权域名服务器直接响应的域名解析方法,其特征在于,
若所述域名在所述增强DNS请求模块白名单中,则所述增强DNS请求模块向DNS服务器发送查询请求,并将所述DNS服务器返回的解析结果提交给所述应用模块,包括:
所述增强DNS请求模块将查询请求通过DNSSEC或私有DNS协议向指定的DNS服务器的增强权威DNS模块发送解析请求,
所述增强权威DNS模块判断用户来源,给出最优解析结果,
所述增强权威DNS模块通过DNSSEC或私有DNS协议向所述增强DNS请求模块发送所述最优解析结果,
所述增强DNS请求模块按照DNSSEC或者私有协议校验所述最优解析结果,校验无误后将所述最优解析结果提交给所述应用模块。
3.一种授权域名服务器直接响应的域名解析系统,其特征在于,包括:增强DNS请求模块,用于接收应用模块发出的DNS解析请求,解析出所述DNS解析请求携带的域名,确定所述域名是否在增强DNS请求模块白名单中,所述DNS解析请求携带了域名;
还包括设置在指定DNS服务器的增强权威DNS模块;
所述增强DNS请求模块,还用于向所述指定的DNS服务器的增强权威DNS模块发送解析请求;
所述增强权威DNS模块,用于判断用户来源,给出解析结果,并向所述增强DNS请求模块发送所述解析结果,
所述增强DNS请求模块,用于校验所述解析结果,校验无误后将所述解析结果提交给所述应用模块;
所述增强DNS请求模块还包括白名单配置器,用于对所述白名单进行策略配置,所述策略配置包括增强权威DNS服务器地址、DNSSEC公钥信息、指定域名信息。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201410334670.7A CN104079683B (zh) | 2014-07-14 | 2014-07-14 | 一种授权域名服务器直接响应的域名解析方法及系统 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201410334670.7A CN104079683B (zh) | 2014-07-14 | 2014-07-14 | 一种授权域名服务器直接响应的域名解析方法及系统 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN104079683A CN104079683A (zh) | 2014-10-01 |
CN104079683B true CN104079683B (zh) | 2019-01-15 |
Family
ID=51600723
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201410334670.7A Active CN104079683B (zh) | 2014-07-14 | 2014-07-14 | 一种授权域名服务器直接响应的域名解析方法及系统 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN104079683B (zh) |
Families Citing this family (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN106101300B (zh) * | 2016-06-22 | 2020-08-18 | 东方有线网络有限公司 | 通过私有域名系统控制访问自建服务器的方法 |
CN106534149A (zh) * | 2016-11-29 | 2017-03-22 | 北京小米移动软件有限公司 | Dns防劫持方法和装置、以及终端和服务器 |
CN106506729B (zh) * | 2017-01-11 | 2019-11-19 | 中国互联网络信息中心 | 一种基于dns视图的dns策略解析方法及装置 |
CN109246256A (zh) * | 2017-07-10 | 2019-01-18 | 中国电信股份有限公司 | 域名解析方法和系统、授信域名系统服务器 |
CN108471458A (zh) * | 2018-07-10 | 2018-08-31 | 北京云枢网络科技有限公司 | 权威dns服务提供方法及系统 |
CN111405083A (zh) * | 2020-03-25 | 2020-07-10 | 深信服科技股份有限公司 | 一种dns解析方法、装置、设备及可读存储介质 |
CN112953962A (zh) * | 2021-03-15 | 2021-06-11 | 杭州迪普科技股份有限公司 | 域名访问方法及装置 |
Family Cites Families (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101640679B (zh) * | 2009-04-13 | 2012-07-18 | 山石网科通信技术(北京)有限公司 | 域名解析代理方法和装置 |
CN102045413B (zh) * | 2011-01-24 | 2013-01-02 | 北京邮电大学 | 经过dht扩展的dns映射系统及其实现dns安全的方法 |
US20120254386A1 (en) * | 2011-04-01 | 2012-10-04 | Verisign, Inc. | Transfer of DNSSEC Domains |
CN102780791A (zh) * | 2012-07-18 | 2012-11-14 | 广东睿江科技有限公司 | 一种自适应ip的方法、装置以及系统 |
CN102970351B (zh) * | 2012-11-06 | 2017-11-17 | 中兴通讯股份有限公司 | 一种基于cdn和网络融合的用户定位的方法及装置 |
-
2014
- 2014-07-14 CN CN201410334670.7A patent/CN104079683B/zh active Active
Also Published As
Publication number | Publication date |
---|---|
CN104079683A (zh) | 2014-10-01 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN104079683B (zh) | 一种授权域名服务器直接响应的域名解析方法及系统 | |
US10374955B2 (en) | Managing network computing components utilizing request routing | |
US9800539B2 (en) | Request routing management based on network components | |
US9264435B2 (en) | Apparatus and methods for access solutions to wireless and wired networks | |
CN103716326B (zh) | 一种资源访问方法及用户资源网关 | |
CN103299594B (zh) | 用于可扩展的认证框架的系统和方法 | |
CN102292961B (zh) | 用于对由域名服务(dns)获得的ip地址进行转换的系统和方法 | |
CN102577302B (zh) | 用于在具有流量管理的连接中使用端点审计的系统和方法 | |
CN102769529B (zh) | Dnssec签名服务器 | |
CN102301677B (zh) | 用于全局服务器负载平衡站点持续的系统和方法 | |
US9037711B2 (en) | Policy directed security-centric model driven architecture to secure client and cloud hosted web service enabled processes | |
US20150195244A1 (en) | Request routing management based on network components | |
CN108270882A (zh) | 域名的解析方法和装置、存储介质、电子装置 | |
CN103119907A (zh) | 提供用于访问控制的智能组的系统和方法 | |
CN101582856B (zh) | 一种门户服务器与宽带接入设备的会话建立方法及其系统 | |
CN103314566A (zh) | 用于管理域名系统安全(dnssec)的系统和方法 | |
CN103503424A (zh) | 用于实现多核系统中的连接镜像的系统和方法 | |
CN104333567A (zh) | 采用安全即服务的web缓存 | |
CN102171984A (zh) | 服务提供者访问 | |
CN104168339A (zh) | 防止域名劫持的方法及设备 | |
CN104751030A (zh) | 一种用户访问权限控制方法及装置 | |
US11949650B2 (en) | System and method for improving network performance when using secure DNS access schemes | |
CN103997479B (zh) | 一种非对称服务ip代理方法和设备 | |
CN103179099A (zh) | 一种接入开放网站平台的统一认证方法和一种网站平台 | |
KR20210089113A (ko) | 사설 네트워크 간의 통신을 위한 방법, 장치, 전자 기기 및 저장 매체 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
TA01 | Transfer of patent application right |
Effective date of registration: 20181121 Address after: 511500 Tian'an Zhigu Exhibition Service Center 159, No. 18 Chuangxing Avenue, Science and Technology Innovation Park, Qingcheng High-tech Industrial Development Zone, Qingyuan City, Guangdong Province Applicant after: Qingyuan starter Intelligent Technology Co., Ltd. Address before: 100080 Beijing Haidian District Suzhou Street 55, 3 tier 01-A340 Applicant before: Beijing Kuai Yibo Science and Technology Ltd. |
|
TA01 | Transfer of patent application right | ||
GR01 | Patent grant | ||
GR01 | Patent grant |