基于加密传输的标识解析模型研究

左 鹏,贺智谋,袁 梦,张海阔,杨卫平

(中国互联网络信息中心,北京 100190)

0 引 言

目前主流的标识解析技术在设计之初，并未过多考虑安全因素，其产生的数据均明文传输[1-2]，导致相关协议在运行过程中存在用户隐私泄露问题。2013年6月，斯诺登曝光了美国国家安全局的“棱镜计划”，披露了美国政府对公众用户数据的大范围监控行为，引发举世震惊[3]。标识解析系统作为互联网应用的入口服务，其解析过程中产生的数据是互联网用户隐私保护的重要环节[4]。

针对域名解析隐私保护问题，业界提出了一些基于加密传输的机制，如DoH、DoT等，这些技术标准旨在解决用户端和DNS递归服务器间数据传送的隐私保护问题，不能覆盖递归服务器和权威服务器间查询流程[5-6]。2016年，IETF发布了谷歌公司提出的RFC7871，允许递归服务器在外发查询过程中携带用户的IP地址，以获取最优的DNS应答[7]，目前谷歌公司的公共递归服务8.8.8.8已支持该标准。由于该标准将客户端的IP地址传递到了DNS权威服务器，因此DNS隐私保护问题被进一步拓展到了递归服务器和权威服务器的交互环节。

截至目前，没有成熟的技术方案支撑域名解析过程中递归服务器和权威服务器各节点间的加密传输，导致此过程中的用户数据存在隐私泄露风险。为此，本文通过充分调研国内外研究现状，并借鉴DNSSEC的信任链思想，提出一种新的基于加密传输的标识解析模型。基于该模型，从客户端到递归解析器，及递归解析器到权威服务器的每一步查询，都通过加密传输完成，保障用户隐私和数据的安全。

1 国内外研究现状

1.1 基于加密传输的DNS

针对域名隐私保护问题，2014年，国际互联网工程任务组(Internet Engineering Task Force， IETF)成立了DNS隐私传输交换工作组，发布了基于TLS和DTLS加密传输的DNS技术标准[8]。2018年，IETF发布的RFC8484定义了基于HTTPS传输的DNS。此外，丹尼尔.伯恩斯坦提出了基于椭圆曲线加密算法的DNSCurve[9-10]，使用Curve25519交换会话密钥，在缓存和服务器之间提供认证和加密。这些标准可以较好地解决客户端和递归服务器之间DNS隐私和查询劫持等问题，但都无法覆盖DNS递归服务器和DNS权威服务器之间的解析流程，且缺乏类似DNSSEC的信任传递模型，因此不能解决DNS解析全流程的隐私保护问题。

1.2 基于签名技术的DNSSEC

2005年，IETF的DNS运维工作组发布了DNS安全扩展方案DNSSEC，其基于数字签名技术实现递归解析器对DNS报文进行完整性验证和来源性验证[11-13]，主要解决类似卡明斯基攻击之类的数据篡改问题[14-15]。截至2018年底，超过90%的顶级域名已部署实施[16]。实施DNSSEC后，DNS报文仍然通过明文传输，因此DNSSEC本身无法解决DNS隐私保护问题。但其建立了权威服务器的信任链机制，实现了权威服务器各节点的信任传递，为实现全流程加密传输的标识模型提供了借鉴思路。

1.3 域名最小化查询

2016年，IETF发布RFC7816，提出了查询域名最小化的DNS查询方式[17]。普通的DNS查询中，用户查询的域名全名将暴露给查询过程中经过的所有权威服务器，容易产生隐私泄露问题。DNS查询最小化遵循发送的数据越少，隐私问题就越少的原则[18]，仅向较高级的权威服务器暴露部分域名，从而提升了DNS查询过程中的私密性。在查询域名最小化中，递归服务器和较低级的权威服务器依然能获取到用户所请求的域名全名，同时递归服务器仍能记录用户所有访问记录，查询域名最小化只能提供较为有限的隐私保护。

1.4 域名广播技术

域名广播技术由Federrath等人[19]于2011年提出，主要是将近一段时间内查询量比较大的域名广播到用户机器上。递归服务器由于参与到了广播的过程中，不再直接获取用户的访问记录，因此可缓解用户隐私泄露问题。同时，由于热门域名被缓存在用户的机器上，域名广播技术能较大程度地提升用户的访问速度。域名广播技术的问题在于对现有的DNS解析架构改动较大，同时需要在用户的机器上占用大量空间，部署难度较大。

2 基于加密传输的标识解析模型

2.1 模型总体架构

