CN111343292B - 权威dns服务器信息更新方法及系统 - Google Patents
权威dns服务器信息更新方法及系统 Download PDFInfo
- Publication number
- CN111343292B CN111343292B CN202010084237.8A CN202010084237A CN111343292B CN 111343292 B CN111343292 B CN 111343292B CN 202010084237 A CN202010084237 A CN 202010084237A CN 111343292 B CN111343292 B CN 111343292B
- Authority
- CN
- China
- Prior art keywords
- information
- authoritative dns
- record
- authorization
- node
- 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
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
-
- 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
-
- 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/3247—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 involving digital signatures
-
- 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/3263—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 involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
-
- 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/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computer Security & Cryptography (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明公开了一种权威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体系的安全性。
结合附图阅读本发明实施方式的详细描述后,本发明的其他特点和优点将变得更加清楚。
附图说明
为了更清楚地说明本发明实施方式或现有技术的技术方案,下面将对实施方式或现有技术描述中所需要使用的附图作简单地介绍,显而易见,下面描述中的附图仅仅是本发明中记载的一些实施方式,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1为现有技术中DNS解析示意图。
图2为本发明一实施方式中权威DNS服务器信息更新方法流程图。
图3为本发明一实施方式中权威DNS服务器布局架构示意图。
图4为本发明一实施方式中同一对象信息更新记录关系示意图。
图5为本发明一实施方式中同一对象信息更新记录关系示意图。
图6为本发明一实施方式中区块结构示意图。
图7为本发明一实施方式中权威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地址。
如上所述,通过根域名服务器可以查询到实现相应解析的顶级域名服务器,通过顶级域名服务器可以查询到实现相应解析的二级域名服务器,然而上述根域名服务器、顶级域名服务器等供查询的信息是需要维护的。在现有技术中,以根域名服务器为例,根区管理属于IANA(Internet Assigned Numbers Authority,互联网数字分配机构)的职能,ICANN(Internet Corporation for Authorited Names and Numbers,互联网名称和数字地址分配机构)具体负责根区更新的最终审批,而PTI(Public Technical Identifiers,公共技术标识符机构,ICANN附属机构)作为根区运营者,负责处理来自顶级域运营者的根区更新申请,威瑞信公司(VeriSign)作为根区维护者,负责根区数据的更新与发布。因此,上层域名服务器对下层域名服务器的管理基本是采用中心化的管理模式,本发明则对现有中心化的DNS服务器管理进行改进,通过设置分布式的多个对等节点进行共同决策,以实现整个DNS体系的运作,以下将详述。
如图2所示,本发明一实施方式中权威DNS服务器信息更新方法流程图。权威DNS服务器信息更新方法,具体包括如下步骤:
步骤S1、接收第一信息更新记录,所述第一信息更新记录包括对第一对象进行信息更新的第一内容及第一授权信息。如图3所示,作为权威DNS服务器组成的递归查询架构,至少包括第一层权威DNS服务器10及第二层权威DNS服务器20,供递归DNS服务器递归查询。在第一层权威DNS服务器10中可以查找到访问第二层权威DNS服务器20的方式,第二层权威DNS服务器20可以进一步查找到访问下层权威DNS服务器的方式或者是相应的IP地址记录。在本实施方式中,第一层权威DNS服务器10包括编列在同一共治组内的若干个权威DNS服务器,共治组内的权威DNS服务器可以相互通信,达到共同治理的目的,其实现的是对下层权威DNS服务器信息的分布式记账。具体地,任意一台权威DNS服务器可以通过类似广播的方式向共治组内的其他权威DNS服务器发送信息,亦或者对特定节点的权威DNS服务器进行通信,以实现相互之间的交互,优选地,权威DNS服务器之间通过专线进行连接。信息更新的触发通常是因为第二层权威DNS服务器20的相关配置发生了变化而引起的,因此需要向第一层权威DNS服务器10提交相应的信息更新,即将新的DNS资源记录等更新在第一层共治组中所有的权威DNS服务器中。具体负责提交的节点可以由对应具有权限的第二层权威DNS服务器20、第一层权威DNS服务器10或者其他实现管理的服务器等实现,在向第一层权威DNS服务器10提交相应的更新信息时,优选地选择距离最近或者链路最佳的权威DNS服务器进行提交,由接收到更新信息的权威DNS服务器向共治组中的其他权威DNS服务器同步请求。如上所述,信息更新的内容具体可以是DNS资源记录,例如特定域名对应的NS记录等,即在第一层权威DNS服务器10中记录指向特定负责解析的第二层权威DNS服务器20。更具体地,在本实施方式中,第一层权威DNS服务器10可以作为根域名服务器,第二层权威DNS服务器20相应地作为顶级域名服务器,顶级域名服务器分别包括负责解析cn、us、de等国家顶级域及com、net等通用顶级域的权威DNS服务器,这些权威DNS服务器通常由特定的国家或者组织进行管理。通过对根域名服务器的去中心化布局,减少了权力滥用的风险。在更多的实施方式中,第一层权威DNS服务器也可以是对下层权威DNS服务器的去中心化布局,可以达到相应的分布式管理的目的。
如上所述,以第一层权威DNS服务器相当于根域名服务器为例,递归DNS服务器通过查询第一层权威DNS服务器可以进一步查询顶级域名服务器,当顶级域名服务器的信息发生了变动时,为了让递归DNS服务器仍然可以查询到相应的顶级域名服务器,上层权威DNS服务器需要对提交的信息更新进行记账,即记录相应的DNS资源记录等。在具体的实施方式中,对于第一层权威DNS服务器,作为共治组中的任意一个权威DNS服务器,可以接收外部提交的信息更新记录,信息更新记录决定了第一层权威DNS服务器是否接收相应的记账及递归解析的相关内容。比如接收的第一信息更新记录可以是关于第一对象的相关信息更新,第一对象指的是递归架构中位于第一层权威DNS服务器之下的特定第二层权威DNS服务器,比如特定的第二层权威DNS服务器发生了变更,亦或者网络连接发生了变化,就需要对第一对象进行信息更新。当任意第一层权威DNS服务器接收到第一信息更新记录时,会对第一信息更新记录进行分析,确定是否进行记账,相应地,也会把第一信息更新记录同步给共治组中的其他权威DNS服务器,其他权威DNS服务器也可以同时做相应的记账分析。在第一信息更新记录中包括对第一对象进行信息更新的第一内容及第一授权信息。第一内容具体可以是DNS资源记录,比如用于确定递归查询下层权威DNS服务器的方式或者是解析特定域名的IP地址,第一内容是为了最终存储在第一层权威DNS服务器中作为查询的信息。第一授权信息是为了在第一层权威DNS服务器接收到第一信息更新记录时,通过验证来确定是否可以在共治组中执行记账,以下将详述。
步骤S2、对所述第一授权信息进行验证,在验证成功时将所述第一信息更新记录确定为待打包记录。如上所述,第一授权信息包含在第一信息更新记录中,当步骤S1接收到第一信息更新记录后,则会对第一授权信息的特征进行验证,其目的是为了保证第一信息更新记录的记账符合相应的权限要求。具体地,第一授权信息包括第一授权节点对应的第一证书,第一授权节点是向第一层权威DNS服务器提交关于特定第二层权威DNS服务器(即第一对象)信息更新记录的节点,信息更新的内容是否接受是由第一授权节点来实现最终的决定,这样的话就可以把第一层权威DNS服务器的信息记账功能与信息验证功能分离,相应地共治组可选择的共识规则就可以更加灵活。而第一授权节点的确定则可以通过共治组的共同决定来确定,如上所述,对于顶级域名服务器而言,主要存在两种类型,一种是国家顶级域,另一种是通用顶级域,对于国家顶级域还可以由对应国家来确定第一授权节点,通用顶级域则可以由特定的组织来确定。需要说明的是,第一授权节点不排除也可以是相应的第一层权威DNS服务器、第二层权威DNS服务器,这样的话在实施中就变的更加方便。当第一授权节点管理的第二层权威DNS服务器发生了变更时,不仅要把信息更新的内容提交给上层的共治组,也会生成相应的第一证书,第一证书采用的是非对称的加密方式,相应的第一授权节点具有关联的第一私钥和第一公钥,通过第一私钥加密生成第一证书用于表示第一授权节点的身份,通过第一公钥解密第一证书就可以验证第一证书的来源身份,因为只有与第一私钥成对的第一公钥才可以正常解密第一证书,进一步就可以确定是否为第一授权节点对第一对象发起的信息更新。具体地,对第一授权信息进行验证包括通过第一授权节点对应的第一公钥对所述第一证书进行验签,第一公钥是公开的,作为第一层权威DNS服务器可以预先存储第一授权节点对应的第一公钥,比如在共治组确定第一授权节点时获得相应的第一公钥并保存。在实施过程中,根据第一信息更新记录确定第一对象,进一步就可以确定对第一对象进行信息更新的第一授权节点,取得第一授权节点对应的第一公钥对第一证书进行验签,如果解密成功相应的第一证书,则说明属于有权限的信息更新,如果解密失败则验签失败,放弃第一信息更新记录的记账。优选地,为了避免第一证书被截取复制后的非法使用,第一证书的内容是动态变化的,第一授权节点在生成第一证书时,可以对第一内容进行加密,对第一授权信息进行验证时具体是对解密后的第一证书内容与明文发过来的第一内容进行比对,只有在比对一致后才会确定通过验证。
上述的实施方式解决了将信息更新的权限下发给特定的第一授权节点,同时可以保证第一授权节点不被冒用的情况,但是在上述实施方式中,作为共治组中的权威DNS服务器还需要针对第一授权节点的第一公钥进行管理,同时第一公钥的确定比较麻烦。在优选的实施方式中,如图4所示,验证通过的信息更新记录41、42、43在共治组的权威DNS服务器中是保存在相互链接的区块中的,以信息更新记录42为第一信息更新记录为例,通过链接的区块可以知道第一信息更新记录相对于第一对象的历史信息更新记录,包括前次信息更新记录41和后次信息更新记录43,还可以查看到每个信息更新记录中信息更新授权信息和信息更新内容。因此可以在每个相对于第一对象的信息更新记录中都保存有第一授权节点的第一公钥,当接收到新的第一信息更新记录做验证时,需要顺着区块链按照时间顺序查找前次关于第一对象的信息更新记录,获取相应的第一公钥,然后做相应的验签工作。在更多的实施方式中,每个相对于第一对象的信息更新记录中都保存的是第一授权节点的第一公钥哈希值,哈希值的特点在于很难做到逆向计算,但却可以很容易实现正向验证,因此可以一定程度的保护第一公钥的泄露。在接收第一信息更新记录时,还会收到相应的第一授权节点的第一公钥,相应的验证过程是先获得前次关于第一对象的信息更新记录中的第一公钥哈希值,对在第一信息更新记录中提供的第一公钥进行同样的哈希计算,并与前次关于第一对象的信息更新记录中的第一公钥哈希值进行比较,如果一致,说明在第一信息更新记录中提供的第一公钥是第一授权节点对应的第一公钥,接着做进一步的验签工作,如果不一致,说明第一信息更新记录中提供的第一公钥不属于第一授权节点,确定验证失败。需要说明的是,当相应的第一信息更新记录需要保存到新的区块时,也会将第一公钥哈希值做相应的存储,供时间在后的关于第一对象的信息更新记录验证使用。
进一步,在第一授权信息中还包括第二授权节点对应的第二公钥或第二公钥的哈希值。如图5所示,关于第一对象的多个信息更新记录中不仅包括信息更新内容,还包括输入授权与输出授权信息。在图5中,以中间的信息更新记录52为第一信息更新记录为例,箭头指向的信息更新记录51为第一信息更新记录按照时间相邻的前次信息更新记录,而被箭头指向的信息更新记录53为第一信息更新记录按照时间相邻的后次信息更新记录,这样可以反映第一对象的信息更新变化。对于第一信息更新记录而言,输入授权信息指的是第一授权节点的第一证书信息,优选地,还包括前次关于第一对象的信息更新记录的所在区块位置及索引,这样可以直接查找到相应的信息更新记录,在图4的实施方式中也可以通过提供区块位置及索引的方式进行快速查找。输出授权指的是第二授权节点的第二公钥,用于为后次信息更新记录的验证提供第二公钥,同理信息更新记录51和信息更新记录53具有类似的内容。以对信息更新记录52进行验签为例,第一授权节点作为对第一对象具有信息更新权限的节点,可以通过信息更新记录51的输出授权确定第一授权节点的第一公钥,从而判断第一授权节点的权限。然后可以根据需要将相应的信息更新权限转移给第二授权节点,相应地,在第一信息更新记录的输出授权中保存第二授权节点提供的第二公钥,因此第二授权节点就可以实施后续对第一对象的信息更新。在更多的实施方式中,每个信息更新记录的输出授权中保存的是相应公钥的哈希值,具体的验证方式可以参照图4的相关实施方式。在本实施方式中,相应的第一信息更新记录中如果不存在相关的权限转移情况,仅仅是信息更新内容的变化,可以在输出授权中直接写入第一授权节点对应的第一公钥或第一公钥的哈希值,即第一授权节点与第二授权节点为同一个节点。相应地,第一对象的信息更新权限还是在第一授权节点上,后次信息更新记录仍然通过第一授权节点的第一证书进行验证。需要补充的是,在第一信息更新记录中,关于输入授权中的第一证书,还可以是基于第一私钥对前次信息更新记录的加密,这样通过查找前次信息更新记录确定第一公钥的同时,还会通过第一公钥解密第一证书后与前次信息更新记录进行比对,如果一致才能认定相应的第一证书验证通过。
因为对于同一对象的信息更新记录在区块链中呈现的是按照时间的顺次关系,因此只需要查找前次的信息更新记录就可以获得相应的公钥信息,但是,对于同一对象的首个信息更新记录必然不存在前次信息更新记录,因此可以确定为创世记录,创世记录的输入授权则不存在相应的在先授权节点,也就不会有相应的授权节点的证书,但是在创世记录的输出授权则有确定的授权节点提供的公钥或者公钥的哈希值,即为相应的对象分配一个授权节点。创世记录可以由共治组中的权威DNS服务器通过投票确定的首个关于相应对象的授权节点,此时可以在对应创世记录的输入授权中标记相关共治组信息,在更多的实施方式中,首个授权节点也可以通过特定的权限申请在共治组中进行注册。
对于上述对第一授权信息进行验证的过程,在验证失败时,说明信息更新的权限存在问题,此时则可以放弃对第一信息更新记录的处理,具体可以删除相应的第一信息更新记录。如果验证成功,则可以准备将第一信息更新记录放入新区块中,完成最终的记账工作。区块是用于具体存放信息更新记录的数据结构,为了保证区块之间的逻辑关系,新区块可以是链接在前次区块之后的区块,通过特定的区块标识来标记链接关系,形成块链式数据结构。如图6所示,一个完整的区块可以包括区块前缀、区块头、区块体,区块前缀和区块头是区块的固定格式,区块前缀可以包括区块分隔符、区块大小等字段,区块头里可以包括版本、前一区块标识、时间戳等,还可以包括用于验证区块体中信息更新记录完整性的哈希参数字段,亦可以包括一些调节字段用于完成特定的计算任务。区块体中用于存放具体的信息更新记录,如上所述第一信息更新记录放入区块中则具体放置在区块体中,后期的查找也可以在对应区块的区块体中进行查找。
当确定第一授权信息需要放入待打包的区块(即新区块)中时,则需要实现相应的记账过程。在本发明的实施方式中,记账权并不是固定地由共治组中的特定权威DNS服务器来实现的,而是基于近乎随机的方式或者不固定的方式在共治组的权威DNS服务器之间轮转,这样可以在共治组中大多数权威DNS服务器处于稳定运行、依规记账的情况下,保证信息更新记录的正常记账。因此,在对第一信息更新记录打包前,会有一定的记账权确定时间,因此在验证成功时是先将所述第一信息更新记录确定为待打包记录,具体可以将第一信息更新记录放入到等待打包的内存数据中,当本地的权威DNS服务器获得了相应记账权,才会把内存数据中的第一信息更新记录取出来打包到新的区块中。在更多的实施方式中,在本地权威DNS服务器未获得记账权之前,接收到共治组中其他权威DNS服务器同步的新区块时,说明其他权威DNS服务器获得了记账权,此时应该暂停相应的操作,确定所述第一信息更新记录是否在新区块中,如果不是,说明第一信息更新记录并没有打包在已有的区块中,可以继续进行打包操作,如果是,则放弃对所述第一信息更新记录的处理,进一步如果第一信息更新记录已经确定为待打包记录,还需要把内存数据中的第一信息更新记录删除,把同步的新区块添加到本地权威DNS服务器中。
步骤S3、根据共识规则与共治组中其他权威DNS服务器协商记账权,在获得记账权时将所述待打包记录放入新区块中,并同步给共治组中其他权威DNS服务器。共治组中的权威DNS服务器之间是对等的,本地的权威DNS服务器并不能直接对验证通过的第一信息更新记录进行记账,而是要根据共治组对应的共识规则来确定自身是否获得相应的记账权。共识规则包括记账权在共治组中的轮转规则,本地权威DNS服务器与共治组中其他权威DNS服务器协商记账权的过程实际上是对记账权进行争夺的过程。需要说明的是,协商记账权的过程并不必然是在步骤S2之后才开始,因此步骤S2和步骤S3不具有绝对的先后关系,在部分共识规则中可以是同步进行的。
具体的共识规则可以是为申请新区块而最先完成设定工作量任务的权威DNS服务器获得记账权,比如工作量任务可以是对待打包区块中的区块头进行哈希计算,对计算的结果验证是否小于指定的目标哈希值,通过调整区块头中的调节字段不断地去试算直到获得符合要求的哈希值,最先计算出相应哈希值的权威DNS服务器获得记账权,即有权利将验证通过的信息更新记录打包到新区块中。
上述的共识规则可以保证记账权的无序轮转,缺点在于非常消耗共治组中权威DNS服务器的资源。在另一实施方式中,获取记账权的共识规则是由共治组中的权威DNS服务器在确定不存在具有记账权权威DNS服务器的情况下,通过随机时间开始发起记账权竞选,由于不同权威DNS服务器发起竞选的时间不一样,因此最先发起竞选的权威DNS服务器会被最先响应,此时其他权威DNS服务器可以对相应竞选进行投票,如果同意数量超过设定阈值,则由发起竞选的权威DNS服务器获得记账权。在具体的实施方式中,获得记账权的权威DNS服务器还会发送心跳信息通知其他权威DNS服务器,以确定共治组中存在具有记账权的权威DNS服务器。一旦共治组中没有相应的心跳信息,则共治组中的所有权威DNS服务器又可以重新按照随机时间发起竞选。需要说明的是,上述实施方式只是示例性地罗列了几种共识规则,由于信息记账功能与信息验证功能分离带来的灵活性,共识规则并不排除其他可能的方式。
当通过共识规则确定具有记账权的权威DNS服务器,比如本地权威DNS服务器获得了记账权,就将待打包记录放入新区块中,即从内存数据中取出对应的信息更新记录放入到新区块中,新区块链接到已有的区块链上。其他权威DNS服务器则不会再对已打包的记录做处理,只会同步新区块。
如图7所示,本发明一实施方式中权威DNS服务器信息更新系统示意图。权威DNS服务器信息更新系统具体包括接收单元U1、验证单元U2及记账单元U3。相应地会设置一个共治组,共治组中包括若干个权威DNS服务器,共治组中的权威DNS服务器可以根据一定的加入和退出机制进行动态管理。共治组中的权威DNS服务器在统一的共识规则下进行决策,具体可以确定如何在对等的权威DNS服务器之间分配记账权,共识规则也可以在共治组中所有权威DNS服务器的同意下进行修改。在具体的实施方式中,共治组中的权威DNS服务器可以分别是不同国家管理的专用权威DNS服务器,亦或者与国家顶级域名服务器处于同一个服务器系统接收顶级域名服务器的信息更新,进一步还可以应用在下层的权威DNS服务器体系中。共治组中的权威DNS服务器通过接收单元U1、验证单元U2及记账单元U3实现DNS体系的去中心化管理。
接收单元U1,用于接收第一信息更新记录,所述第一信息更新记录包括对第一对象进行信息更新的第一内容及第一授权信息。其中第一内容指的可以是DNS资源记录,用于查询访问下层权威DNS服务器的方式。第一授权信息与第一内容、第一对象相关,用于确定第一内容的修改是否经过对第一对象具有修改权限的授权节点操作。接收到的第一信息更新记录被希望存储在共治组中的所有权威DNS服务器中,用于给递归DNS服务器等的查询。但是是否接受第一信息更新记录的存储,取决于对应的第一授权信息是否符合要求。进一步,第一信息更新记录由哪个权威DNS服务器打包到新区块,则需要通过共识规则争抢相应的记账权。
验证单元U2,用于对所述第一授权信息进行验证,在验证成功时将所述第一信息更新记录确定为待打包记录。验证单元U2便是解决是否接受第一信息更新记录的存储,具体对第一授权信息进行验证,其中第一授权信息包括第一授权节点对应的第一证书,所述第一授权节点为具有对所述第一对象进行信息更新权限的节点,对所述第一授权信息进行验证包括通过所述第一授权节点对应的第一公钥对所述第一证书进行验签。在上述实施方式中,对第一对象具有信息更新权限的节点是固定,不可以改变,优选地,第一授权信息还包括第二授权节点对应的第二公钥或第二公钥的哈希值,第二公钥可以是第二授权节点提供给第一授权节点的,以使下次通过所述第二授权节点对所述第一对象进行信息更新时确定对应的第二公钥,所述第二授权节点为通过所述第一授权节点转移获得对所述第一对象进行信息更新权限的节点。具体的第一信息更新记录的结构还可以参照图4-图6及说明书相关内容,通过上述实施方式的实现,区块之间不仅存有相应的信息更新的内容,还直接包括相关的验证信息,大大提高了实施的能力。
记账单元U3,用于根据共识规则与共治组中其他权威DNS服务器协商记账权,在获得记账权时将所述待打包记录放入新区块中,并同步给共治组中其他权威DNS服务器。在记账单元U3中,所述共识规则为申请新区块而最先完成设定工作量任务的权威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 (6)
1.一种权威DNS服务器信息更新方法,其特征在于,与若干个权威DNS服务器组成一个共治组,所述方法具体包括如下步骤:
接收第一信息更新记录,所述第一信息更新记录包括对第一对象进行信息更新的第一内容及第一授权信息;
对所述第一授权信息进行验证,在验证成功时将所述第一信息更新记录确定为待打包记录;
所述第一授权信息包括第一授权节点对应的第一证书,所述第一授权节点为具有对所述第一对象进行信息更新权限的节点,对所述第一授权信息进行验证包括通过所述第一授权节点对应的第一公钥对所述第一证书进行验签;
所述第一授权信息还包括第二授权节点对应的第二公钥或第二公钥的哈希值,以使下次通过所述第二授权节点对所述第一对象进行信息更新时确定对应的第二公钥,所述第二授权节点为通过所述第一授权节点转移获得对所述第一对象进行信息更新权限的节点;
根据共识规则与共治组中其他权威DNS服务器协商记账权,在获得记账权时将所述待打包记录放入新区块中,并同步给共治组中其他权威DNS服务器。
2.根据权利要求1所述的权威DNS服务器信息更新方法,其特征在于,在接收到共治组中其他权威DNS服务器同步的新区块时,确定所述第一信息更新记录是否在新区块中,如果是则放弃对所述第一信息更新记录的处理。
3.根据权利要求1所述的权威DNS服务器信息更新方法,其特征在于,所述共识规则为申请新区块而最先完成设定工作量任务的权威DNS服务器获得记账权。
4.根据权利要求1所述的权威DNS服务器信息更新方法,其特征在于,所述共识规则为随机时间发起竞选并最先获得超过阈值数量的其他权威DNS服务器确认的权威DNS服务器获得记账权。
5.根据权利要求1所述的权威DNS服务器信息更新方法,其特征在于,信息更新的第一内容为DNS资源记录。
6.一种权威DNS服务器信息更新系统,其特征在于,与若干个权威DNS服务器组成一个共治组,所述系统具体包括:
接收单元,用于接收第一信息更新记录,所述第一信息更新记录包括对第一对象进行信息更新的第一内容及第一授权信息;
验证单元,用于对所述第一授权信息进行验证,在验证成功时将所述第一信息更新记录确定为待打包记录;
记账单元,用于根据共识规则与共治组中其他权威DNS服务器协商记账权,在获得记账权时将所述待打包记录放入新区块中,并同步给共治组中其他权威DNS服务器;
所述第一授权信息包括第一授权节点对应的第一证书,所述第一授权节点为具有对所述第一对象进行信息更新权限的节点,所述验证单元对所述第一授权信息进行验证包括通过所述第一授权节点对应的第一公钥对所述第一证书进行验签;
所述第一授权信息还包括第二授权节点对应的第二公钥或第二公钥的哈希值,以使下次所述验证单元通过所述第二授权节点对所述第一对象进行信息更新时确定对应的第二公钥,所述第二授权节点为通过所述第一授权节点转移获得对所述第一对象进行信息更新权限的节点。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010084237.8A CN111343292B (zh) | 2020-02-10 | 2020-02-10 | 权威dns服务器信息更新方法及系统 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010084237.8A CN111343292B (zh) | 2020-02-10 | 2020-02-10 | 权威dns服务器信息更新方法及系统 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN111343292A CN111343292A (zh) | 2020-06-26 |
CN111343292B true CN111343292B (zh) | 2022-09-27 |
Family
ID=71186064
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202010084237.8A Active CN111343292B (zh) | 2020-02-10 | 2020-02-10 | 权威dns服务器信息更新方法及系统 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN111343292B (zh) |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111953802A (zh) * | 2020-07-06 | 2020-11-17 | 网宿科技股份有限公司 | 一种域名的解析方法、系统、设备及存储介质 |
CN113194159B (zh) * | 2021-04-19 | 2023-05-02 | 广州根链国际网络研究院有限公司 | Dns权威数据管理方法及系统 |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN107360206A (zh) * | 2017-03-29 | 2017-11-17 | 阿里巴巴集团控股有限公司 | 一种区块链共识方法、设备及系统 |
CN107769922A (zh) * | 2017-10-31 | 2018-03-06 | 捷德(中国)信息科技有限公司 | 区块链安全管理系统及方法 |
-
2020
- 2020-02-10 CN CN202010084237.8A patent/CN111343292B/zh active Active
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN107360206A (zh) * | 2017-03-29 | 2017-11-17 | 阿里巴巴集团控股有限公司 | 一种区块链共识方法、设备及系统 |
CN107769922A (zh) * | 2017-10-31 | 2018-03-06 | 捷德(中国)信息科技有限公司 | 区块链安全管理系统及方法 |
Non-Patent Citations (4)
Title |
---|
IEEE 15th International Conference on Smart City》.2017,全文. * |
WANG, Xiangui等.ConsortiumDNS: A Distributed Domain Name Service Based on Consortium Chain.《2017 IEEE 19th International Conference on High Performance Computing and Communications * |
基于区块链技术的安全DNS系统设计;马宇生;《中国优秀硕士学位论文全文数据库(信息科技辑)》;20181231;第5.2节 * |
基于区块链的DNS根域名解析体系;庄天舒等;《电信科学》;20180331;第1-4节 * |
Also Published As
Publication number | Publication date |
---|---|
CN111343292A (zh) | 2020-06-26 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10178069B2 (en) | Systems and methods for managing top-level domain names using consortium blockchain | |
EP3844657B1 (en) | Distributed data authentication and validation using blockchain | |
US10951577B2 (en) | Device and method for resolving domain names | |
WO2018191882A1 (zh) | 一种基于区块链的域名解析系统 | |
Liu et al. | A data storage method based on blockchain for decentralization DNS | |
US11368450B2 (en) | Method for bidirectional authorization of blockchain-based resource public key infrastructure | |
CN109983752A (zh) | 带有编码dns级信息的网络地址 | |
CN112260990B (zh) | 一种安全访问内网应用的方法和装置 | |
CN111200642B (zh) | 权威dns服务器信息分发方法及系统 | |
CN112468309B (zh) | 基于智能合约的域名管理系统 | |
CN111343292B (zh) | 权威dns服务器信息更新方法及系统 | |
JP2014182828A (ja) | レコード・セットへのdnssec対応ゾーンの事前署名のためのシステムおよび方法 | |
CN109495604A (zh) | 一种泛根域名解析的方法 | |
CN112260988B (zh) | 一种异常请求处理方法和装置 | |
CN109842626A (zh) | 分配安全区域访问凭证的方法和装置 | |
Liu et al. | A comparative study of blockchain-based dns design | |
Zhang et al. | Blockchain‐Based DNS Root Zone Management Decentralization for Internet of Things | |
Tehrani et al. | The missing piece: On namespace management in NDN and how DNSSEC might help | |
CN111193816A (zh) | 权威dns服务器信息更新方法及系统 | |
CN110071810A (zh) | 一个基于开源dns软件的自证根实现方法 | |
Lioy et al. | DNS security | |
CN111464668A (zh) | 一种快速安全的域名解析方法 | |
Hu et al. | Blockzone: a decentralized and trustworthy data plane for DNS | |
CN111181950A (zh) | 权威dns服务器授权方法及系统 | |
Sun et al. | RFC3650: Handle system overview |
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 |