CN110071810B - 一个基于开源dns软件的自证根实现方法 - Google Patents

Abstract

一个基于开源DNS软件的自证根实现方法，涉及DNS安全改进技术领域。本发明为了解决现有的DNSSEC方案中不提供针对根区胶水记录的签名机制，致使根区胶水记录面临被篡改的问题。本发明包含在根服务器和顶级域服务器中生成区域密钥及其对胶水记录的签名，将顶级域密钥及其对胶水记录签名发布到根服务器中替代根区原有的胶水记录，在递归解析器上向根服务器查询顶级域胶水记录并进行DNSSEC验证。自证根方案是对DNSSEC方案中胶水记录可能被篡改的安全隐患进行的改进，通过添加对根区胶水记录的签名，提高了根区胶水记录安全性。本发明通过修改一个开源DNS软件的源码，在根区中建立了一条由根到顶级域胶水记录的信任链，实现了自证根。

Description

一个基于开源DNS软件的自证根实现方法

技术领域

本发明涉及DNS安全改进技术领域，具体为涉及一个基于开源DNS软件的自证根实现方法。

背景技术

域名系统(DNS)是人们使用TCP/IP协议访问因特网时的一项基础核心服务，它通过将主机名映射到IP地址，提供更加便捷的互联网服务方式。DNSSEC安全扩展的主要思想是通过公钥加密技术对DNS中的信息创建密码签名，为DNS内部的信息同时提供权限认证和信息完整性检查。DNSSEC的设计思想是由上到下或自下而上，逐级对签名进行验证。DNSSEC的实现依赖于DS记录，即子域的公共密钥的摘要。DS记录存储的位置在父域中，通过信任委托的方式，实现将信任从父域的密钥传递到子域的密钥上。这其中的安全隐患在于，一个域只对其中的权威数据签名，胶水记录的安全性无法得到保障。

发明内容

本发明的目的是提供一种基于开源DNS软件的自证根实现方法，为了解决现有的DNSSEC方案中不提供针对根区胶水记录的签名机制，致使根区胶水记录面临被篡改的问题。

本发明为解决上述技术问题采取的技术方案是：

一个基于开源DNS软件的自证根实现方法，所述自证根为一个根区数据本身可自证来源真实性的安全DNS加密方案(针对现有DNSSEC方案中根区胶水记录因不提供签名机制而面临可能被篡改的隐患而提出)，自证根主要包含三个设计目标：

一、胶水签名：对胶水记录添加来自顶级域权威的数字签名，令根区胶水记录来源可公开验证；自证根在开源DNS软件bind中实现服务器端胶水签名；

二、公钥钉：解析器采用公钥白名单或首用信任的方法来获得顶级域公钥；

三、双重签名：当顶级域密钥滚动时，新的顶级域公钥证书需要来自根权威和顶级域权威(使用旧密钥)的两个签名；

胶水签名、公钥钉以及双重签名在开源DNS软件bind中实现的；

自证根在开源DNS软件bind中实现服务器端胶水签名的过程包括：

(1)服务器配置：

(1.1)先进行顶级域服务器的配置，包含配置系统环境、配置顶级域区文件、配置named服务器中的选项；其中，配置顶级域区文件的步骤如下：

(1.1.1)建立区文件，添加TTL记录、顶级域SOA记录、顶级域NS记录和对应的A记录；

(1.1.2)使用dnssec-keygen工具生成顶级域DNSKEY记录(DNSKEY记录包含KSK和ZSK密钥)，将生成的密钥添加到所述顶级域区文件中；

(1.1.3)使用dnssec-signzone工具生成对顶级域区文件进行签名，生成相关记录的RRSIG和NSEC记录，所述的相关记录包含根区的胶水记录；

(1.2)再进行根服务器的配置，因为根服务器的区文件中的顶级域DS记录需要在完成顶级域服务器配置后才能获得；

根服务器的配置包含配置系统环境、配置区文件、配置named服务器中的options；其中，区文件内容除包含根区本身的TTL记录、SOA记录、NS记录和名称服务器对应的A记录外，还需要加入顶级域NS记录和顶级域名称服务器对应的A记录，以及顶级域区文件签名成功后生成的DS记录；

