CN111181950A - 权威dns服务器授权方法及系统 - Google Patents

Abstract

本发明公开了一种权威DNS服务器授权方法及系统，与若干个第一权威DNS服务器组成一个共治组，其中所述方法包括如下步骤：接收第二权威DNS服务器的权限申请，对所述第二权威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服务器的身份及权限申请发送给所述共治组中对应的第一权威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服务器授权分层示意图。

图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地址。

如上所述，通过根域名服务器可以查询到实现相应解析的顶级域名服务器，通过顶级域名服务器可以查询到实现相应解析的二级域名服务器。根域名服务器、顶级域名服务器、二级域名服务器等分别是递归架构中每一层的权威DNS服务器，然而每一层权威DNS服务器的设置在现有技术中通常是事先就固定下来的，缺乏足够的灵活性，同时设置的方式也是拘泥于中心化管理的思路，与多边、民主、透明的互联网发展原则相违背。本发明利用分布式设置、共同决策的机制，对每一层的权威DNS服务器，特别是根域名服务器层的授权进行分布式管理，达到去中心化的效果，以下将详述。

如图2所示，本发明一实施方式中权威DNS服务器授权方法流程图。权威DNS服务器授权方法，具体包括如下步骤：

步骤S1、接收第二权威DNS服务器的权限申请，对所述第二权威DNS服务器的身份进行验证，在验证失败时，拒绝权限申请。如图3所示，无论应用在递归架构哪一层的权威DNS服务器，只要处于共治组中的第一权威DNS服务器10之间都是可以彼此通信实现交互，从而达到共同治理的目的。具体地，任意一台第一权威DNS服务器可以通过类似广播的方式向共治组内的其他第一权威DNS服务器发送信息，亦或者对特定节点的第一权威DNS服务器进行通信，以实现相互之间的交互，优选地，第一权威DNS服务器之间通过专线进行连接。需要说明的是，第一权威DNS服务器在递归架构中，存储有由下层权威DNS服务器进行解析的查询方式，以第一权威DNS服务器充当根域名服务器为例，通过第一权威DNS服务器可以进一步递归查询顶级域名服务器。共治组中第一权威DNS服务器通过同步具有一致的DNS资源记录，因此查询共治组中的任意第一权威DNS服务器都可以达到查询的目的。

对于相应的共治组而言，共治组可以接受新的权威DNS服务器的加入，或者针对特定的权威DNS服务器的权限进行修改，以作为下层权威DNS服务器信息更新的决策节点及存储节点。因此，相应地，在共治组中的第一权威DNS服务器接收第二权威DNS服务器的权限申请中，这里的权限申请可以是申请加入共治组，获得相应的共同决策权，或者是共治组中已有的权威DNS服务器更新相应的投票权或者退出共治组。进一步，更新相应的投票权具体可以是加入或退出com、net等通用顶级域信息更新的共同决策，或者是获得或取消独立确定cn、us、de等国家顶级域的权利。需要说明的是，对于共治组中已有的权威DNS服务器更新相应的投票权或者退出共治组来说，发起权限申请的第二权威DNS服务器实际上也属于共治组中的第一权威DNS服务器，相应地可以设置共识规则不参与步骤S2的第一共识交互。

当接收到第二权威DNS服务器的权限申请时，首先是对第二权威DNS服务器的身份进行验证，根据验证的成功或失败来决定进一步的授权过程，比如验证失败，就说明第二权威DNS服务器的身份存在问题，此时拒绝权限申请，可以直接结束相应的步骤。在本发明实施方式中，将第二权威DNS服务器的身份伪造性判断和权限可授权性判断进行分离，由不同的机制进行决策，从而保证实施的便利性和可靠性。在步骤S1中对第二权威DNS服务器的身份进行验证中，主要是对第二权威DNS服务器的身份是否伪造进行验证，从而杜绝让一些冒名顶替的服务器节点混入到授权过程中，甚至使之加入到共治组中，从而影响后期的DNS体系运作。

在具体的实施方式中，对第二权威DNS服务器的身份进行验证包括根据第二权威DNS服务器的身份特征利用自身规则判断生成身份证书和/或向第三方权威机构申请身份证书。如图3所示，发送权限申请的第二权威DNS服务器可以是传统递归架构中的权威DNS服务器20，即包括现存的根域名服务器、顶级域名服务器等。在本发明实施方式中，第二权威DNS服务器可以兼容传统模式下的权威DNS服务器20，即传统模式下的权威DNS服务器可以根据情况加入到相应的共治组中。由于这些权威DNS服务器20是经过中心化管理的认证通过的，因此第一权威DNS服务器10可以借助传统递归查询方式确定对应权威DNS服务器是否伪造。进一步，当发起权限申请的第二权威DNS服务器判断是传统递归架构中的权威DNS服务器时，具体可以根据递归架构查询到的地址发送验证码，再由对应的第二权威DNS服务器返回相应的验证码以实现验证，优选地，还可以对相应的验证码进行加密操作。另外，也可以无需发送验证码，可以根据递归架构查询到的NS记录或A/AAAA记录直接与第二权威DNS服务器的相关信息进行比较。在更多的实施方式中，特别对于非传统递归架构中的第二权威DNS服务器，此时还可以根据发起权限申请时提供的其他身份特征信息，进行分析判断，以确定信息对应的身份是真实的还是伪造的。