本文提出一种新的基于加密传输的全流程标识解析模型，借鉴DNSSEC的思想，并使用加密连接的身份认证机制实现权威节点的身份认证和信任传递，实现递归服务器和权威服务器间查询隐私保护。总体架构如图1所示，分为安全套接层、传输层和应用层，其核心在于应用层实现基于加密传输的信任链和节点信任传递，将在2.2节详细描述。其中，安全套接层采用SSL协议，为上层提供加密功能。传输层作为数据传输的管道，采用TCP或HTTP等协议实现。应用层由桩解析器、递归解析器和权威解析器组成，实现基于加密传输的标识解析功能。

图1 系统总体架构

模型的信任链部分借鉴了DNSSEC信任链的思想，但技术原理和目标问题不同。从技术原理上讲，DNSSEC通过电子签名实现信任传递。具体地，各节点掌握一对或多对非对称密钥，使用私钥对各自数据签名，并提供公钥给递归服务器用于数据验证。其中，子节点将公钥的摘要提交至父节点，父节点对其签名。递归解析器通过验证该公钥的摘要并与子节点的公钥进行比对，从而验证子节点的身份。由此类推，实现各节点身份认证传递。本文模型通过加密连接确保数据的隐私性。加密连接建立的过程中，通信双方首先验证对方的身份，之后通过协商机制选择加密传输所使用的密钥。在上述过程中，通信双方的身份通过非对称加密进行验证，非对称加密同时确保了密钥协商过程的私密性和可靠性，即使攻击者对通信进行拦截，也无法获取密钥协商期间的具体内容或对其进行篡改[20-21]。从目标问题上看，DNSSEC主要解决递归服务器解析过程中数据被篡改的问题。本文模型主要解决解析全流程的用户隐私保护问题。

2.2 信任链建立

本文模型信任链通过加密连接过程中的身份认证和加密传输实现。具体地，递归解析器首先与根节点建立加密连接，在此过程中，递归解析器根据根节点发布的证书对其身份进行验证。一旦连接建立成功，则根节点身份认证通过，之后递归解析器向根节点查询一级节点的证书信息。由于全程加密传输，可保证该证书来自于根节点且无法被篡改。在获取到一级节点证书后，递归解析器尝试使用该证书和一级节点建立加密连接，一旦连接建立成功，则一级节点身份得到认证，并继续向一级节点查询二级节点证书信息。由此，通过加密连接的身份认证和加密传输下级节点的证书实现权威解析器各级节点的身份认证。DNSSEC信任链与本文模型信任链如图2所示。

图2 DNSSEC信任链与本文模型信任链

对比DNSSEC和本文模型，DNSSEC的优势在于可实现数据来源性验证，即经过DNSSEC签名后的数据，传输链路上无论经过何种方式传输，链路上的任何一方都不需要掌握签名者的私钥，最终接收方都可以验证该数据来自于签名者。因此，实际应用中，域名拥有者可以对自有数据签名，再将域名托管至第三方运营，方便签名业务和解析托管业务分离。但DNSSEC的主要局限在于无法实现用户的隐私保护，由于其使用电子签名技术，经过DNSSEC签名后的报文仍然明文传输，第三方可以获取用户数据并窥探用户隐私。此外，DNSSEC无法覆盖用户端和递归解析器间的链路，存在“最后一公里”问题[22]。本文模型的优势在于实现了标识解析所有流程的加密传输，因此可实现全流程的用户隐私保护。此外，由于数据加密传输，也保障了数据无法篡改。但其局限在于无法实现数据来源验证，域名拥有者若需托管域名到第三方，则第三方需要掌握域名拥有者用于加密连接的私钥。因此，实际应用中，若域名拥有者和域名托管第三方存在信任风险，可采用DNSSEC和本模型结合的方式，同时实现数据来源性验证和用户隐私保护。

2.3 系统工作流程

本文模型通过建立信任链，实现标识解析过程中全流程加密传输。递归解析器和根节点的公钥通过带外方式发布，分别配置到桩解析器和递归解析器。假设递归解析器无缓存数据，解析数据存储于二级节点。一次典型的标识解析流程如图3所示。

图3 系统工作流程

系统工作流程具体描述如下：

1)桩解析器使用递归解析器的公钥与其建立加密连接，并发送查询请求。

2)递归解析器使用根节点的公钥与其建立加密连接，并发送查询请求。

3)根节点返回一级节点的服务地址和公钥给递归解析器。

4)递归解析器使用一级节点的公钥与其建立加密连接，并发送查询请求。