(2)信任链合成，其过程为：

(2.1)建立根服务器的区文件时添加顶级域密钥；

(2.2)对根区文件进行签名后，生成顶级域NSEC记录(不会直接生成对顶级域DNSKEY记录和NS记录的RRSIG记录，只会生成顶级域NSEC记录)；

(2.3)在签名后的根区文件中，添加顶级域DNSKEY记录的签名(签名为RRSIG记录)和NS记录(NS记录为胶水记录)的签名，生成一条由根到顶级域的信任链。

(3)查询验证，

在递归解析器上向根服务器查询顶级域NS记录，并进行DNSSEC验证，验证成功即得到一条由根到顶级域的完整信任链，其过程具体包括：

(3.1)配置递归解析器，开启递归选项，配置信任锚为根服务器的KSK；

(3.2)在递归解析器中，使用dig工具向根服务器查询顶级域NS记录，并使用sigchase选项进行DNSSEC验证。

进一步地，自证根在开源DNS软件bind中通过修改服务器端源码的方式实现解析器端的查询验证。

进一步地，在查询验证前，所述步骤(3)中根服务器并不能返回目标的胶水记录签名及其信任链的数据，因此对基于bind根服务器的源码进行修改：bind源码的数据存储形式呈现为层级式，具体为每个区文件以一个树的形式存储于bind数据库中；在每个树下，不同域的数据存储在不同节点中；其中，第一个节点代表该区的权威节点，即对这部分数据具有权威性；在查询过程中，如果目标数据存储在非权威节点中，并且目标数据不是DS记录，表明该区文件对目标数据不具有权威性，服务器不会返回目标数据；因此，为实现对服务器中目标记录的获取，修改在遍历树形数据库下的节点进行匹配的过程的源码(不对任何节点设置maybe_zonecut标记即可)，将修改后的bind重新编译，在递归解析器中使用dig+sigchase查询测试，修改后的根服务器对顶级域数据给出了完整的应答，形成了一条由根到顶级域的信任链。

进一步地，自证根在开源DNS软件bind中实现解析器端公钥钉和双重签名验证的过程如下：

(1)解析器向服务器查询顶级域公钥，与本地公钥白名单进行匹配。若本地不存在该顶级域公钥，转至步骤(2)；若本地存在该顶级域的公钥，但与当前公钥不同，转至步骤(3)；否则不做处理；

(2)对于本地白名单中新顶级域的公钥，采用首用信任的方式，将其加入本地公钥白名单；

(3)对于本地白名单中已存在的顶级域的新公钥，视为密钥更新，使用本地旧公钥对新公钥进行验证，验证成功则更新当前白名单，否则返回验证失败信息。

本发明的有益效果是：

本发明提出一个基于开源DNS软件的自证根实现方法，自证根方案是基于现有DNSSEC方案中存在的一些安全隐患进行的改进，本发明通过修改一个开源DNS软件的源码，实现了自证根方案，提高了根区胶水记录安全性。本发明方法的利用能改进现有DNSSEC方案中存在的一些安全隐患。DNSSEC中的安全隐患在于，一个域只对其中的权威数据签名，胶水记录的安全性无法得到保障。自证根方案的目标就是提供对胶水记录的签名。

本发明包含在根服务器和顶级域服务器中生成区域密钥及其对胶水记录的签名，将顶级域密钥及其对胶水记录签名发布到根服务器中替代根区原有的胶水记录，在递归解析器上向根服务器查询顶级域胶水记录并进行DNSSEC验证。自证根方案是对DNSSEC方案中胶水记录可能被篡改的安全隐患进行的改进，通过添加对根区胶水记录的签名，提高了根区胶水记录安全性。本发明通过修改一个开源DNS软件的源码，在根区中建立了一条由根到顶级域胶水记录的信任链，实现了自证根。

附图说明

附图用来提供对本发明的进一步理解，并且构成说明书的一部分，与本发明的实施方式共同用于解释本发明，并不构成对本发明的限制。在附图中：

图1为自证根实现流程图；

图2为DNSSEC验证流程图，trust anchor表示信任锚，TLD表示顶级域；

