CN111193816A - 权威dns服务器信息更新方法及系统 - Google Patents

Abstract

本发明公开了一种权威DNS服务器信息更新方法及系统，与若干个权威DNS服务器组成一个共治组，其中所述方法包括如下步骤：响应信息更新的触发，对信息更新的合规性进行验证，在验证失败时，拒绝信息更新；在验证成功时，根据所述共治组的共识规则判断是否与共治组中其他权威DNS服务器进行交互，以确定信息更新；在确定信息更新时执行本地的信息更新，并与共治组中其他权威DNS服务器同步更新的信息。本发明可以减少DNS服务对中心化管理的依赖，提高整个DNS体系的安全性。

Description

权威DNS服务器信息更新方法及系统

技术领域

本发明涉及计算机网络通信技术领域，尤其涉及一种权威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服务器信息更新方法的进一步改进，对信息更新的合规性验证包括信息更新中的IP地址格式、和/或域名内容、和/或邮箱内容、和/或备注信息内容、和/或服务类型是否符合第一预设规则。

作为本发明上述权威DNS服务器信息更新方法的进一步改进，所述共识规则包括在信息更新属于共治类型时，向共治组中对应的权威DNS服务器发起投票，在对应的权威DNS服务器反馈同意数量超过第二阈值时，确定执行信息更新。

作为本发明上述权威DNS服务器信息更新方法的进一步改进，所述共识规则包括在信息更新属于自治类型时，判断是否在自身的权威DNS服务器自治域内，如果是则直接确定是否执行信息更新，如果否则发送给对应自治域权限的权威DNS服务器进行处理。

作为本发明上述权威DNS服务器信息更新方法的进一步改进，信息更新的内容为DNS资源记录。

为了解决上述技术问题，本发明的一种权威DNS服务器信息更新系统，与若干个权威DNS服务器组成一个共治组，所述系统具体包括：

验证单元，用于响应信息更新的触发，对信息更新的合规性进行验证，在验证失败时，拒绝信息更新；

共识单元，用于在验证成功时，根据所述共治组的共识规则判断是否与共治组中其他权威DNS服务器进行交互，以确定信息更新；

执行单元，用于在确定信息更新时执行本地的信息更新，并与共治组中其他权威DNS服务器同步更新的信息。

作为本发明上述权威DNS服务器信息更新系统的进一步改进，所述验证单元对信息更新的合规性验证包括信息更新中的IP地址格式、和/或域名内容、和/或邮箱内容、和/或备注信息内容、和/或服务类型是否符合第一预设规则。

作为本发明上述权威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服务器信息更新分层示意图。

图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服务器10上进行注册。在本实施方式中，第一层权威DNS服务器10包括编列在同一共治组内的若干个权威DNS服务器组成，共治组内的权威DNS服务器可以相互通信，达到共同治理的目的。具体地，任意一台权威DNS服务器可以通过类似广播的方式向共治组内的其他权威DNS服务器发送信息，亦或者对特定节点的权威DNS服务器进行通信，以实现相互之间的交互，优选地，权威DNS服务器之间通过专线进行连接。信息更新的触发通常是由第二层权威DNS服务器发起，其目的是向上层权威DNS服务器注册新的信息，第二层权威DNS服务器20在向第一层权威DNS服务器10发送信息更新请求时，优选地选择距离最近或者链路最佳的权威DNS服务器进行请求。这里的信息更新具体的可以是DNS资源记录，例如特定域名对应的NS记录等，即在第一层权威DNS服务器中记录指向特定负责解析的第二层权威DNS服务器。更具体地，在本实施方式中，第一层权威DNS服务器特指的可以是根域名服务器，第二层权威DNS服务器则特指的是顶级域名服务器，顶级域名服务器分别包括负责解析cn、us、de等国家顶级域及com、net等通用顶级域的权威DNS服务器，通过对根域名服务器的去中心化布局，减少了权力滥用的风险。在更多的实施方式中，第一层权威DNS服务器也可以是对下层权威DNS服务器的去中心化布局，可以达到相应的分布式管理的目的。

