CN111200642B - 权威dns服务器信息分发方法及系统 - Google Patents
权威dns服务器信息分发方法及系统 Download PDFInfo
- Publication number
- CN111200642B CN111200642B CN201911363001.1A CN201911363001A CN111200642B CN 111200642 B CN111200642 B CN 111200642B CN 201911363001 A CN201911363001 A CN 201911363001A CN 111200642 B CN111200642 B CN 111200642B
- Authority
- CN
- China
- Prior art keywords
- authoritative dns
- server
- dns server
- distribution mechanism
- information
- 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
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
-
- 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
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/12—Applying verification of the received information
- H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
- H04L67/1004—Server selection for load balancing
- H04L67/101—Server selection for load balancing based on network conditions
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
- H04L67/1036—Load balancing of requests to servers for services different from user content provisioning, e.g. load balancing across domain name servers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Telephonic Communication Services (AREA)
Abstract
本发明公开了一种权威DNS服务器信息分发方法及系统,与若干个权威DNS服务器组成一个共治组,其中所述方法包括如下步骤:分析接入的节点服务器,根据节点服务器的类型确定分发机制;将所述节点服务器信息及分发机制发送给共治组中对应的权威DNS服务器进行第一共识交互,以确定分发机制是否通过;在通过所述分发机制时在本地存储所述分发机制,并与所述共治组中其他权威DNS服务器同步所述分发机制。本发明可以减少DNS服务对中心化管理的依赖,提高整个DNS体系的安全性。
Description
技术领域
本发明涉及计算机网络通信技术领域,尤其涉及一种权威DNS服务器信息分发方法及系统。
背景技术
DNS(Domain Name System,域名系统)提供了互联网上的一个重要服务,其本质是建立了人的名字世界和底层的二进制协议地址世界的桥梁。它作为将域名和IP地址相互映射的一个分布式数据库,能够使人更方便地访问互联网,而不用去记住能够被机器直接读取的 IP地址数串,通过域名最终得到该域名对应的 IP 地址的过程叫做域名解析。
域名解析的过程具体以UDP(User Datagram Protocol,用户数据报协议)报文方式向本地域名服务器发起查询,如果本地域名服务器缓存有相应的查询结果,则直接返回包括对应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服务器,在接收到所述递归DNS服务器的域名解析请求超过第三阈值时,触发分析接入的节点服务器。
作为本发明上述权威DNS服务器信息分发方法的进一步改进,向所述节点服务器进行信息分发时,分发的信息为包括哈希值的区块数据结构,以使所述节点服务器通过所述哈希值验证信息的完整性。
为了解决上述技术问题,本发明的一种权威DNS服务器信息分发系统,与若干个权威DNS服务器组成一个共治组,所述系统具体包括:
分析单元,用于分析接入的节点服务器,根据节点服务器的类型确定分发机制;
共识单元,用于将所述节点服务器信息及分发机制发送给共治组中对应的权威DNS服务器进行第一共识交互,以确定分发机制是否通过;
执行单元,用于在通过所述分发机制时在本地存储所述分发机制,并与所述共治组中其他权威DNS服务器同步所述分发机制。
作为本发明上述权威DNS服务器信息分发系统的进一步改进,在所述共识单元中,所述第一共识交互包括向共治组中对应的权威DNS服务器发起包括是否同意信息分发的投票,在对应的权威DNS服务器反馈同意数量超过第一阈值时,确定通过所述分发机制。
作为本发明上述权威DNS服务器信息分发系统的进一步改进,在所述共识单元中,所述第一共识交互包括向共治组中对应的权威DNS服务器发起包括是否同意分发机制内容的投票,在对应的权威DNS服务器反馈同意数量超过第二阈值时,确定通过所述分发机制;
在对应的权威DNS服务器反馈同意数量低于第二阈值时,由共治组中服务质量最好的权威DNS服务器重新发起共识交互。
与现有技术相比,本发明通过在同一共治组中分布式设置多个权威DNS服务器,权威DNS服务器之间存储有统一的供外部节点服务器使用的信息资源,对节点服务器的需求进行分析并根据共识规则在共治组中进行信息分发的共同决策,以实现整个DNS体系的运作。本发明可以减少DNS服务对中心化管理的依赖,提高整个DNS体系的安全性。
结合附图阅读本发明实施方式的详细描述后,本发明的其他特点和优点将变得更加清楚。
附图说明
为了更清楚地说明本发明实施方式或现有技术的技术方案,下面将对实施方式或现有技术描述中所需要使用的附图作简单地介绍,显而易见,下面描述中的附图仅仅是本发明中记载的一些实施方式,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1为现有技术中DNS解析示意图。
图2为本发明一实施方式中权威DNS服务器信息分发方法流程图。
图3为本发明一实施方式中权威DNS服务器布局架构示意图。
图4为本发明一实施方式中权威DNS服务器信息分发系统示意图。
图5为本发明一实施方式中权威DNS服务器信息分发分层示意图。
图6为本发明一实施方式中权威DNS服务器信息分发模块示意图。
具体实施方式
以下将结合附图所示的各实施方式对本发明进行详细描述。但这些实施方式并不限定本发明,本领域的普通技术人员根据这些实施方式所做出的结构、方法或功能上的变化均包含在本发明的保护范围内。
需要说明的是,在不同的实施方式中,可能使用相同的标号或标记,但这些并不代表结构或功能上的绝对联系关系。并且,各实施方式中所提到的“第一”、“第二”也并不代表结构或功能上的绝对区分关系,这些仅仅是为了描述的方便。
对于权威DNS服务器而言,它们是实际持有并负责DNS资源记录的DNS服务器。这是DNS查找链上最源头的服务器,它将使用查询的资源记录进行响应,最终一般通过递归DNS服务器反馈给请求方以获得访问网站或其他Web资源所需的IP地址等。如图1所示,权威DNS服务器包括根域名服务器、顶级域名服务器及二级域名服务器,在更多的实施方式中,还可以在二级域名服务器下存在更多层次的域名服务器。通过根域名服务器可以查询到实现相应解析的顶级域名服务器,依此类推,通过顶级域名服务器可以查询到实现相应解析的二级域名服务器,根域名服务器、顶级域名服务器及二级域名服务器之间形成上下的层级架构以实现递归查询。在本实施方式中,以客户端发起域名www.example.com的网站为例,客户端会向本地域名服务器发送解析请求,如果本地域名服务器存在相应的解析结果,则直接反馈结果。如果本地域名服务器不存在相应的解析结果,则需要作为递归DNS服务器向权威DNS服务器进行递归查询,具体可以通过本地域名服务器中的递归模块先从根域名服务器开始查询.com的顶级域名服务器,获得后再向.com的顶级域名服务器查询域example.com的二级域名服务器,依此类推,可以通过域example.com的二级域名服务器查找到www.example.com相应的解析结果。在图1中,客户端发起的是A记录查询,即最终获得的是访问对应网站服务器的IPv4地址。
如上所述,通过根域名服务器可以查询到实现相应解析的顶级域名服务器,通过顶级域名服务器可以查询到实现相应解析的二级域名服务器,因此,对于根域名服务器、顶级域名服务器、二级域名服务器等权威DNS服务器而言,为外部的节点服务器提供特定的查找资源是其最主要的作用,比如上述的递归DNS服务器,通过权威DNS服务器实现相应的域名解析。另外,镜像DNS服务器也是权威DNS服务器以外的一种特定类型节点服务器,通过与相应权威DNS服务器同步数据,从而为递归DNS服务器提供同样的资源查找功能。因此,相对于外部的节点服务器,权威DNS服务器承担着信息分发的功能,为外部的节点服务器提供相应的信息资源。但是,现有技术中涉及权威DNS服务器的信息分发大多采用中心化的治理思路,存在着设计僵化,不够灵活等技术缺陷,本发明则采用去中心化的思路进行实现,提高了信息分发的灵活性,一定程度上保证了安全,以下将详述。
如图2所示,本发明一实施方式中权威DNS服务器信息分发方法流程图。权威DNS服务器信息分发方法,具体包括如下步骤:
步骤S1、分析接入的节点服务器,根据节点服务器的类型确定分发机制。如图3所示,由若干个权威DNS服务器10组成的共治组,共治组中的权威DNS服务器之间彼此通信实现交互,从而实现共同治理的目的。具体地,共治组中任意一台权威DNS服务器可以通过类似广播的方式向共治组内的其他权威DNS服务器发送信息,亦或者对特定节点的权威DNS服务器进行通信,以实现相互之间的交互,优选地,权威DNS服务器之间通过专线进行连接。共治组中的权威DNS服务器可以应用在递归架构的不同层次,在本实施方式中,共治组中的权威DNS服务器10可以作为根域名服务器,查询到下层顶级域名服务器的NS记录等,具体包括cn、us、de等国家顶级域及com、net等通用顶级域信息,因此,共治组中的权威DNS服务器10与指向顶级域解析的权威DNS服务器20形成上下两层的递归查询架构。对于权威DNS服务器以外,还存在两种类型的节点服务器,分别是镜像DNS服务器31及递归DNS服务器32,递归DNS服务器32如上所述可以利用递归架构中的权威DNS服务器最终查询到对应域名的访问IP地址等。而镜像DNS服务器31则是同步了共治组中权威DNS服务器10中的资源记录等,进一步,递归DNS服务器32也可以实现从镜像DNS服务器31开始实现递归查询。
由于上述的镜像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服务器经过分析,可以直接采用请求的信息分发时间周期。
步骤S2、将所述节点服务器信息及分发机制发送给共治组中对应的权威DNS服务器进行第一共识交互,以确定分发机制是否通过。通过步骤S1确定了相应的分发机制后,会向共治组中对应的权威DNS服务器进行第一共识交互,这里参与第一共识交互的权威DNS服务器具体是根据共治组中的共识规则来确定的。共识规则是对应共治组中各个权威DNS服务器共同遵守的用于生成和更新信息分发机制等的算法规则,是共治组中共同认可的,后期也可以在共同认可的前提下进行更新。共治组中对应的权威DNS服务器在接收到相应发送的节点服务器信息及分发机制后,可以通过自身规则对其进行判定,比如根据自身对共治组中的网络状况来判定对应的分发机制中负责信息分发的权威DNS服务器是否合理,或者镜像DNS服务器申请信息分发的数量是否达到共治组的限额,亦或者是否整个共治组应该分配权限给特定身份的节点服务器等。
相应地,在步骤S2中为了确定分发机制是否通过,向共治组中对应的权威DNS服务器发起投票,主要分为两种投票类型,一种是对特定节点服务器实施信息分发本身同意还是否决,另一种是对分发机制内容的安排是否同意还是否决,上述投票类型可以根据共识规则选择一个还是两个寻求对应权威DNS服务器的投票反馈,如果同时发起两种投票类型,则需要两者都通过才能确定通过分发机制。具体地,第一共识交互包括向共治组中对应的权威DNS服务器发起包括是否同意信息分发的投票,共治组中的权威DNS服务器可以根据分析来确定同意还是否决,在对应的权威DNS服务器反馈同意数量超过第一阈值时,确定通过分发机制。同理,在向共治组中对应的权威DNS服务器发起包括是否同意分发机制内容的投票时,只有在对应的权威DNS服务器反馈同意数量超过第二阈值时,才确定通过分发机制。上述的第一阈值和第二阈值都是根据共识规则设定的临界值,可以是通过的投票数量或者加权值,进一步还会设定一定的投票周期,只有在投票周期内反馈的投票才可以认定为有效投票,或者将超时未反馈的投票默认认定为同意票或否决票。对于第一种是否同意信息分发的投票,如果未通过就认定为针对特定节点服务器的信息分发接入请求未被共治组所认定,此时可以直接结束相应的过程。但是对于第二种是否同意分发机制内容的投票,还可以设定在对应的权威DNS服务器反馈同意数量低于第二阈值时,由共治组中服务质量最好的权威DNS服务器重新发起共识交互,因为初始的分发机制通常都是由最先接收请求的权威DNS服务器来确定的,如果该权威DNS服务器确定的分发机制不合理就很大可能会被共治组中的其他权威DNS服务器否决。服务质量最好的权威DNS服务器可以是通过共治组中权威DNS服务器之间的交互,确定的服务器资源好、网络环境优异的权威DNS服务器,该权威DNS服务器可以根据自身对网络的判定来重新确定分发机制,进一步可以根据共识规则直接将分发机制同步给其他权威DNS服务器,或者重新向共治组中对应的权威DNS服务器发起投票,如果通过则接收相应的分发机制,如果未通过,可以结束相应的信息分发处理过程。
步骤S3、在通过所述分发机制时在本地存储所述分发机制,并与所述共治组中其他权威DNS服务器同步所述分发机制。步骤S3是对通过分发机制后的实施过程,主要是对已经投票通过的分发机制存储在发起投票的自身权威DNS服务器中,可以在后续的执行过程中作为信息分发的依据,进一步还会与共治组中其他权威DNS服务器进行同步,作为其他需要执行的权威DNS服务器进行信息分发的依据。进一步,在通过分发机制时,还会向对应的节点服务器发送分发授权证书,授权证书可以通过接收接入请求的权威DNS服务器生成相应的公钥和私钥,利用私钥进行加密以保证不被篡改,通过公钥进行打开以可以查看相应的信息,相应的分发授权证书及公钥可以在共治组中的权威DNS服务器之间进行同步。分发授权证书中包括对应的节点服务器信息及信息分发的权限、分发机制等,优选地还可以包括证书的有效期,在证书过期时还需要重新发起上述的步骤。在具体的实施方式中,在分发授权证书的有效范围内,比如对应的镜像DNS服务器需要主动向对应的权威DNS服务器进行同步时,对应的权威DNS服务器通过查验对应分发授权证书的合法性来确定是否可以进行信息分发,无须再与其他权威DNS服务器发起共识交互,分发授权证书的查验也可以只在查询超量的时候才发起。
对于分发机制来说,可以根据需要设定很多的策略,比如镜像DNS服务器、递归DNS服务器只能与共治组中特定的权威DNS服务器实现具体的信息同步。在更多的实施方式中,如果分发机制针对镜像DNS服务器的信息分发包括由共治组定期主动向对应镜像DNS服务器同步时,相应的分发机制可以有动态分配的机制,具体在定期需要同步时,由共治组中的一个权威DNS服务器发起第二共识交互,可以是由通过的分发机制确定的,优选地,直接以确定分发机制的权威DNS服务器发起,此时通过实时确定当下与对应镜像DNS服务器链路环境最好的权威DNS服务器,将信息分发的任务移交给该权威DNS服务器,由它来实施与对应镜像DNS服务器的同步工作,这样可以保证信息分发的效率,动态地适应网络环境的波动变化。
在优选的实施方式中,向所述节点服务器进行信息分发时,分发的信息为包括哈希值的区块数据结构,以使所述节点服务器通过所述哈希值验证信息的完整性。具体地,在分发的信息中包括在分发前对区块数据进行哈希计算输出的哈希值。哈希计算是一种散列算法,特点具有单向性,逆向推导几乎不可能,因此不易篡改,另外细微不同的输入通过哈希计算都能得出几乎随机的不同输出。因此,当相应的节点服务器在接收到分发的信息后,可以对相应的区块数据做重新的哈希计算,并与收到的本身哈希值进行比较,如果一致则认定为信息完整,如果不一致则有可能被截取修改过。
在实施例1中,对于已有在共治组中注册申请的镜像DNS服务器,如果需要修改共治组中权威DNS服务器信息分发的周期,比如之前权威DNS服务器是一周与对应镜像DNS服务器同步一次,现在对应镜像DNS服务器申请设置一天同步一次,此时作为外部节点服务器的对应镜像DNS服务器可以重新向共治组中任意的权威DNS服务器发起权限申请。此时,共治组中对应的权威DNS服务器可以对接入的节点服务器进行分析,比如确定为合法的镜像DNS服务器,并综合对应镜像DNS服务器申请的权限修改请求,确定每24小时由共治组中与对应节点服务器链路环境最好的权威DNS服务器发起同步的分发机制,经过共治组的共识投票获得通过后,后续共治组中的权威DNS服务器就会根据新的分发机制执行相应的信息分发工作。
在实施例2中,对于确定定期向镜像DNS服务器同步更新信息的分发机制中,还可以进一步包括将对应的镜像DNS服务器加入到区块链的数据同步组中。当共治组中任意权威DNS服务器发生了信息更新,比如有新的DNS资源记录变化,可以通过区块链的数据同步与共治组中的其他权威DNS服务器进行同步,同时,也与加入数据同步组中的镜像DNS服务器进行同步,这样可以保证镜像DNS服务器获取信息的效率及稳定性。
在实施例3中,对于递归DNS服务器,当首次向共治组发起递归查询量超过限制时或者接收的分发授权证书失效后首次向共治组发起递归查询量超过限制时,共治组中接收递归查询的权威DNS服务器可以触发对节点服务器的分析,比如确定节点服务器为递归DNS服务器。进一步确定分发机制,比如对应节点服务器可以向共治组中权威DNS服务器单位查询量的最大值是多少,超量就拒绝查询。亦或者是对应节点服务器超量查询时必须优先查询共治组中特定的权威DNS服务器,如果非特定的权威DNS服务器接收到对应节点服务器的超量查询则拒绝查询。进一步还可以包括在共治组中设置限制条件的权威DNS服务器,超量查询的节点服务器只有在完成相应工作量证明的计算任务后才可以实现与限制条件的权威DNS服务器发起查询,具体地,限制条件的权威DNS服务器只有在接收查询前接收到对应节点服务器的工作量证明,才可以响应相应的查询。由于递归DNS服务器在查询前需要耗时完成一定量的计算任务,所以可以防止分布式拒绝服务攻击等,对于正常的递归DNS服务器,也起到了鼓励向服务质量好的权威DNS服务器发起查询的作用。确定好的分发机制在共治组内进行投票,参与投票的权威DNS服务器可以根据共治组中的网络环境等确定同意还是否决。如果通过,在接收到对应节点服务器的递归查询时,就会按照对应的分发机制执行分发还是拒绝。
如图4所示,本发明一实施方式中权威DNS服务器信息分发系统示意图。权威DNS服务器信息分发系统具体包括分析单元U1、共识单元U2及执行单元U3。相应地会设置一个共治组,共治组中包括若干个权威DNS服务器,共治组中的权威DNS服务器可以根据一定的加入和退出机制进行动态管理。共治组中的权威DNS服务器在统一的共识规则下进行决策,共识规则也可以在共治组中所有权威DNS服务器的同意下进行修改。在具体的实施方式中,共治组中的权威DNS服务器可以分别是不同国家管理的专用权威DNS服务器,亦或者与国家顶级域名服务器处于同一个服务器系统接收顶级域名服务器的更新请求,进一步还可以应用在下层的权威DNS服务器体系中。共治组中的权威DNS服务器通过分析单元U1、共识单元U2及执行单元U3实现DNS体系的去中心化管理。
分析单元U1,用于分析接入的节点服务器,根据节点服务器的类型确定分发机制。分析的触发是根据不同的接入情况发生,比如镜像DNS服务器是根据对应的接入申请,具体可以是新的镜像DNS服务器的加入,或者是已有镜像DNS服务器的权限修改。而递归DNS服务器则是在特定前提下的超量查询等。相应地,所述节点服务器为递归DNS服务器时,在接收到所述递归DNS服务器的域名解析请求超过第三阈值时,触发分析接入的节点服务器。分析接入的节点服务器,根据节点服务器的类型确定分发机制,如上所述,由于镜像DNS服务器、递归DNS服务器等获得信息的需求不一样,因此需要不同的分发机制来适应不同的应用场景,具体可以参照权威DNS服务器信息分发方法的相关内容。
共识单元U2,用于将所述节点服务器信息及分发机制发送给共治组中对应的权威DNS服务器进行第一共识交互,以确定分发机制是否通过。共识单元U2是在共治组内发起投票,最终在共治组内形成合理有效的分发机制供执行。具体地,所述第一共识交互包括向共治组中对应的权威DNS服务器发起包括是否同意信息分发的投票,在对应的权威DNS服务器反馈同意数量超过第一阈值时,确定通过所述分发机制。另外,所述第一共识交互还包括向共治组中对应的权威DNS服务器发起包括是否同意分发机制内容的投票,在对应的权威DNS服务器反馈同意数量超过第二阈值时,确定通过所述分发机制;在对应的权威DNS服务器反馈同意数量低于第二阈值时,由共治组中服务质量最好的权威DNS服务器重新发起共识交互。
执行单元U3,用于在通过所述分发机制时在本地存储所述分发机制,并与所述共治组中其他权威DNS服务器同步所述分发机制。执行单元U3在共识单元U2发起共识交互的基础上进行执行,如果最终没有通过任何一个分发机制,则拒绝相应的过程。如果通过了相应的分发机制,则会把分发机制同步给共治组中的权威DNS服务器,供后续的信息分发使用。为了减少共识交互的频度,根据需要可以在通过所述分发机制时,向所述节点服务器发送分发授权证书,以保证所述节点服务器在主动请求信息时验证权限,其作用是在有效的范围内复用特定共识交互的结果。
在更多的实施方式中,对于确定的节点服务器是镜像DNS服务器,确定的分发机制是定期向镜像DNS服务器同步更新信息时,由所述分发机制确定的权威DNS服务器发起第二共识交互,确定共治组中与所述镜像DNS服务器链路环境最好的权威DNS服务器,以实施分发,这样可以在变化的网络环境下保证更好的信息分发效果。优选地,设置判断离线超时的第四阈值,如果向对应节点服务器定期同步更新信息失败的次数超过第四阈值时,说明对应节点服务器存在问题,此时可以判定对应节点服务器离线。如果节点服务器恢复正常后重新需要同步信息时,可以重新发起接入申请。进一步,向所述节点服务器进行信息分发时,分发的信息为包括哈希值的区块数据结构,以使所述节点服务器通过所述哈希值验证信息的完整性。需要说明的是,权威DNS服务器信息分发系统的具体实施方式,还可以参照权威DNS服务器信息分发方法的具体实施方式。
如图5所示,为了适应应用过程中的实施和扩展,可以将整个权威DNS服务器信息分发系统自上而下分成三层结构,包括API(Application Programming Interface,应用程序接口)接口层、智能合约层、区块链处理层。API接口层为用户与智能合约层提供交互的接口,通过API接口层进行信息增删改查以及投票等操作,并提供相应的扩展;智能合约层是整个系统的核心,主要用于验证、存储、操作相关信息,用户可以通过API接口层与智能合约层进行交互,并在验证身份后完成相关操作。区块链处理层负责对接智能合约层以及存储相应数据,同时数据修改的每一次操作都将在区块链处理层上留下记录,确保数据修改的可追溯性,从而保证了系统数据的防篡改和一致性。
进一步,如图6所示,可以将整个系统分为区块链态和应用程序态,区块链态负责具体管理的实施,包括合约注册机及投票管理模块、共治组授权管理模块、DNS信息管理模块、DNS分发管理模块,合约注册机通过管理合约地址来调用投票管理模块、共治组授权管理模块、DNS信息管理模块、DNS分发管理模块。具体地,首先部署合约注册机,然后再部署投票管理模块、共治组授权管理模块、DNS信息管理模块、DNS分发管理模块,并将上述模块的合约地址写入到合约注册机中,以供后续合约间调用或应用程序态调用。应用程序态负责上层的操作交互,包括自主投票模块、共治组授权操作模块、DNS更新操作模块、DNS分发操作模块,应用程序态中的相应模块通过区块链态中合约注册机获得区块链态中相应模块的合约地址以实现调用。
在区块链态中,合约注册机支持接收新的合约注册,并保存相应模块的合约地址等合约数据,可以与应用程序态进行交互支持应用程序态的模块实施。合约注册机还链接着区块链态中的多个模块,共治组授权管理模块包括授权数据、授权修改等实施逻辑,可以在实施相关授权权限时调用。DNS信息管理模块包括DNS数据、DNS修改等实施逻辑,可以实现相应的信息更新。DNS分发管理模块包括DNS数据、分发权限修改等实施逻辑,可以实现按需进行信息分发。上述模块在操作过程中如果需要发起投票的,还可以通过调用投票管理模块,根据相应的投票共识逻辑实现共同决策。在本发明实施方式中,实现权威DNS服务器信息分发的管理,可以借助区块链态中的DNS分发管理模块、投票管理模块、合约注册机及应用程序态中的自主投票模块、DNS分发操作模块等来实施交互。
需要补充的是,在区块链态中,各个模块涉及的数据在不同的权威DNS服务器之间通过相应的机制是可以实现自动同步的,共治组中每个权威DNS服务器可以快速地了解到共治组中统一的最新状态及信息,比如分发机制的内容等。在上述的实施方式中,由于共治组中的权威DNS服务器之间需要相互通信,且需要在每个权威DNS服务器上同步信息,因此每次信息更新的记录可以通过加密签名保证信息数据的不可篡改,确保整个体系的安全性。同时,共治组中的权威DNS服务器采用哈希映射的数据存储,大大加快了数据的查询速度,缩短等待时间,进一步,如上所述的分发机制等是存储在块链式数据结构的特定区块中。
结合本申请所公开的技术方案,可以直接体现为硬件、由控制单元执行的软件模块或二者组合,即一个或多个步骤和/或一个或多个步骤组合,既可以对应于计算机程序流程的各个软件模块,亦可以对应于各个硬件模块,例如ASIC(Application SpecificIntegrated Circuit,专用集成电路)、FPGA(Field-Programmable Gate Array,现场可编程门阵列)或其他可编程逻辑器件、分立门或晶体逻辑器件、分立硬件组件或者其任意适当组合。为了描述的方便,描述上述装置时以功能分为各种模块分别描述,当然,在实施本申请时可以把各模块的功能在同一个或多个软件和/或硬件中实现。
通过以上实施方式的描述可知,本领域的技术人员可以清楚地了解到本申请也可以借助软件加必需的通用硬件平台的方式来实现。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分也可以以软件产品的形式体现出来。该软件可以由微控制单元执行,依赖于所需要的配置,也可以包括任何类型的一个或多个微控制单元,包括但不限于微控制器、DSP(Digital Signal Processor,数字信号控制单元)或其任意组合。该软件存储在存储器,例如,易失性存储器(例如随机读取存储器等)、非易失性存储器(例如只读存储器、闪存等)或其任意组合。
综上所述,本发明通过在同一共治组中分布式设置多个权威DNS服务器,权威DNS服务器之间存储有统一的供外部节点服务器使用的信息资源,对节点服务器的需求进行分析并根据共识规则在共治组中进行信息分发的共同决策,以实现整个DNS体系的运作。本发明可以减少DNS服务对中心化管理的依赖,提高整个DNS体系的安全性。
应当理解,虽然本说明书按照实施方式加以描述,但并非每个实施方式仅包含一个独立的技术方案,说明书的这种叙述方式仅仅是为了清楚起见,本领域技术人员应当将说明书作为一个整体,各实施方式中的技术方案也可以经适当组合,形成本领域技术人员可以理解的其他实施方式。
上文所列出的一系列的详细说明仅仅是针对本发明的可行性实施方式的具体说明,它们并非用以限制本发明的保护范围,凡未脱离本发明技艺精神所作的等效实施方式或变更均应包含在本发明的保护范围之内。
Claims (9)
1.一种权威DNS服务器信息分发方法,其特征在于,与若干个权威DNS服务器组成一个共治组,所述方法具体包括如下步骤:
分析接入的节点服务器,根据节点服务器的类型确定分发机制;
将所述节点服务器信息及分发机制发送给共治组中对应的权威DNS服务器进行第一共识交互,以确定分发机制是否通过;
在通过的分发机制为定期向镜像DNS服务器同步更新信息时,由所述分发机制确定的权威DNS服务器发起第二共识交互,确定共治组中与所述镜像DNS服务器链路环境最好的权威DNS服务器,以实施分发;
在通过所述分发机制时在本地存储所述分发机制,并与所述共治组中其他权威DNS服务器同步所述分发机制。
2.根据权利要求1所述的权威DNS服务器信息分发方法,其特征在于,所述第一共识交互包括向共治组中对应的权威DNS服务器发起包括是否同意信息分发的投票,在对应的权威DNS服务器反馈同意数量超过第一阈值时,确定通过所述分发机制。
3.根据权利要求1所述的权威DNS服务器信息分发方法,其特征在于,所述第一共识交互包括向共治组中对应的权威DNS服务器发起包括是否同意分发机制内容的投票,在对应的权威DNS服务器反馈同意数量超过第二阈值时,确定通过所述分发机制;
在对应的权威DNS服务器反馈同意数量低于第二阈值时,由共治组中服务质量最好的权威DNS服务器重新发起共识交互。
4.根据权利要求1所述的权威DNS服务器信息分发方法,其特征在于,在通过所述分发机制时,向所述节点服务器发送分发授权证书,以保证所述节点服务器在主动请求信息时验证权限。
5.根据权利要求1所述的权威DNS服务器信息分发方法,其特征在于,所述节点服务器为递归DNS服务器,在接收到所述递归DNS服务器的域名解析请求超过第三阈值时,触发分析接入的节点服务器。
6.根据权利要求1所述的权威DNS服务器信息分发方法,其特征在于,向所述节点服务器进行信息分发时,分发的信息为包括哈希值的区块数据结构,以使所述节点服务器通过所述哈希值验证信息的完整性。
7.一种权威DNS服务器信息分发系统,其特征在于,与若干个权威DNS服务器组成一个共治组,所述系统具体包括:
分析单元,用于分析接入的节点服务器,根据节点服务器的类型确定分发机制;
共识单元,用于将所述节点服务器信息及分发机制发送给共治组中对应的权威DNS服务器进行第一共识交互,以确定分发机制是否通过;在通过的分发机制为定期向镜像DNS服务器同步更新信息时,由所述分发机制确定的权威DNS服务器发起第二共识交互,确定共治组中与所述镜像DNS服务器链路环境最好的权威DNS服务器,以实施分发;
执行单元,用于在通过所述分发机制时在本地存储所述分发机制,并与所述共治组中其他权威DNS服务器同步所述分发机制。
8.根据权利要求7所述的权威DNS服务器信息分发系统,其特征在于,在所述共识单元中,所述第一共识交互包括向共治组中对应的权威DNS服务器发起包括是否同意信息分发的投票,在对应的权威DNS服务器反馈同意数量超过第一阈值时,确定通过所述分发机制。
9.根据权利要求7所述的权威DNS服务器信息分发系统,其特征在于,在所述共识单元中,所述第一共识交互包括向共治组中对应的权威DNS服务器发起包括是否同意分发机制内容的投票,在对应的权威DNS服务器反馈同意数量超过第二阈值时,确定通过所述分发机制;
在对应的权威DNS服务器反馈同意数量低于第二阈值时,由共治组中服务质量最好的权威DNS服务器重新发起共识交互。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201911363001.1A CN111200642B (zh) | 2019-12-26 | 2019-12-26 | 权威dns服务器信息分发方法及系统 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201911363001.1A CN111200642B (zh) | 2019-12-26 | 2019-12-26 | 权威dns服务器信息分发方法及系统 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN111200642A CN111200642A (zh) | 2020-05-26 |
CN111200642B true CN111200642B (zh) | 2022-08-23 |
Family
ID=70746553
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201911363001.1A Active CN111200642B (zh) | 2019-12-26 | 2019-12-26 | 权威dns服务器信息分发方法及系统 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN111200642B (zh) |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN113194159B (zh) * | 2021-04-19 | 2023-05-02 | 广州根链国际网络研究院有限公司 | Dns权威数据管理方法及系统 |
CN113472855A (zh) * | 2021-06-07 | 2021-10-01 | 广州根链国际网络研究院有限公司 | Dns权威服务器分布式共识方法及系统 |
CN115378908B (zh) * | 2022-08-22 | 2024-06-25 | 哈尔滨工业大学 | 一种基于ndn的dns标识解析方法及系统 |
CN115460169A (zh) * | 2022-09-06 | 2022-12-09 | 中国电子信息产业集团有限公司第六研究所 | 域名解析方法、系统、电子设备及计算机可读存储介质 |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN108366138A (zh) * | 2018-05-28 | 2018-08-03 | 北京奇虎科技有限公司 | 域名操作方法、系统及电子设备 |
CN109327562A (zh) * | 2018-12-10 | 2019-02-12 | 中共中央办公厅电子科技学院 | 一种基于区块链的域名存储系统及方法 |
CN109756589A (zh) * | 2019-02-20 | 2019-05-14 | 中国互联网络信息中心 | 一种基于区块链多方共治的域名信息维护系统 |
CN110061838A (zh) * | 2019-04-28 | 2019-07-26 | 广州大学 | 一种dns资源记录的去中心化存储系统及其实现、信息检索方法 |
CN110474994A (zh) * | 2018-05-10 | 2019-11-19 | 中国移动通信集团有限公司 | 域名解析方法、装置、电子设备和存储介质 |
CN110537346A (zh) * | 2017-03-06 | 2019-12-03 | 诺基亚技术有限公司 | 安全去中心化域名系统 |
Family Cites Families (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8800011B2 (en) * | 2012-05-31 | 2014-08-05 | Rackspace Us, Inc. | Validating pointer records in a domain name system (DNS) service |
US11030860B2 (en) * | 2014-08-06 | 2021-06-08 | Lottery Now, Inc. | Systems for multiple legal game providers with digital ledger |
-
2019
- 2019-12-26 CN CN201911363001.1A patent/CN111200642B/zh active Active
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110537346A (zh) * | 2017-03-06 | 2019-12-03 | 诺基亚技术有限公司 | 安全去中心化域名系统 |
CN110474994A (zh) * | 2018-05-10 | 2019-11-19 | 中国移动通信集团有限公司 | 域名解析方法、装置、电子设备和存储介质 |
CN108366138A (zh) * | 2018-05-28 | 2018-08-03 | 北京奇虎科技有限公司 | 域名操作方法、系统及电子设备 |
CN109327562A (zh) * | 2018-12-10 | 2019-02-12 | 中共中央办公厅电子科技学院 | 一种基于区块链的域名存储系统及方法 |
CN109756589A (zh) * | 2019-02-20 | 2019-05-14 | 中国互联网络信息中心 | 一种基于区块链多方共治的域名信息维护系统 |
CN110061838A (zh) * | 2019-04-28 | 2019-07-26 | 广州大学 | 一种dns资源记录的去中心化存储系统及其实现、信息检索方法 |
Non-Patent Citations (2)
Title |
---|
"User-Friendly, Versatile, and Efficient Multi-link DNS Service Discovery";Daniel Kaiser et al;《 2016 IEEE 36th International Conference on Distributed Computing Systems Workshops (ICDCSW)》;20161124;全文 * |
庄天舒等." 基于区块链的DNS根域名解析体系".《电信科学》.2018, * |
Also Published As
Publication number | Publication date |
---|---|
CN111200642A (zh) | 2020-05-26 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN111200642B (zh) | 权威dns服务器信息分发方法及系统 | |
US9544278B2 (en) | Using domain name system security extensions in a mixed-mode environment | |
US20180287997A1 (en) | Systems and methods for managing top-level domain names using consortium blockchain | |
CN112425139B (zh) | 用于解析域名的设备和方法 | |
US20190166085A1 (en) | Blockchain-based domain name resolution system | |
CN112468309B (zh) | 基于智能合约的域名管理系统 | |
CN112468525B (zh) | 一种基于区块链的域名管理系统 | |
US12003606B2 (en) | Systems and methods for providing secure access to shared registration systems | |
CN101064717A (zh) | 信息系统或设备的安全防护系统及其工作方法 | |
JP2014182828A (ja) | レコード・セットへのdnssec対応ゾーンの事前署名のためのシステムおよび方法 | |
Angieri et al. | A distributed autonomous organization for internet address management | |
WO2022067888A1 (zh) | 一种基于共治链的域名解析方法及装置 | |
WO2023116028A1 (zh) | 区块链上的跨域访问方法及服务器 | |
US12081512B2 (en) | Collecting passive DNS traffic to generate a virtual authoritative DNS server | |
CN109842626A (zh) | 分配安全区域访问凭证的方法和装置 | |
Liu et al. | A comparative study of blockchain-based dns design | |
CN109951481B (zh) | 基于区块链网络相邻节点的信息处理方法和系统 | |
Zhang et al. | Blockchain‐Based DNS Root Zone Management Decentralization for Internet of Things | |
CN111343292B (zh) | 权威dns服务器信息更新方法及系统 | |
CN111193816A (zh) | 权威dns服务器信息更新方法及系统 | |
CN111464668A (zh) | 一种快速安全的域名解析方法 | |
CN111181950A (zh) | 权威dns服务器授权方法及系统 | |
Hu et al. | Blockzone: a decentralized and trustworthy data plane for DNS | |
Chanti et al. | Global Naming and Storage System Using Blockchain | |
Fu et al. | TI-DNS: A Trusted and Incentive DNS Resolution Architecture based on Blockchain |
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 |