图3为数据存储形式示意图，zone table表示DNS数据库，RBT表示存储单个区域的数据库，origin node表示数据库中的权威节点，node表示非权威节点；

图4为服务器查询流程图；

图5为数据库匹配流程图；

图6是自证根方案示意图，TLD表示顶级域，GSK表示签名胶水记录的公钥。

具体实施方式

自证根方案是一个根区数据本身可自证来源真实性的安全DNS加密方案，针对现有DNSSEC方案中根区胶水记录因不提供签名机制而面临可能被篡改的隐患而提出。自证根主要包含三个设计目标：

1、胶水签名：对胶水记录添加来自顶级域权威的数字签名，令根区胶水记录来源可公开验证。

2、公钥钉：解析器采用公钥白名单或首用信任的方法来获得顶级域公钥。

3、双重签名：当顶级域密钥滚动时，新的顶级域公钥证书需要来自根权威和顶级域权威(使用旧密钥)的两个签名。

自证根方案示意图如图6所示。

自证根方案的实现流程如图1所示，在实现过程中使用的DNS服务器软件是bind9.10.3。实现步骤如下：

(1)服务器配置；(2)信任链合成；(3)查询验证；

所述步骤(1)中服务器配置的具体步骤如下：

bind提供了密钥生成工具dnssec-keygen和对区文件签名工具dnssec-signzone用于实现DNSSEC相关记录的生成。配置过程分为两步进行，因为根区文件中的顶级域DS记录需要在完成顶级域配置后才能获得。

服务器配置步骤如下：

(1.1)配置顶级域服务器

(1.2)配置根服务器

步骤(1.1)包含配置系统环境，配置顶级域区文件，配置named服务器中的options。其中，配置顶级域区文件的步骤如下：

(1.1.1)建立区文件，添加TTL记录、顶级域SOA记录、顶级域NS记录和顶级域名称服务器对应的A记录

(1.1.2)使用dnssec-keygen工具生成顶级域KSK和ZSK密钥。将生成的密钥添加到顶级域区文件中

(1.1.3)使用dnssec-signzone工具生成对顶级域区文件进行签名，生成相关记录的RRSIG和NSEC记录

步骤(1.1)中，配置named服务器中的options主要包含配置日志目录、关闭auth-nxdomain选项、关闭递归选项。

步骤(1.2)与步骤(1.1)基本一致，区别在于，区文件内容除包含根区本身的TTL记录、SOA记录、NS记录和名称服务器对应的A记录外，还需要加入顶级域NS记录和顶级域名称服务器对应的A记录，以及顶级域区文件签名成功后生成的DS记录。

所述步骤(2)中信任链合成的具体步骤如下：

(2.1)编辑根服务器区文件，添加步骤(1.1.2)中生成的顶级域信任链中的顶级域KSK、ZSK密钥

(2.2)使用dnssec-signzone工具生成对根区文件重新签名，生成顶级域NSEC记录(2.3)在签名后的根区文件中，添加步骤(1.1.3)中生成的顶级域信任链中的顶级域KSK、ZSK密钥的RRSIG记录和顶级域NS记录的RRSIG记录

所述步骤(3)中查询验证的具体步骤如下：

(3.1)配置递归解析器，开启递归选项，配置信任锚为根服务器的KSK

(3.2)在递归解析器中，使用dig工具向根服务器查询顶级域NS记录，并使用sigchase选项进行DNSSEC验证

其中，步骤(3.2)中进行DNSSEC验证的步骤如下：

(3.2.1)递归服务器向根服务器请求顶级域NS记录及其RRSIG记录，根服务器启动查询并返回相应记录。

(3.2.2)递归服务器向根服务器请求顶级域DNSKEY记录及其RRSIG记录，根服务器启动查询并返回相应记录。使用DNSKEY记录对NS签名记录真实性和完整性进行验证，若该DNSKEY能成功验证该NS记录，则返回success。

(3.2.3)递归服务器向根服务器请求顶级域DS记录及其RRSIG记录，根服务器启动查询并返回相应记录。使用DS记录对DNSKEY签名记录真实性和完整性进行验证，若该DS能成功验证该DNSKEY记录，则返回success。