如上所述，以第一层权威DNS服务器为根域名服务器为例，递归DNS服务器通过查询根域名服务器可以进一步查询顶级域名服务器，当顶级域名服务器的信息发生了变动时，为了让递归DNS服务器仍然可以查询到相应的顶级域名服务器，顶级域名服务器则需要向上一层的根域名服务器发起信息更新的动作。上层的权威DNS服务器接收到相应的更新请求，就需要响应相应的触发，具体地可以判断是否需要进行相应的信息更新。在步骤S1中，当收到信息更新的请求时，会先对信息更新的合规性进行验证，这里主要是对信息更新中的IP地址格式、和/或域名内容、和/或邮箱内容、和/或备注信息内容、和/或服务类型等进行判断，评判是否符合一定的规则，具体设置相应的第一预设规则，第一预设规则比如有IPv4地址、IPv6地址的标准格式，对于域名内容，可以包括域名的内容格式，为域名设定相应的最大长度等，邮箱内容、备注信息内容也有类似的格式及长度规则，服务类型规则即设定类似黑名单的服务类型列表等。更多的还有对信息更新的请求方身份是否合规做验证，即确定是否为非法身份发起的信息更新。通过对信息更新是否符合第一预设规则进行判断，从而可以丢弃一部分不符合第一预设规则的信息更新，即根据第一预设规则，对信息更新的合规性进行验证，在验证失败时，拒绝信息更新。

步骤S2、在验证成功时，根据所述共治组的共识规则判断是否与共治组中其他权威DNS服务器进行交互，以确定信息更新。对于步骤S1的信息更新验证，如果验证成功时，即符合第一预设规则，说明信息更新的内容属于正常的信息更新，属于第一层权威DNS服务器需要进行的信息更新。此时，接收到信息更新的权威DNS服务器，需要根据共治组的共识规则来进行相应的决策。如上所述，共治组中具有若干个权威DNS服务器，同一共治组的权威DNS服务器间执行相同的共识规则，共识规则包括整个共治组的统一治理规则，比如对于信息更新而言，哪些信息更新需要经过哪些权威DNS服务器通过哪种方式进行确定，这些规则都是事先设定好被共治组中的每个权威DNS服务器所接受的，并且每个权威DNS服务器可以在共识规则的架构下独立地作出决策。

对于信息更新，共识规则将信息更新大致分为共治类型及自治类型，共治类型是指共治组中的多个特定权威DNS服务器共同投票达到通过条件时才可以执行信息更新，自治类型是指共治组中的特定权威DNS服务器独立进行判断是否执行信息更新，共治组中的其他权威DNS服务器默认接受特定权威DNS服务器的决策。

在具体的实施方式中，对于共治类型的信息更新，比如共识规则规定com、net等通用顶级域相关的信息更新需要经过共治组中的所有权威DNS服务器或者具有投票权的权威DNS服务器通过投票达到通过条件才可以执行信息更新，通过条件可以为是否超过同意的比例，亦或者每个投票具有不同的权重，判断加权值是否达到一定的数值等。在具体执行过程中，可以通过判断信息更新的相应域名属于通用顶级域时确定共治类型，查询共识规则中规定的共治组中具有投票权的权威DNS服务器，向对应的权威DNS服务器发起投票以与共治组中其他权威DNS服务器进行交互，对应的权威DNS服务器根据自身的规则进行判断确定反馈同意还是否决，共识规则中设置有第二阈值，如上所述，具体可以是同意比例或者加权值，在同意数量超过第二阈值时，即表示信息更新在共治组中达成了共识，就可以进行信息更新。

而对于自治类型的信息更新，比如共识规则规定cn、us、de等国家顶级域相关的信息更新只需经过特定的权威DNS服务器确定，就可以决策是否进行信息更新。一般而言，上述国家顶级域的信息更新可以由共治组中对应国家的权威DNS服务器独立进行决策，但是，为了满足特定环境或条件的需要，也可以将对应的国家顶级域信息更新的投票权转让给特定的权威DNS服务器，这个由原国家顶级域对应的权威DNS服务器决定，并向共治组中的其他权威DNS服务器同步相应的转让信息，在共治组中更新自治类型的对应共识规则。在具体执行过程中，可以通过判断信息更新的相应域名属于国家顶级域时确定自治类型，进一步还要判断对应的信息更新是否在自身的权威DNS服务器自治域内。如上所述，对于自治类型的信息更新，是由共治组中对应的权威DNS服务器独立进行决策的，因此当共治组中的一个权威DNS服务器接收到自治类型的信息更新时，确定相应的信息更新不属于自身的权威DNS服务器时，它是无权进行决策的，此时可以通过最新的共识规则确定指定的权威DNS服务器。权威DNS服务器的自治域是由共治组的共识规则决定的，比如规定了特定的权威DNS服务器可以进行独立决策特定国家顶级域的信息更新。需要说明的是，这类共识规则不是恒定不变的，也可以根据权限进行修改并在共治组中进行同步更新，比如上述的投票权转让。进一步，交互的方式是在判断对应的信息更新在自身的权威DNS服务器自治域内时，直接确定执行信息更新，此时可以将确定执行的信息同步给共治组中的其他权威DNS服务器，如果对应的信息更新不在自身的权威DNS服务器自治域内时，则可以根据共识规则确定具有权限的权威DNS服务器，发送给对应自治域权限的权威DNS服务器进行处理，进一步还可以将无权处理的信息反馈给提出信息更新请求的下层权威DNS服务器，对应的下层权威DNS服务器可以根据情况直接与具有对应自治域权限的权威DNS服务器进行交互。