5)一级节点返回二级节点的服务地址和公钥给递归解析器。

6)递归解析器使用二级节点的公钥与其建立加密连接，并发送查询请求。

7)二级节点返回查询应答结果给递归解析器。

8)递归解析器返回查询应答结果给桩解析器。

2.4 与现有安全模型对比分析

目前，域名领域主要的安全模型有基于签名技术的DNSSEC以及基于加密技术的DoT、DoH等。其中DNSSEC通过数字签名实施来源性验证，通过数字摘要连接父子节点信任链，可保障递归解析器和权威解析器间的数据安全。但部署DNSSEC后，数据仍然明文传输，无法解决隐私保护问题。DoT等安全模型通过桩解析器和递归解析器的加密传输解决用户端和递归解析器链路上的DNS劫持问题，但无法实现各权威节点的信任传递，因此不能覆盖标识解析全流程。本文模型基于加密传输技术，通过加密过程的身份认证实现权威节点的信任传递，可实现标识解析全流程加密传输，保障用户隐私和数据完整性。各模型具体对比如表1所示。

表1 各安全模型技术对比

3 实验与分析

3.1 实验方法

为测试不同加密算法、密钥长度、传输数据量等因素对加密传输下解析性能的影响及实际可用性，共设计了5组实验。基本思路为基于不同的传输协议和加密方法，在客户端与服务端之间建立加密连接，并发送一定量的数据，计算平均解析时延和服务端CPU使用率并进行安全性分析。

实验基于TLS协议对RSA和EC这2种加密算法进行测试。其中，RSA算法测试的密钥长度分别为512 bit、1024 bit和2048 bit(以下简称RSA512、RSA1024和RSA2048)，EC算法测试的密钥长度分别为160 bit、256 bit和384 bit(以下简称EC160、EC256和EC384)。实验中密钥对由JDK中的keytool工具生成，客户端和服务端均为Java程序，JDK版本为JDK1.7.0_80。服务端和客户端均运行在CentOS release 6.5操作系统上。

3.2 实验结果与分析

3.2.1 不同加密算法和密钥长度下解析时延测试(实验1)

本组实验基于TLS协议，使用不同加密算法和密钥长度，以复用连接和不复用连接的方式与服务端进行5000次通信，计算平均时延。不同加密算法和密钥长度下基于TLS的平均时延如图4所示。

图4 不同加密算法和密钥长度下基于TLS的平均时延

图4结果显示，不复用连接时，平均时延在11.48 ms～21.55 ms之间，复用连接时，平均解析时延显著降低，相较于不复用连接，下降约98.5%。复用连接情况下，由于连接初始化过程会产生2次RTT(Round-Trip Time)的时延，因此复用连接可以明显降低时延。此外，握手过程中使用指定的非对称密钥进行密钥协商，因此解析时延与算法复杂度和密钥长度呈正相关。复用连接时，由于连接建立后双方采用对称加密进行通信，因此握手过程中使用不同的加密算法和密钥长度对解析时延影响不明显。

3.2.2 不同响应包大小下解析时延测试(实验2)

本组实验基于TLS协议，分别使用100 B、500 B、1 kB、10 kB和70 kB的报文，以复用连接和不复用连接的方式进行5000次通信，计算平均时延。其中，加密连接使用RSA算法，密钥长度为1024 bit。不同大小报文基于TLS的平均时延如图5所示。

图5 不同大小报文基于TLS的平均时延

与实验1类似，复用连接相较于不复用连接，解析时延显著降低，平均约下降95.8%。总体上，解析时延与报文大小呈正相关。当报文在10 kB及以下时，报文大小对解析时延影响不明显，其中复用连接时，平均时延约为0.3 ms，不复用连接时平均时延约为10.46 ms。当报文增长到70 kB时，解析时延出现明显增长，相较与10 kB报文，复用连接情况下时延增加约161%，不复用连接情况下时延增加约40%。由此可看出，当响应包在70 kB以内时，TLS建立连接消耗的时间远大于连接建立后数据加密传输的时间。

3.2.3 加密传输下服务端CPU使用率测试(实验3)

本组实验测试了基于TCP协议和TLS协议通信时，服务端CPU使用率的变化情况，测试结果见图6，图中横坐标为采集CPU使用率的时间点，t为连接建立后采集的第一份CPU使用率数据。

图6 TCP和TLS协议对服务端CPU的占用率