(3.2.4)递归服务器向根服务器请求根DNSKEY记录及其RRSIG记录，根服务器启动查询并返回相应记录。使用该DNSKEY记录对顶级域DS签名记录真实性和完整性进行验证，若该DNSKEY能成功验证顶级域DS记录，则返回success。

(3.2.5)根DNSKEY即为递归解析器的信任锚，验证到达顶点，完成验证。

在bind中进行步骤(3.2)中的查询实验后发现，根服务器并不能返回目标的胶水记录签名数据，因此结合bind源码对其进行了修改，编译后重新进行步骤(3.2)中的查询实验，根服务器完整返回目标的NS记录，并且通过sigchase验证，如图2所示，得到一条由根到顶级域的完整信任链。

bind源码中DNS数据存储形式呈现为层级式，具体为每个区文件以一个树的形式存储于zone table中，如图3所示。在每个树下，不同域的数据存储在不同节点中。其中，第一个节点代表该区的权威节点，即对这部分数据具有权威性。在查询过程中，如果目标数据存储在非权威节点中，并且目标数据不是DS记录，表明该区文件对目标数据不具有权威性，服务器不会返回目标数据。因此，只需修改查询过程中针对数据权威性判断的逻辑，即可实现对服务器中目标记录的获取。

DNSSEC方案中不提供针对根区胶水记录的签名机制，根区胶水记录面临可能被篡改的隐患。而根服务器作为递归解析的起点，一旦其数据真实性无法得到保障，将在整个DNS系统上造成极大影响。自证根方案的目标就是提供对根区胶水记录的签名。而这违反了现有的RFC4035，各个域名服务器工具都不能支持。本发明通过修改一个开源DNS软件的源码，在根区中建立了一条由根到顶级域NS记录的信任链，实现了自证根。

实施例：为了更具体地描述本发明，下面结合具体实施方式对本发明的技术方案再进行详细说明。

自证根方案的目标就是提供对根区胶水记录的签名。而这违反了现有的RFC4035中对于胶水记录不做签名的规定，各个域名服务器工具都不能支持。本发明通过修改bind源码，在根区中建立了一条由根到顶级域NS记录的信任链，实现了自证根。

自证根方案的具体实施步骤如下：首先在根服务器和顶级域服务器中，生成区域密钥及其对胶水记录的签名；然后将顶级域密钥及其对胶水记录签名发布到根服务器中，替代根区原有的胶水记录。其中，为保证顶级域数据来自根区，以验证自证根信任链，实验中不再开启顶级域服务器；最后在递归解析器上向根服务器查询顶级域NS记录，并进行DNSSEC验证，验证成功即得到一条由根到顶级域的完整信任链。

按照上述方案实验发现，未修改的bind根服务器并不能对顶级域中的密钥和签名数据给予应答。查看内存文件可知，bind服务器能够将根区文件中的配置完整加载。因此，将原因定位在DNS数据库的存储规则上。

DNS数据库采用层级存储形式。数据库如同一个目录，存储着指向每个区结构的指针，而每个区结构也以同样的形式存储指向每个资源记录结构的指针。

DNS数据库中的分区为：在一个命名空间树中，每个区结构中存储着不同的节点，每个节点下存储着各自的资源记录数据。其中有一个最高的节点，它比任何其他节点更接近根。此节点的名称通常用于标识区结构。

值得注意的是，当NS记录位于该区结构的顶部节点时具有权威性，而区结构中位于区域切割之下的底部NS记录则不具有权威性。

在bind数据库中，一个红黑树对应的是DNS中的一个区结构，而每个树下存储着不同的节点，位置最高的节点即为起源节点，如图3所示。

DNS服务器的查询算法中，如果查询数据经过匹配发现是非权威数据，则返回一个推荐应答。发生这种情况意味着查询数据存储在一个区结构底部的节点中，该节点带有一个NS记录标记。这种情况下，应答时将子区域的NS记录复制到应答报文的权威部分。

结合源码可知，实验中查询目标的顶级域DNSKEY及NS记录位于根区底部，因此bind只返回一个包含顶级域NS记录的推荐应答。