步骤S3、在确定信息更新时执行本地的信息更新，并与共治组中其他权威DNS服务器同步更新的信息。通过步骤S2可以最终判断得出是否可以对请求的信息更新进行执行，无论是共治类型还是自治类型的信息更新，如果没有被确定执行信息更新，就拒绝相应的更新，进一步可以将相应的拒绝信息反馈给提出信息更新请求的下层权威DNS服务器，优选地，还可以根据不同的情况反馈具体的拒绝类型信息提示。自身的权威DNS服务器在确定需要进行更新时，先将本地的信息进行更新，并与共治组中其他权威DNS服务器同步更新的信息，这样就可以让共治组中的所有权威DNS服务器都掌握了相应更新的信息。在具体的实施方式中，共治组中的权威DNS服务器同步是通过区块链态来实现自动同步的，以下将详述。以cn顶级域名服务器向上层权威DNS服务器发起信息更新请求为例，当共治组中中国对应的权威DNS服务器同意相应的信息更新时，中国对应的权威DNS服务器先对自身的服务器进行信息更新，进一步与共治组中其他权威DNS服务器进行同步更新，这样当特定的递归DNS服务器向共治组中的任何一个权威DNS服务器查询cn域顶级域名服务器时，都可以获得最新的相同的DNS资源记录。

如图4所示，在又一实施方式中，在开始一系列的信息更新时，由下层的权威DNS服务器或者其他符合要求的服务器发起步骤S11触发信息更新，通常是与上层共治组中的一个权威DNS服务器进行交互，接收到信息更新请求的权威DNS服务器响应信息更新的触发，执行步骤S12，进行信息验证，具体可以对信息更新中的IP地址格式、和/或域名内容、和/或邮箱内容、和/或备注信息内容、和/或服务类型等进行判断，进一步还可以对信息更新的请求方进行身份验证，确定是否符合信息更新的身份要求，比如不是符合要求的下层权威DNS服务器的信息更新，拒绝更新。通过步骤S12的判断，验证失败的执行步骤S17拒绝更新，结束整个信息更新流程。验证成功的，进一步执行步骤S13，对信息更新的共识类型进行验证，如上所述，信息更新大致分为共治类型及自治类型，在确定为共治类型时，进入步骤S15，向共治组中对应的权威DNS服务器发起投票，在步骤S16中，对共治组中对应的权威DNS服务器反馈的投票结果进行分析，具体地，为了防止特定权威DNS服务器长时间不反馈信息的情况，还设置一个投票周期，在投票周期内未收到对应权威DNS服务器反馈的投票结果，则默认为否决或者是同意，在更多的实施方式中，还可以根据与不同权威DNS服务器的链路状况来确定不同的投票周期时间。进一步根据所有的权威DNS服务器反馈的投票结果进行相应的阈值判断，以确定否决还是通过相应的信息更新，如果否决同样进入步骤S17结束信息更新流程，如果通过则进入步骤S14执行更新，执行完成后再结束整个信息更新流程。对于步骤S13判断为自治类型时，则需要具有相应自治域权限的权威DNS服务器执行步骤S14的更新并同步，以完成相应的信息更新流程。