进一步，当确定为伪造时，说明验证失败，如上所述拒绝权限申请。当确定不存在伪造迹象时，对相应的第二权威DNS服务器生成身份证书，可以作为后期验证所用。具体地，身份证书至少包括对应第二权威DNS服务器的身份特征等表示对象身份的信息，用于确定一个特定的权威DNS服务器，优选地，身份证书中还可以包括授权码、有效期、校验值等标志信息。身份证书优选采用非对称加密算法进行加减密，具体生成一组非对称加密算法的密钥对，包括第一公钥及第一私钥，通过第一私钥对身份证书进行加密以防止篡改，同时可以将身份证书发放给第二权威DNS服务器，第一公钥及第一公钥对应的第二权威DNS服务器身份可以同步给共治组中所有的第一权威DNS服务器，以保证以后对应的第二权威DNS服务器在向其他第一权威DNS服务器发起权限申请时，可以通过相应的第一公钥解密查看相应的身份证书信息。

上述的验证过程是基于接收权限申请的第一权威DNS服务器有能力判断真伪的情况，在更多的实施方式中，还可以引入第三方权威机构，由第三方权威机构对第二权威DNS服务器的身份真伪进行认证，相应地发放相应的身份证书。如图3所示，具体流程可以是，由接收权限申请的第一权威DNS服务器10向第三方权威机构40发出申请，第三方权威机构40根据自身的分析资源对发出权限申请的第二权威DNS服务器30的身份进行验证，同时发出相应的身份证书，身份证书可以直接发送给对应的第二权威DNS服务器30，也可以通过对应第一权威DNS服务器10发送给对应的第二权威DNS服务器30。进一步，基于非对称加密算法的公钥、私钥分配机制，可以由对应第一权威DNS服务器生成第二公钥和第二私钥，第一权威DNS服务器10在向第三方权威机构40申请时，将第二权威DNS服务器30的相关信息连同第二公钥发送给第三方权威机构40，第三方权威机构40如果判定属于真实身份的第二权威DNS服务器时，通过第一权威DNS服务器10提供的第二公钥来生成加密的身份证书返回给第一权威DNS服务器10，第一权威DNS服务器10可以利用第二私钥来解密相应的身份证书。为了保证在共治组中的同步，第一权威DNS服务器10还可以对相应的身份证书重新做加密操作，生成非对称的第三公钥、第三私钥，利用第三私钥对身份证书进行加密，然后将第三公钥同步给共治组的其他第一权威DNS服务器10。在对应第一权威DNS服务器10向第三方权威机构40发出申请的交互过程中，如果对通信的安全性没有要求的前提下，第三方权威机构40在返回身份证书时也可以采用明文的方式发送，然后由第一权威DNS服务器10生成第三私钥、第三公钥来实现加密。在更多的实施方式中，身份证书的加密完全由第三方权威机构40来主导，第三方权威机构40在收到相应的身份验证申请时，如果确认属于真实身份时，在生成相应身份证书时，生成非对称的第四私钥、第四公钥，通过第四私钥对其身份证书进行加密，然后将身份证书及相应的第四公钥返回给对应的第一权威DNS服务器10，第一权威DNS服务器10也可以将相应的第四公钥同步给共治组中的其他第一权威DNS服务器10。

在本发明又一实施方式中，对于发起权限申请的第二权威DNS服务器，如果在权限申请时提供相应的身份证书，接收权限申请的第一权威DNS服务器会查找相应的身份证书存储记录，对身份证书的合法性进行验证。具体地包括，对应的第一权威DNS服务器确定是否查找到相应的解密公钥，相应的解密公钥是否可以对身份证书正常解密，解密后的身份证书信息是否与对应的第二权威DNS服务器信息一致，相应的身份证书有效期是否过期等。如果相应的身份证书确定合法，则认定第二权威DNS服务器身份可信，进一步可以执行步骤S2。