bind采用Reactor模式多线程地处理客户端请求，具体为IO线程负责监听是否有事件发生，主线程将不同事件分发给对应的工作线程处理，工作线程负责读写数据，接收新的连接，以及处理客户请求。bind启动后，主线程在isc_app_onrun()中注册负责配置文件的解析的回调函数。在调用isc_app_run()时，回调函数会被打包成事件发送，主线程进入阻塞状态。事件被分配给对应工作线程，执行配置文件的解析与加载，完成服务器的启动。

此时在递归解析器上，对实验服务器发起查询，服务器会开始执行查询工作，流程如图4所示。其中ns__query_start()是客户端查询的起点。首先由query_setup()设置查询内容，然后通过ns__query_start()确定要搜索的权威数据库，最后调用query_lookup()进行数据库内查询的工作。

为了确定要搜索的权威数据库，ns__query_start()调用query_getzonedb()获取目标数据库。其中，query_getzonedb()搜索数据库是通过调用dns_zt_find()实现的。如果成功查询到目标数据库，将相关的区结构数据附加到查询上下文，服务器响应SUCCESS；否则退出查询。如果没有查询到目标数据库，服务器响应REFUSED或SERVFAL。对应图3中bind中的数据存储形式，dns_zt_find()的功能具体为遍历全部红黑树e，找到需要查询的权威数据库。

若查询到权威数据库，则调用query_lookup()，在数据库中查找目标记录。如果找到目标记录，调用query_gotanswer()返回数据；否则调用query_done()终止查询。其中，query_lookup()查找目标记录通过调用dns_db_findext()实现。dns_db_findext()执行数据库内记录匹配的流程如图5所示。首先对查询的数据库加锁以保证线程安全，然后通过调用dns_rbt_findnode()查询存储目标记录的节点，对应图3中bind中的数据存储形式，具体为遍历树形数据库下的节点，返回匹配的目标节点。若该节点上被设置有maybe_zonecut标记，则调用setup_delegation()返回该节点的NS记录，签名数据返回空值。否则根据目标记录的类型继续查询，对应图3中bind中的数据存储形式，具体为遍历当前节点下的各个记录，并完整返回查询结果。最后对数据库解锁，结束查询。

DNS服务器的查询算法为，查询过程中根据目标数据的类型及其存储位置，可能会设置一个NS记录标记。若查询的节点没有被标记，则根据查询的数据类型对节点中数据进行进一步匹配；对于被标记的节点，只能授权NS记录作为应答。

bind源码中标记设置条件如下：

1、当前服务器类型是stub，代表从服务器，和slave的区别是只传送NS记录，因此只返回推荐应答(NS记录)；

2、当前服务器类型不是stub，若满足以下条件，则对查询数据不具有权威性，只能返回推荐应答：

2.1、当前查询数据类型不是DS记录；

2.2、当前节点不是当前RBT下的起源节点；

2.3、当前节点的find_callback属性为真。

其中，stub的定义在bind手册中可以查到，意为只存储NS记录的从服务器。

由此可知，对于区域切割之下的带有NS记录标记的节点，如果想要获取完整的响应，只需要消除NS记录标记即可。将修改后的bind重新编译，使用dig+sigchase查询测试，实验结果符合预期，根服务器对顶级域数据给出了完整的应答，并形成了一条由根到顶级域的信任链，表达形式如下：

本发明还可有其它多种实施方式或实施例，在不背离本发明精神及其实质的情况下，本领域技术人员当可根据本发明作出各种相应的改变和变形，但这些相应的改变和变形都应属于本发明所附的权利要求的保护范围。

Claims (4)

1.一个基于开源DNS软件的自证根实现方法，所述自证根为一个根区数据本身可自证来源真实性的安全DNS加密方案，自证根主要包含三个设计目标：

一、胶水签名：对胶水记录添加来自顶级域权威的数字签名，令根区胶水记录来源可公开验证；自证根在开源DNS软件bind中实现服务器端胶水签名；

二、公钥钉：解析器采用公钥白名单或首用信任的方法来获得顶级域公钥；