图6结果显示，无论是否采用加密连接，服务端的CPU使用率在连接建立时(t时刻)均有显著增加，其中，TLS加密连接达到约24%，TCP非加密连接达到约17%，TLS加密连接相比TCP非加密连接CPU使用率提高约41%。在连接建立后(t时刻后)，TLS传输的CPU平均使用率约为13%，TCP传输的CPU平均使用率约为8%，TLS加密传输相比TCP非加密传输CPU使用率提高约63%。因此，加密连接传输相较于非加密连接传输将占用更高的CPU资源，实际环境中，若大量加密连接并发而造成资源不足，可通过拒绝接受新的加密连接或对部分用户支持加密连接的方式以节省资源，保障解析服务正常运行。

3.2.4 现网环境下DNS查询时延和报文大小测试(实验4)

为分析本文模型在实际场景下的可用性，本组实验测试了现网环境下DNS解析时延及报文大小。其中DNS查询的解析时延，通过向1.2.4.8、8.8.8.8、114.114.114.114这3个公共递归服务查询Alexa网站上排名前五的中国网站域名各5000次并计算平均时延得到，DNS报文大小通过向DNS根服务器、.com和.baidu.com的权威服务查询各自域名的A记录、NS记录和DNSKEY记录得到。

表2 现网环境DNS递归服务查询时延 单位:ms

从表2可以看出，目前主流的公共递归服务平均解析时延均在100 ms以内。其中，由于测试机到1.2.4.8的路由跳数最少，时延最小，为2 ms以内。到8.8.8.8的时延最大，约50 ms～90 ms之间。到114.114.114.114的时延在两者之间，约16 ms。

表3 现网环境DNS报文大小情况 单位:B

表3结果显示，现网环境大部分DNS报文大小都在1 kB以下。其中，最大的DNS报文是根NS记录的DNSSEC查询，非DNSSEC查询时，常见的A记录、NS记录的DNS报文大小一般在200 B以内。

结合前3组实验情况，并以114.114.114.114解析结果为例，在解析时延方面，采用TLS复用连接方式时延约提升1.8%，不复用连接时延将提升95%。因此，为降低加密传输带来的时延提升，在实际应用中，应尽可能复用已建立的链接，降低加密传输所带来的时延和服务器的处理压力，RFC1035也建议服务端在连接空闲2分钟以上后再将连接关闭。同时，客户端应该将连接数量最小化，通过复用一个活跃的加密连接，在客户端和服务端之间进行多次通信，以有效降低时延[23]。

在报文大小方面，实验2结果显示，当报文在10 kB以下时，解析时延变化不明显，以TLS为例，复用连接时，时延增加约0.3 ms。目前现网环境DNS报文大小大部分小于1 kB，因此该因素对解析时延无显著影响。

3.2.5 模型安全性分析(实验5)

本组实验通过搭建2级权威节点解析器(10.192.195.17和10.192.195.21)及递归解析器(218.241.111.162)，对模型信任传递机制的安全性进行验证和分析。结果如图7和图8所示，从图中结果可知，递归解析器从初始状态开始，通过查询学习到各级权威节点的证书信息，实现信任传递，并全程通过加密方式传送数据，保障了数据的私密性和完整性。

图7 根服务器与下级节点的信任传递过程

图8 本文模型下加密传输的解析结果

本文模型依赖加密连接过程的身份认证来实现信任传递，因此保障证书的安全非常关键。在证书发布方面，由于递归服务器和根服务器分别是用户和递归服务器的查询起点，因此它们的证书需通过带外方式发布。实际应用中，可采用加密传输、官方发布等类似DNS根区发布密钥的方式，保障查询起点的安全。在证书密钥方面，由于现代计算机计算能力不断增强，为防止密钥被暴力破解，参考DNSSEC相关部署经验，推荐使用的RSA密钥长度应不低于1024 bit，EC密钥长度应不低于160 bit，同时应定期更换密钥，保障密钥安全。

4 结束语

本文提出的基于加密通信的标识解析模型，实现了标识系统各节点在加密方式下的信任传递，保障了标识解析全流程下用户隐私，同时由于数据加密传输，防止了数据被篡改，保障了数据传输安全。与现有的技术相比，本文模型具有一定的技术优势，但也存在一定的局限。与DNSSEC不同，本文设计的模型依赖标识解析服务提供方的信任传递，由于缺乏数字签名，不能实现类似DNSSEC的来源性验证。对于实际应用较复杂的场景，如标识拥有方与解析服务提供商存在信任风险时，可采用数字签名与本文模型结合的方式，进一步加强数据安全的保护。同时，由于全流程加密传输，对于网络流量监测分析、恶意流量监管等也提出了新的挑战，需要进一步研究。