步骤S2、在验证成功时，将所述第二权威DNS服务器的身份及权限申请发送给所述共治组中对应的第一权威DNS服务器并实现第一共识交互，以确定权限申请是否授权。步骤S2是在确定对应的第二权威DNS服务器属于真实身份后，对第二权威DNS服务器申请的权限可授权性进行判断。在具体的实施方式中，根据共治组的共识规则通过与共治组中的其他第一权威DNS服务器进行交互，来实现类似投票之类的共识结果。共识规则可以包括需要参与投票的第一权威DNS服务器，比如向共治组中的所有第一权威DNS服务器发起投票，还包括在什么情况的共识结果前提下，确定通过授权，比如在对应的第一权威DNS服务器反馈同意数量超过第一阈值时，确定通过授权，第一阈值可以是同意的比例或者相应的加权值。进一步，共识规则中还可以对投票周期进行限制，确定特定时间段内返回的投票才有效，这样可以有效控制投票等待时间。只有在共治组达成符合共识规则的共识以后，才能确定通过授权，如果不能通过授权，说明第二权威DNS服务器的权限申请在共治组中并没有达成共识，此时就拒绝申请，优选地，会向对应的第二权威DNS服务器发出相应的拒绝信息，具体地可以包括相应的拒绝类型。只有在通过共治组的授权后，才可以对第二权威DNS服务器的权限执行更新，进一步执行步骤S3。

步骤S3、在通过授权时更新本地的授权数据，并与所述共治组中其他第一权威DNS服务器同步更新的授权数据。通过步骤S2确定可以对第二权威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服务器发起投票。

如图4所示，对于与共治组相关的权威DNS服务器，在加入共治组的过程中具有多种状态。如上所述，可以归纳为加入申请状态，第二权威DNS服务器可以向共治组已有的第一权威DNS服务器发起权限申请，优选地，向链路状况最优的第一权威DNS服务器发起权限申请。接着第一权威DNS服务器会针对加入申请进行证书验证，进一步第二权威DNS服务器会进入等待状态，主要等待共治组中的第一权威DNS服务器之间的共识交互，如果通过授权，则进入授权状态。加入共治组的权威DNS服务器根据实际情况在授权状态、离线状态、等待状态之间进行转换，比如，处于授权状态的权威DNS服务器发起权限修改的申请后，则又可能进入等待状态，或者相应的权威DNS服务器与其他权威DNS服务器断开了，则进入了离线状态。

如图5所示，本发明一实施方式中权威DNS服务器授权系统示意图。权威DNS服务器授权系统具体包括验证单元U1、共识单元U2及执行单元U3。相应地会设置一个共治组，共治组中包括若干个第一权威DNS服务器，共治组中的第一权威DNS服务器可以对加入的第二权威DNS服务器进行加入管理，或者对特定的第一权威DNS服务器进行权限修改管理。需要说明的是，第一权威DNS服务器和第二权威DNS服务器不具有绝对的区分关系，第二权威DNS服务器通过加入对应共治组的共识交互而成为第一权威DNS服务器。共治组中的权威DNS服务器在统一的共识规则下进行决策，共识规则也可以在共治组中所有权威DNS服务器的同意下进行修改。在具体的实施方式中，共治组中的权威DNS服务器可以是根域名服务器层的权威DNS服务器，用于连接下层的顶级域名服务器，亦或者应用在更下层的递归架构中。共治组中的权威DNS服务器通过验证单元U1、共识单元U2及执行单元U3实现DNS体系的去中心化管理。

验证单元U1，用于接收第二权威DNS服务器的权限申请，对所述第二权威DNS服务器的身份进行验证，在验证失败时，拒绝权限申请。参照权威DNS服务器授权方法的具体实施方式，第二权威DNS服务器的权限申请可以包括申请加入共治组或者修改在共治组中的权限。相应地，共治组中的第一权威DNS服务器接收到权限申请时，会对第二权威DNS服务器的身份进行验证，从而确定第二权威DNS服务器是不是伪造的，这样才可以在真实身份的基础上进行权限决策。

具体地，对所述第二权威DNS服务器的身份进行验证包括根据所述第二权威DNS服务器的身份特征利用自身规则判断生成身份证书和/或向第三方权威机构申请身份证书。身份证书可以设置为通过加密认证的身份信息凭证，其不被篡改，具有一定的信息证明作用。其中，第二权威DNS服务器的身份证书至少包括用于加密证书的私钥及用于解密证书的公钥，所述私钥与所述公钥为一对非对称密钥，所述公钥绑定所述第二权威DNS服务器身份，与所述共治组中其他第一权威DNS服务器进行同步。当对应的第二权威DNS服务器存在相应的身份证书时，可以对所述第二权威DNS服务器的身份证书合法性进行验证，从而判断对应的第二权威DNS服务器的身份是不是被伪造的。

