基于IPFS的域名解析技术研究
2020-04-29刘姝言翟健宏
刘姝言， 翟健宏
(哈尔滨工业大学 计算机科学与技术学院， 哈尔滨 150001)
0 引 言
作为现代互联网的基础服务，DNS 域名系统已经发展成为当前最成功、最庞大的分布式数据系统[1]。但是传统的DNS服务器存在数据中心化，安全性差等特点。为防止DNS的单点失效等各类问题，需要对其进行大量的镜像工作。 IPFS的技术原理是将文件内容用哈希算法生成一个哈希指纹[2]，并且同一个哈希算法对相同内容只能产生唯一的指纹，这样IPFS系统中的文件就具有去重性，降低了系统的冗余度。同时，IPFS网络可以永久存储文件，某一节点中文件被删除也会在其它节点中查询到。基于此，本文将IPFS技术与DNS服务相结合，研究出一种新型、安全和高效的DNS解析服务。
1 基于IPFS设计域名解析器
1.1 IPFS概述
区别于传统HTTP协议，IPFS 是按内容查找文件。研究将一个文件放在IPFS的节点，会得到一个新名字QmYVCByHMDUSqedGkXqCC3V5Vn2nmoPo SpFQtnBuUAGc8V，这是一个由文件内容计算出的加密哈希值[3-6]。使用同一算法加密相同数据时，产生的哈希值是唯一的，并且散列的长度很短又固定，对于IPFS这种分布式网络来说，方便文件在不同节点之间存储和查询，Hash函数示意图如图1所示。当要查询一个文件时，运行着IPFS节点的计算机会询问其所有对等点是否存在这个特定哈希值的文件，拥有该文件的节点将会返回整个文件。使用哈希值在网络中传输会减少非常多的网络带宽和时延[7]。每个IPFS节点中都记录的公网ipv4地址
图1 Hash函数示意图
表1 IPFS节点属性
在IPFS网络中上传的每个文件及其所有数据块，都会根据内容返回唯一一个固定的散列字符串哈希指纹，也称为CID。当文件大小超过数据块容量大小时，会被网络分块上传[8]。上传文件的节点会维护一个该文件的块哈希列表，方便其它节点检索时通过多节点并行下载数据块，如图2所示。
图2 文件分块Hash示意图
同时每个对等节点都维护一张DHT，DHT中描述了每个对等节点拥有的数据块。DHT表数据结构为二叉树，在下载文件时只需在IPFS公网中搜索文件哈希值，便会通过DHT找到包含该文件的节点，获得完整文件。多节点都拥有文件时根据节点的信用分选择节点，从高信用分节点优先下载数据。
IPFS网络节点如图3所示，在云服务器上搭建了若干IPFS节点并且互连成对等点，对等点之间可以相互将节点信息和本节点存储的固定文件记录在自己的DHT表中，便于文件的检索和分发。整个网络都加入在IPFS公网中， IPFS网络中的节点均能互相检索到文件信息。在其中若干节点上传域名文件，在上传节点成为永久文件并返回唯一的哈希指纹，其它节点想访问该文件时只需使用此文件的哈希指纹即可查看完整文件，并将文件缓存在本地中。
图3 IPFS网络结构图
1.2 资源记录数据源
鉴于IPFS网络节点之间传输数据低时延、多备份和防篡改的特点，研究将传统DNS的根、顶级域和权威的三层树状查询结构改为根和顶级域两层结构。将资源记录直接由顶级域分类存储，简化查询次数，缩短查询所用的时间。并且将资源记录文件存在IPFS网络中可实现文件的永久保存。
在配置解析服务之前要先在IPFS网络中上传域名解析文件，在搭建的不同节点并行上传顶级域名的解析数据。DNS Server第一层文件为root_file，内容见表2，其上存储着所有顶级域名上传到IPFS网络的文件哈希值。第二层文件为top_level_file，内容见表3，其中存储着该顶级域名的所有资源记录。系统中所存域名是在Alexa网站上爬取的全球访问量前100万的域名。
表2 root_file格式
表3 DomainFile的内容格式
root_file文件需要上传全部的top_level_file文件才能生成。在节点中分别上传top_level_file，并记录IPFS网络返回的CID值。将CID与顶级域名相对应，写入另一文件中，此文件即为root_file文件。最后将root_file文件上传到IPFS网络中，返回根文件的CID。根文件CID作为查询入口，开始逐级解析。
1.3 域名解析过程
用户端在查询域名www.cnnic.cn时，先将顶级域名.cn剥离出来，在根文件中查找.cn的顶级域名文件的CID。再根据顶级域名文件的CID找到完整的顶级域名文件，从中解析出www.cnnic.cn的完整资源记录，并返回用户端A记录。
结合IPFS的设计理念，文件解析过程为在连接IPFS网络的节点客户端CLI上查询域名www. cnnic.cn，首先会从本地的blockstore中查找是否存有root_file文件，若没有则通过IPFS- API向swarm网络发送查询请求。swarm网络是由与自己节点直接相连的对等节点组成。通过DHT表查找拥有root_file的节点，根据root_file的CID找到完整root_file并返回到本地节点，本地节点先将文件缓存，系统再根据用户要查询的DNS报文www. cnnic.cn的顶级域名，在root_file中查找.cn对应的top_level_file文件的hash值。CLI重新在对等点间检索拥有top_level_file的节点，并获取完整文件，之后进行DNS解析并返回用户需要的解析信息。
用户发出一次请求的查询过程如图4所示。由图4可知，对此查询过程可做阐释分述如下。
图4 域名查询流程图
(1)用户在客户端输入待查询的域名为domain_name。
(2)客户端在其Peer节点的DHT表中查询root_file的CIDroot。
(3)从含有root_file的Peer节点下载完整的root_file文件。
(4)ipfs cat /ipfs/
(5)客户端在其Peer节点的DHT表中查询top_level_file的CIDtop。
(6)从含有top_level_file的Peer节点下载完整的top_level_file文件。
(7)ipfs cat /ipfs/
(8)查询到的IP信息返回给客户端。
(9)客户端收到DNS响应报文。
root_file的CID作为域名解析的入口，但是需要用户从其它途径获取哈希指纹，并且要确保该哈希指纹的真实性和合法性才能进行正确的解析，但现实条件下哈希指纹的真实性难以保障。因此后续研究中增加了签名验证功能。
2 签名验证
2.1 签名机制
为保证文件的真实性和可用性，研究引入一个可信第三方的概念对在IPFS网络中上传的域名解析文件进行非对称密钥签名认证。由可信的第三方为每一个顶级域名和根文件分发一对公私钥，选定秘钥算法为RSASHA256，秘钥长度keylen为2 048。
上述的两层域名解析结构是通过查询CID进行解析，尽管CID是每个文件唯一的哈希指纹已确保文件内容不会被篡改，但是无法保证CID的真实性。无法信任获得的CID所代表的文件是真实的未经篡改的域名文件，因此增加了两层签名机制，利用非对称密钥系统的身份验证功能进行签名。首先上一级文件的私钥对下一级文件进行签名，这样在拿公钥验签时可以确保下一级文件公钥的真实性和文件完整性，多级文件签名连成信任链。顶级域文件再用自己的私钥对自己的资源记录文件签名，每个顶级域名都有一对密钥对，公钥是对外公开且经过根域验证的，以此能验证此子域文件的真实性。
本文由第三方为顶级域名签发一对密钥对，由私钥对顶级域文件中的资源记录签名，由公钥验证文件的完整性。私钥由第三方安全的存储，公钥则是对外公布用于验签。顶级域公钥的真实可靠性则由其上一级根文件来确保。第三方同样为根文件签发一对非对称的密钥对，根文件私钥对文件中的内容，即每一个顶级域及其对应资源记录文件的公钥进行签名，以此保证顶级域文件的真实性。同时顶级域私钥还需将顶级域名与所对应文件CID签名，这样可保证域名与文件一一对应。由根文件公钥为验证入口的双层签名能有效地保证资源记录文件的来源真实性和文件完整性。根文件的私钥由可信第三方秘密保存，公钥则是公布在外用于验签。
从IPFS中获取全部的顶级域资源记录文件，对每一项执行2次签名操作，得到一个五元组(DomainName，DomainHash，DomainPubkey，PubkeySign，HashSign)，结构见表4。其中，DomainName为域名，DomainHash为域名在IPFS系统中对应的资源记录文件的哈希指纹，DomainPubkey为root_file的公钥，PubkeySign是为了保证顶级域名公钥真实性产生的签名，HashSign是域名保证哈希指纹真实性产生的签名。
表4 root_file文件结构
顶级域名DomainName对应的公钥为DomainPubkey，私钥为DomainPrikey。root_file的私钥RootPriley，公钥RootPubkey作为验签的入口公布在网络上。PubkeySign的形成是由root_file的私钥RootPriley对DomainName和DomainPubkey进行签名，得到签名结果PubkeySign；HashSign的形成是由DomainPrikey对域名DomainName和域名哈希指纹DomainHash进行签名，得到签名结果HashSign。私钥都是由可信第三方秘密保存的，公钥均对外公布，用于验证。
两层签名形成信任链，如图5所示。用户从可信的第三方获取根文件的CID和根文件公钥，由此开始可验证文件真实性。根据CID可以找到用RootPriley签名的root_file，用得到的根文件公钥root_pub验证根文件。验证成功后显示完整的root_file文件。
2.2 验证机制
各文件间依赖关系如图6所示。在root_file文件中，由于root_file的私钥RootPrikey对root_file文件的哈希指纹签名，因此root_pub可以对PubkeySign进行验签，进一步得到完整产生的root_file文件。再由root_file的私钥RootPriley对DomainName和DomainPubkey签名，因此root_pub可以对PubkeySign进行验签。域名私钥DomainPrikey对DomainName和DomainHash进行了签名，则域名公钥DomainPubkey可对HashSign验签。2次签名验证成功后可根据DomainHash在IPFS网络中查找top_level_file，用DomainPubkey对完整top_level_file验签，成功后显示top_level_file文件并从中获取域名解析数据。
图5 信任链
图6 文件间依赖关系
3 实验结果
为了验证该方案的可行性，本文实验从3个方面进行：只查询根文件，直接通过文件hash值从IPFS网络实现DNS解析，以及经过私钥签名后验签再进行DNS解析。
对于IPFS网络的域名解析，本文使用一个连入IPFS网络节点的客户端进行DNS报文查询。由于最初搭建节点时是从不同节点分散上传解析文件的，因此使用一个从未上传过域名解析文件的peer节点进行查询操作。在该节点上，对访问量较高的5 000个包含不同顶级域的域名进行一千余次域名解析实验，并记录每次域名解析所需时间。分别采用如下3种方式：只查询根文件、直接通过文件hash值从IPFS网络实现DNS解析，以及经过私钥签名后验签再进行DNS解析。
将3种实验所用时间画成同一张折线图，如图7所示，研究从中随机选取了sina.cn这个域名进行3种实验的时间对比。实验结果表明基于IPFS网络带签名验证机制的一次域名解析时间在1.2 s上下波动，波动范围为0.3 s。解析时间明显增加，增加的时间主要是验证签名产生的时延。带签名验证机制的IPFS域名解析需要4次验签过程：根文件公钥对根文件哈希值验签、根文件公钥对PubkeySign验签、顶级域名公钥对HashSign验签，以及顶级域名公钥对顶级域文件验签。因此解析一次域名时间明显变久。
图7 域名解析实验结果
对于直接读取根文件和不验证签名的解析结果放大后如图8所示。
图8 不进行签名验证的查询时间
测试结果表明基于IPFS网络的一次域名解析时间在0.16 s上下波动，波动范围上下约为0.03 s，对于同一域名的多次查询有时间波动，说明该波动为IPFS网络状况对域名解析造成的影响。域名解析所产生的时间主要由在IPFS上下载完整文件和对文件进行解析两部分构成。每次查询文件都需要通过IPFS网络在节点上查找本地节点是否有该文件，有文件则直接返回完整文件再进行域名解析。在IPFS网络中，即使文件在本地有缓存，但每次查询时还是会问一次IPFS节点网络，经由IPFS网络节点判断文件在本地、还是对等点。因此对于IPFS网络来说，无论文件在不在本地节点，都会访问IPFS网络，这个过程会和当时的网络情况有关。本地节点不存在，则通过DHT路由表在对等节点间查询。所有的域名解析均有以上的过程。
结果表明本系统在域名解析方面确实可行，但花费时间较多。这也是DNSSEC迄今为止仍不能完全部署的原因。区块链技术虽然安全，但读取数据所用时间代价仍然较大。
4 结束语
随着互联网规模日益增大，网络复杂度也越来越高。高度中心化的DNS系统越来越脆弱。为解决DNS的安全问题，专家学者们也都提出很多的改进方案，但大多是在现有DNS协议基础上进行修改，不能彻底解决中心化的问题。例如DNSSEC，同样基于密码学理论和算法来保证解析数据的权威性和完整性，但却带来了非常严重的性能问题。并且DNSSEC目前只在根域和二级域进行了部署，想要覆盖全部DNS系统十分困难。而本文基于分布式的IPFS技术，签名验证机制覆盖全部解析过程，所产生的时延也在可容忍范围内，可以有效解决DNS的安全问题。目前验签根文件的公钥是从某一可信第三方获得，今后工作会将IPFS网络与Fabric区块链相结合，Fabric作为可信第三方，确保根文件公钥的真实性，能够进一步解决域名解析的安全问题。