三、双重签名：当顶级域密钥滚动时，新的顶级域公钥证书需要来自根权威和顶级域权威的两个签名；

水签名、公钥钉以及双重签名在开源DNS软件bind中实现的；

于，自证根在开源DNS软件bind中实现服务器端胶水签名的过程包括：

(1)服务器配置：

(1.1)先进行顶级域服务器的配置，包含配置系统环境、配置顶级域区文件、配置named服务器中的选项；其中，配置顶级域区文件的步骤如下：

(1.1.1)建立区文件，添加TTL记录、顶级域SOA记录、顶级域NS记录和对应的A记录；

(1.1.2)使用dnssec-keygen工具生成顶级域DNSKEY记录(DNSKEY记录包含KSK和ZSK密钥)，将生成的密钥添加到所述顶级域区文件中；

(1.1.3)使用dnssec-signzone工具生成对顶级域区文件进行签名，生成相关记录的RRSIG和NSEC记录，所述的相关记录包含根区的胶水记录；

(1.2)再进行根服务器的配置，因为根服务器的区文件中的顶级域DS记录需要在完成顶级域服务器配置后才能获得；

根服务器的配置包含配置系统环境、配置区文件、配置named服务器中的options；其中，区文件内容除包含根区本身的TTL记录、SOA记录、NS记录和名称服务器对应的A记录外，还需要加入顶级域NS记录和顶级域名称服务器对应的A记录，以及顶级域区文件签名成功后生成的DS记录；

(2)信任链合成，其过程为：

(2.1)建立根服务器的区文件时添加顶级域密钥；

(2.2)对根区文件进行签名后，生成顶级域NSEC记录；

(2.3)在签名后的根区文件中，添加顶级域DNSKEY记录的签名和NS记录的签名，生成一条由根到顶级域的信任链；

(3)查询验证，

在递归解析器上向根服务器查询顶级域NS记录，并进行DNSSEC验证，验证成功即得到一条由根到顶级域的完整信任链，其过程具体包括：

(3.1)配置递归解析器，开启递归选项，配置信任锚为根服务器的KSK；

(3.2)在递归解析器中，使用dig工具向根服务器查询顶级域NS记录，并使用sigchase选项进行DNSSEC验证。

2.根据权利要求1所述的一个基于开源DNS软件的自证根实现方法，其特征在于，自证根在开源DNS软件bind中通过修改服务器端源码的方式实现解析器端的查询验证。

3.根据权利要求2所述的一个基于开源DNS软件的自证根实现方法，其特征在于，在查询验证前，所述步骤(3)中根服务器并不能返回目标的胶水记录签名及其信任链的数据，因此对基于bind根服务器的源码进行修改：bind源码的数据存储形式呈现为层级式，具体为每个区文件以一个树的形式存储于bind数据库中；在每个树下，不同域的数据存储在不同节点中；其中，第一个节点代表该区的权威节点，即对这部分数据具有权威性；在查询过程中，如果目标数据存储在非权威节点中，并且目标数据不是DS记录，表明该区文件对目标数据不具有权威性，服务器不会返回目标数据；为实现对服务器中目标记录的获取，修改在遍历树形数据库下的节点进行匹配的过程的源码，将修改后的bind重新编译，在递归解析器中使用dig+sigchase查询测试，修改后的根服务器对顶级域数据给出的完整的应答，形成了一条由根到顶级域的信任链。

4.根据权利要求1、2或3所述的一个基于开源DNS软件的自证根实现方法，其特征在于，自证根在开源DNS软件bind中实现解析器端公钥钉和双重签名验证的过程如下：

(1)解析器向服务器查询顶级域公钥，与本地公钥白名单进行匹配；若本地不存在该顶级域公钥，转至步骤(2)；若本地存在该顶级域的公钥，但与当前公钥不同，转至步骤(3)；否则不作处理；

(2)对于本地白名单中新顶级域的公钥，采用首用信任的方式，将其加入本地公钥白名单；

(3)对于本地白名单中已存在的顶级域的新公钥，视为密钥更新，使用本地旧公钥对新公钥进行验证，验证成功则更新当前白名单，否则返回验证失败信息。

Images