共识单元U2，用于在验证成功时，将所述第二权威DNS服务器的身份及权限申请发送给所述共治组中对应的第一权威DNS服务器并实现第一共识交互，以确定权限申请是否授权。共识单元U2是在验证单元U1确定第二权威DNS服务器的身份后，对其申请的权限进行决策处理，相应地，接收权限申请的第一权威DNS服务器向共治组中的其他第一权威DNS服务器发起投票，投票附带信息中包括第二权威DNS服务器的身份及权限申请内容等。这里参与投票的其他第一权威DNS服务器由共治组对应的共识规则决定，优选地，让共治组中所有的在线第一权威DNS服务器共同决策。设置第一阈值，在对应的第一权威DNS服务器反馈同意数量超过第一阈值时，确定共治组已经接受权限申请的更新，确定通过授权，反之，确定未通过授权，否决相应的权限申请。

执行单元U3，用于在通过授权时更新本地的授权数据，并与所述共治组中其他第一权威DNS服务器同步更新的授权数据。执行单元U3实现对共治组中的授权数据的更新，保证共治组中的每个权威DNS服务器具有最新的共治组的组成状态及共识规则等。进一步，在通过授权时，还向所述第二权威DNS服务器同步DNS资源记录及所述共治组中其他第一权威DNS服务器的连接方式、共识规则，让新加入的权威DNS服务器可以参与到共治组的决策管理。

在更多的实施方式中，权威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服务器采用哈希映射的数据存储，大大加快了数据的查询速度，缩短等待时间，进一步，如上所述的授权数据等是存储在块链式数据结构的特定区块中。

结合本申请所公开的技术方案，可以直接体现为硬件、由控制单元执行的软件模块或二者组合，即一个或多个步骤和/或一个或多个步骤组合，既可以对应于计算机程序流程的各个软件模块，亦可以对应于各个硬件模块，例如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服务器的身份进行验证，在验证失败时，拒绝权限申请；

在验证成功时，将所述第二权威DNS服务器的身份及权限申请发送给所述共治组中对应的第一权威DNS服务器并实现第一共识交互，以确定权限申请是否授权；

在通过授权时更新本地的授权数据，并与所述共治组中其他第一权威DNS服务器同步更新的授权数据。

2.根据权利要求1所述的权威DNS服务器授权方法，其特征在于，对所述第二权威DNS服务器的身份进行验证包括根据所述第二权威DNS服务器的身份特征利用自身规则判断生成身份证书和/或向第三方权威机构申请身份证书。

3.根据权利要求2所述的权威DNS服务器授权方法，其特征在于，第二权威DNS服务器的身份证书至少包括用于加密证书的私钥及用于解密证书的公钥，所述私钥与所述公钥为一对非对称密钥，所述公钥绑定所述第二权威DNS服务器身份，与所述共治组中其他第一权威DNS服务器进行同步。

4.根据权利要求1所述的权威DNS服务器授权方法，其特征在于，对所述第二权威DNS服务器的身份进行验证包括在存在所述第二权威DNS服务器的身份证书时，对所述第二权威DNS服务器的身份证书合法性进行验证。

5.根据权利要求1所述的权威DNS服务器授权方法，其特征在于，所述第一共识交互包括向共治组中对应的第一权威DNS服务器发起投票，在对应的第一权威DNS服务器反馈同意数量超过第一阈值时，确定通过授权。

6.根据权利要求1所述的权威DNS服务器授权方法，其特征在于，在通过授权时，还向所述第二权威DNS服务器同步DNS资源记录及所述共治组中其他第一权威DNS服务器的连接方式、共识规则。

7.根据权利要求1所述的权威DNS服务器授权方法，其特征在于，获取与所述共治组中其他第一权威DNS服务器之间的心跳检测状况，发起对离线超时的第一权威DNS服务器的第二共识交互。

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

验证单元，用于接收第二权威DNS服务器的权限申请，对所述第二权威DNS服务器的身份进行验证，在验证失败时，拒绝权限申请；

共识单元，用于在验证成功时，将所述第二权威DNS服务器的身份及权限申请发送给所述共治组中对应的第一权威DNS服务器并实现第一共识交互，以确定权限申请是否授权；

执行单元，用于在通过授权时更新本地的授权数据，并与所述共治组中其他第一权威DNS服务器同步更新的授权数据。

9.根据权利要求8所述的权威DNS服务器授权系统，其特征在于，所述验证单元对所述第二权威DNS服务器的身份进行验证包括根据所述第二权威DNS服务器的身份特征利用自身规则判断生成身份证书和/或向第三方权威机构申请身份证书。

10.根据权利要求8所述的权威DNS服务器授权系统，其特征在于，在所述共识单元中，所述第一共识交互包括向共治组中对应的第一权威DNS服务器发起投票，在对应的第一权威DNS服务器反馈同意数量超过第一阈值时，确定通过授权。

Images