如图5所示，本发明一实施方式中权威DNS服务器信息更新系统示意图。权威DNS服务器信息更新系统具体包括验证单元U1、共识单元U2及执行单元U3。相应地会设置一个共治组，共治组中包括若干个权威DNS服务器，共治组中的权威DNS服务器可以根据一定的加入和退出机制进行动态管理。共治组中的权威DNS服务器在统一的共识规则下进行决策，共识规则也可以在共治组中所有权威DNS服务器的同意下进行修改。在具体的实施方式中，共治组中的权威DNS服务器可以分别是不同国家管理的专用权威DNS服务器，亦或者与国家顶级域名服务器处于同一个服务器系统接收顶级域名服务器的更新请求，进一步还可以应用在下层的权威DNS服务器体系中。共治组中的权威DNS服务器通过验证单元U1、共识单元U2及执行单元U3实现DNS体系的去中心化管理。

验证单元U1，用于响应信息更新的触发，对信息更新的合规性进行验证，在验证失败时，拒绝信息更新。信息更新的触发一般由如图3所示的第二层权威DNS服务器20发起，通常是由于对应第二层权威DNS服务器20发生了改变，需要更新在第一层权威DNS服务器10中存储的资源记录。验证单元U1对于接收到的信息更新进行响应，进一步对信息更新的合规性进行验证，具体包括信息更新中的IP地址格式、和/或域名内容、和/或邮箱内容、和/或备注信息内容、和/或服务类型是否符合第一预设规则等，优选地，还会对信息更新的发起方进行身份验证，对信息更新中的下层权威DNS服务器进行权限判断。通过验证，如果验证失败时，说明整个共治组都不接收相应的信息更新，拒绝信息更新，优选地，拒绝的提示信息还会反馈给信息更新的发起方。

共识单元U2，用于在验证成功时，根据所述共治组的共识规则判断是否与共治组中其他权威DNS服务器进行交互，以确定信息更新。共识单元U2针对验证单元U1的验证，对验证成功的信息更新做进一步的共识操作，其基于的是对应共治组的共识规则。根据共识规则，需要根据信息更新的类型来确定在共治组中达成什么形式的一致，对应地需要与共治组中对应的权威DNS服务器进行通信以实现交互。

在具体的实施方式中，共识单元U2对判断确定的共治类型信息更新，根据共识规则确定共治组中需要参与投票的权威DNS服务器，向共治组中对应的权威DNS服务器发起投票，即分别向对应权威DNS服务器发送相应信息更新的请求搜集，统计对应权威DNS服务器的反馈，反馈同意即表示接受相应的信息更新，反馈否决即表示不接受相应的信息更新。具体地设置第二阈值，在对应的权威DNS服务器反馈同意数量超过第二阈值时，确定执行信息更新。统计反馈同意的数量可以设置相应的投票周期，投票周期结束即不再等待未响应的权威DNS服务器的反馈，直接开始与第二阈值进行比较处理。

共识单元U2对判断确定的自治类型信息更新，需要判断是否在自身的权威DNS服务器自治域内，自治域表示对应权威DNS服务器可以独立处理的信息更新范围，具体的可以是特定的顶级域等。如果信息更新属于自身权威DNS服务器的自治域，则表示自身就可以对相应的信息更新进行分析处理，此时直接根据自身的判断规则确定是否执行信息更新。如果信息更新不属于自身权威DNS服务器的自治域，说明信息更新是由其他有自治域权限的权威DNS服务器进行处理，此时可以根据共治组的共识规则确定有自治域权限的权威DNS服务器，发送给对应自治域权限的权威DNS服务器进行处理。如果存在信息更新超出对应共治组的管理权限时，比如对应的信息更新在共治组中不存在任何一个权威DNS服务器具有相应的自治域权限，也可以拒绝更新，丢弃相应的信息更新请求。

执行单元U3，用于在确定信息更新时执行本地的信息更新，并与共治组中其他权威DNS服务器同步更新的信息。执行单元U3在共识单元U2确定需要执行信息更新的前提下，执行对本地的信息更新，同时也与共治组中其他权威DNS服务器同步更新的信息，保证共治组中的各个权威DNS服务器保持数据一致。这样即使共治组中的部分权威DNS服务器出现了数据丢失等情况时，也可以通过正常运行的权威DNS服务器恢复完整的数据，提高数据存储的冗余性及灾备能力。需要说明的是，权威DNS服务器信息更新系统的具体实施方式，还可以参照权威DNS服务器信息更新方法的具体实施方式。

如图6所示，为了适应应用过程中的实施和扩展，可以将整个权威DNS服务器信息更新系统自上而下分成三层结构，包括API(Application Programming Interface,应用程序接口)接口层、智能合约层、区块链处理层。API接口层为用户与智能合约层提供交互的接口，通过API接口层进行信息增删改查以及投票等操作，并提供相应的扩展；智能合约层是整个系统的核心，主要用于验证、存储、操作相关信息，用户可以通过API接口层与智能合约层进行交互，并在验证身份后完成相关操作。区块链处理层负责对接智能合约层以及存储相应数据，同时数据修改的每一次操作都将在区块链处理层上留下记录，确保数据修改的可追溯性，从而保证了系统数据的防篡改和一致性。

进一步，如图7所示，可以将整个系统分为区块链态和应用程序态，区块链态负责具体管理的实施，包括合约注册机及投票管理模块、共治组授权管理模块、DNS信息管理模块、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服务对中心化管理的依赖，提高整个DNS体系的安全性。

应当理解，虽然本说明书按照实施方式加以描述，但并非每个实施方式仅包含一个独立的技术方案，说明书的这种叙述方式仅仅是为了清楚起见，本领域技术人员应当将说明书作为一个整体，各实施方式中的技术方案也可以经适当组合，形成本领域技术人员可以理解的其他实施方式。

上文所列出的一系列的详细说明仅仅是针对本发明的可行性实施方式的具体说明，它们并非用以限制本发明的保护范围，凡未脱离本发明技艺精神所作的等效实施方式或变更均应包含在本发明的保护范围之内。

Claims (10)

1.一种权威DNS服务器信息更新方法，其特征在于，与若干个权威DNS服务器组成一个共治组，所述方法具体包括如下步骤：

响应信息更新的触发，对信息更新的合规性进行验证，在验证失败时，拒绝信息更新；

在验证成功时，根据所述共治组的共识规则判断是否与共治组中其他权威DNS服务器进行交互，以确定信息更新；

在确定信息更新时执行本地的信息更新，并与共治组中其他权威DNS服务器同步更新的信息。

2.根据权利要求1所述的权威DNS服务器信息更新方法，其特征在于，对信息更新的合规性验证包括信息更新中的IP地址格式、和/或域名内容、和/或邮箱内容、和/或备注信息内容、和/或服务类型是否符合第一预设规则。

3.根据权利要求1所述的权威DNS服务器信息更新方法，其特征在于，所述共识规则包括在信息更新属于共治类型时，向共治组中对应的权威DNS服务器发起投票，在对应的权威DNS服务器反馈同意数量超过第二阈值时，确定执行信息更新。

4.根据权利要求1所述的权威DNS服务器信息更新方法，其特征在于，所述共识规则包括在信息更新属于自治类型时，判断是否在自身的权威DNS服务器自治域内，如果是则直接确定是否执行信息更新，如果否则发送给对应自治域权限的权威DNS服务器进行处理。

5.根据权利要求1所述的权威DNS服务器信息更新方法，其特征在于，信息更新的内容为DNS资源记录。

6.一种权威DNS服务器信息更新系统，其特征在于，与若干个权威DNS服务器组成一个共治组，所述系统具体包括：

验证单元，用于响应信息更新的触发，对信息更新的合规性进行验证，在验证失败时，拒绝信息更新；

共识单元，用于在验证成功时，根据所述共治组的共识规则判断是否与共治组中其他权威DNS服务器进行交互，以确定信息更新；

执行单元，用于在确定信息更新时执行本地的信息更新，并与共治组中其他权威DNS服务器同步更新的信息。

7.根据权利要求6所述的权威DNS服务器信息更新系统，其特征在于，所述验证单元对信息更新的合规性验证包括信息更新中的IP地址格式、和/或域名内容、和/或邮箱内容、和/或备注信息内容、和/或服务类型是否符合第一预设规则。

8.根据权利要求6所述的权威DNS服务器信息更新系统，其特征在于，在所述共识单元中，所述共识规则包括在信息更新属于共治类型时，向共治组中对应的权威DNS服务器发起投票，在对应的权威DNS服务器反馈同意数量超过第二阈值时，确定执行信息更新。

9.根据权利要求6所述的权威DNS服务器信息更新系统，其特征在于，在所述共识单元中，所述共识规则包括在信息更新属于自治类型时，判断是否在自身的权威DNS服务器自治域内，如果是则直接确定是否执行信息更新，如果否则发送给对应自治域权限的权威DNS服务器进行处理。

10.根据权利要求6所述的权威DNS服务器信息更新系统，其特征在于，信息更新的内容为DNS资源记录。

Images