域名系统（DNS）是互联网基础服务，是互联网访问的重要入口，域名隐私保护是 DNS安全的研究热点。本文提出了一种基于用户数据报协议的DNS传输中用户隐私保护的加密方法：DNSDEA。该方法采用PKI加密体系与DNS协议相融合，不仅解决了域名隐私保护问题，而且与传统DNS体系相兼容，保持了DNS系统的简单、高效的技术特点。
域名系统（domain name system，DNS）是互联网的重要基础服务之一，主要通过域名和互联网协议地址（IP）等互联网基础资源之间的映射与转换，实现标识和定位互联网上服务器和服务入口。DNS是一个相对成熟的全球性分布式数据库，为互联网提供高效稳定的互联网标识解析服务。
1983 年，Mockapetris提出 DNS 架构，随后该构架在不断地持续演进和优化。在设计之初，域名系统在域名协议方面并没有考虑完备的安全机制。1999年，DNS安全扩展协议（domain name system security extensions，DNSSEC）被提出，其能够有效降低中间人攻击的风险，保证 DNS传输数据的完整性，从而提升 DNS系统的安全服务能力。2010年，互联网域名的根服务开始部署 DNSSEC服务，标志着域名服务开始向安全服务方向迈进，DNS 也从一个简单的名址转换服务向复杂的、可信的解析服务发展，传输层安全协议DANE（DNS-based authentication of named entities）就是基于 DNSSEC协议将数字证书通过 DNS服务进行发布，以确保证书来自特定的证书颁发机构。
随着互联网普及率的不断提高及其对生产生活的不断渗透，人们已经对互联网产生了越来越强的依赖性，当前的互联网已不仅是获取和分享信息的途径，而且已成为大多数传统行业业务系统的基础载体，因此隐私问题已经成为互联网亟待解决的一个重要问题。DNS 主要采用用户数据报协议（user datagram protocol，UDP）协议明文传输方式进行名址转换，虽然DNSSEC协议提升了数据篡改难度，但是依然采用明文方式提供解析服务。作为互联网基础服务，DNS 对于用户隐私保护依然表现出了脆弱性。目前 DNS 有关安全的命题被真正解决得还较少，而其中的隐私问题也已成为行业关注的焦点问题并逐渐得到重视。一方面，行业内采用查询最小化（query minimization）方法降低隐私窃取风险，使用数据最小化（data minimization）原理减少 DNS权威服务收集个人隐私信息；另一方面，针对 DNS 解析服务过程中隐私泄露的问题，国际组织Internet Engineering Task Force（IETF）于 2014年专门成立 The DNS PRIVate Exchange（DPRIVE）工作组讨论并制定 DNS 隐私保护协议，希望采用数据加密传输的方式实现 DNS隐私保护。基于此背景，本文提出一种基于UDP的DNS传输中用户隐私保护的加密方法。
研究现状
当前，绝大多数 DNS 服务和终端之间的数据交换（主要包含请求和反馈）采用明文、非加密的方式进行，这将导致用户隐私暴露在互联网通信中，其隐私方面的脆弱性将会被黑客所利用，例如黑客可以收集用户的访问痕迹（查询时间、访问内容、用户IP地址等）等信息分析用户习惯等。针对这个问题，目前主要有以下两种方法保护DNS查询过程中的用户隐私。
DNS数据报文加密
Dempsky 提出了 DNSCurve 方法，该方法基于现有 DNS 体系架构，使用Curve25519 在客户端和服务器端交换密钥以及提供认证和数据加密。服务端的公钥存放在“NS”记录中发送给客户端，因此使用 DNSCurve加密DNS报文并不会带来额外查询延迟。DNSCrypt是DNSCurve比较有名的一个实现，已在 OpenDNS的服务上得到广泛部署，用来解决终端用户的隐私保护问题。类似的ConfidentialDNS也使用了 DNS的扩展机制为 DNS协议增加加密功能。它提出一种新的资源记录类型“ENCRYPT”来传送 DNS服务器的公钥到客户端。然后客户端使用服务器公钥加密 DNS 查询请求，以及用来加密 DNS响应的客户端公钥，从而实现对 DNS请求和反馈数据进行加密保护。这两种方案虽然能有效解决 DNS 明文传输所带来的脆弱性问题，但是需要在DNS通信两端都部署安装插件（或升级解析软件）实现DNS通信从明文到密文的目标，推广成本较大，所以目前使用并不广泛。
DNS通信链路加密
TLS（transport layer security）是一种为网络通信提供数据保密以及完整性的安全协议，它在传输层对网络连接进行加密。目前 TLS 最常见的一种应用是HTTPS协议，它使用公钥加密对网站进行认证，同时使用对称加密对数据传输进行加密。TLS需要 TCP协议来保证信道的可靠传输，不能直接用来加密保护 UDP协议的数据，如果 DNS希望使用 TLS加密保护数据，就必须使用 TCP协议。然而现状是绝大部分的 DNS查询使用 UDP协议，切换为 TCP协议是一个长期的过程，并且代价巨大。因此，就现阶段来说，DNS-over-TLS并不是一个可行的隐私保护方案。
DTLS（datagram transport layer security）数据包传输层安全协议是在TLS架构上提出的一种扩展，能够支持 UDP 协议。DTLS 使得直接加密 UDP 协议的 DNS 查询报文变得可行。IETF草案提出的DNS-over-DTLS详细描述了如何使用DTLS技术加密DNS报文。
DNS-over-TLS 和 DNS-over-DTLS 使用互联网标准协议 TLS 和 DTLS 来实现 DNS 密文通信。这两种方法都是采用 TLS 协议进行 DNS 改进，但该方法需要在通信之前需要建立握手、认证等一系列复杂网络通信才能实现，对于访问量巨大、开销相对较小的 DNS服务提出了较高的网络开销和性能要求。
上述两种方法对于延迟敏感、高吞吐量的互联网基础服务DNS来说，都带来了较大挑战。
DNS密文通信方法
提出了一种新的 DNS加密通信方法DNSDEA（DNS data encryption algorithm），该方法在现有 DNS架构和报文格式下采用非对称加密算法的密文方式通信。通过DNS查询传输客户端的公钥，以降低基于TLS等方法建立链接的开销，减低查询延时。同时，利用其无状态特性提高服务端的并发性。
报文结构
1）加密标记位。为标记一个 DNS 报文是否为加密报文，将 DNS 报文头部后的第一个字节定位为加密标记位。对于一个正常的未加密 DNS 报文，该字节表示查询域名第一段的长度，按照互联网协议标准（request for comments，RFC），长度应小于 64。将该字节拓展为加密标记位，若该字节小于 64，表示 DNS报文为非加密报文，若大于64，表示该报文为加密报文。
2）密钥格式。DNSDEA 采用非对称加密方法，在 DNS 终端和DNS 服务端分别独立生成通信密钥对（含公钥和私钥）。DNS 服务端的公钥通过现有的证书颁发架构（certificate authority infrastructure）发布，使用该 DNS 服务端的客户需手动配置该公钥。DNS客户端使用的密钥在查询过冲中临时生成。考虑到查询效率等因素，DNS客户端密钥在一段时间内可重复使用。
客户端的公钥由客户端在DNS 报文的附加段以EDNS0 格式添加，通过 DNS 查询发送给 DNS 服务端。具体格式如图1所示。
图1 EDNS0格式传输PKI公钥密钥
密钥的具体内容存放在上面的选项数据中，其中前两个字节为算法标记位，标识该密钥使用的加密算法，之后两个字节为预留的标识位，最后一部分为具体的公钥数据。具体格式如图2所示。
图2 密钥格式
3）密报文格式。加密的 DNS报文的头部与普通的 DNS报文保持一致，头部后一个字节为加密标记位。标记位后两个字节为加密数据的长度，最后一部分为的加密数据，具体格式如图3所示。
图3 加密后的DNS报文格式
加密查询方法
使用 DNSDEA 方法时，DNS 终端需要手动配置DNS服务端的公钥。服务端的公钥可通过 PKI体系进行验证。在 DNS终端向 DNS服务端发送查询请求时，使用 DNS 服务端的公钥对请求资源记录（RRset）进行加密，将DNS终端的公钥制作成RRset并使用DNS服务端的公钥将其加密，生成 DNS 报文格式数据，传输给DNS服务端。
DNS 终端将按照 DNS 协议要求，将生成的 DNS 查询报文发送给 DNS 服务端，DNS 服务端使用自身私钥进行解密还原待查询的域名记录和 DNS终端的公钥信息，按照 DNS查询逻辑寻找查询结果，使用还原出来的DNS终端公钥对查询结果进行加密，发送给DNS终端。
DNS 终端接收到应答报文后，使用其私钥信息将应答报文的应答资源记录（RRset）进行解密，并按照DNS协议进行处理。
具体流程如图 4所示。以 www.example.com查询为例，实现加密查询方法，主要分以下步骤：（1）服务端通过 PKI发布公钥，客户端手动配置服务端公钥；（2）客户端生成密钥对；（3）客户端构造 www.example.com 的查询包，将客户端的公钥添加在查询包的附加段，并用服务端公钥加密后，将查询包发送给服务端；（4）服务端收到加密的查询包，使用服务端私钥解密，获取 DNS查询内容和客户端公钥；（5）服务端构造 www.example.com的应答包，并用客户端的公钥加密后，将应答包发送给客户端；（6）客户端收到加密的应答包，使用客户端私钥解密，获得www.example.com的应答内容。
图4 加密DNS查询流程
实验及分析
为测试 DNSDEA 的可行性，进行了相关实验，对DNSDEA 和基于 TLS、DTLS 加密方法的 DNS 查询进行对比，以验证DNSDEA 的可行性及相对于目前较流行加密方法的低延迟优势。
实验方法
由于 DNS 查询主要通过 UDP 传输，因此实验主要关注 DNSDEA 和基于 DTLS 加密方法下 DNS 查询包延迟。实验分别测试了两种加密方法使用RSA和ECC算法情况下不同大小数据包的性能表现，通过发起多次DNS查询取平均值，计算各方法下DNS查询时延，比较两种方法在DNS加密使用上的特点。
实验使用openssl-0.9.8 和crypto++5.6.5 加密库实现 RSA和 ECDSA加密，通过编程模拟了两种加密方法下DNS服务端和客户端的软件行为。客户端DNS查询均通过脚本定时循环调用实现，因此基于 DTLS加密的查询每次触发新的 DTLS连接，未使用历史会话。实验运行环境为CentOS 5.7，服务端和客户端分别部署在北京同城的不同节点。
实验结果与分析
1）固定通信字节时延对比。采用10 Bit的通信数据，利用不同强度的密钥进行测试，实验结果如图5所示。
图5 两种DNS加密方法时延比较
从实验结果来看，在密钥长度相等的情况下，基于DTLS 加密的 DNS 查询由于在建立连接的过程中密钥协商耗时较大，DNS 查询整体延时大于 DNSDEA 方法下DNS延时。在RSA加密算法下，加密强度越小，密钥越短，与 DTLS方法比较，DNSDEA性能是 DTLS方法的2.79倍（定义加速比为DTLS方法与DNSDEA时延之比，其比率越高则说明 DNSDEA 时延越低，速度越快）；随着RSA密钥长度的增长到2048 Bit时，由于DNSDEA需要将客户端的密钥加密后，通过 DNS 报文传送给服务端，加密耗时明显增长，但总时延仍低于 DTLS 加密方法（图6（a））。
图6 ECDSA算法下两种DNS加密方法加速比
使用 ECDSA 加密算法情况下，密钥长度为 112、160、256 Bit时，DNSDEA对密钥加密的开销小于DTLS密钥协商的通信开销，因此总体网络延时优于 DTLS方法，但随着加密强度增加到521Bit时，DNSDEA对密钥本身加密的开销显著增长，明显大于 DTLS密钥协商的通信开销，造成加密后的 DNS 查询时延急剧增长，在ECDSA 512下，性能低于DTLS方法（图6（b））。
2）固定密钥长度时延对比。使用RSA算法，选取密钥长度为1024位，测试了不同长度的DNS报文在DNSDEA、DTLS方法的时延情况，实验结果如图7所示。
图7 RSA在1024位密钥长度下的时延对比
由于 DTLS在密钥协商成功后，采用对称密钥加密数据，因此随着 DNS报文的加大，基于 DTLS 的 DNS加密方法时延增长不明显，而 DNSDEA 在 DNS 报文较大时，其传输时延明显增长（图8）。
图8 1024位密钥长度下DTLS与DNSDEA的加速比
实验可以看出，在 1024 位密钥加密条件下，采用DNSDEA 传输时延整体明显低于基于 DTLS 的 DNS 加密方法。
综上所述，在密钥长度和传输报文较小时，DNSDEA时延明显低于 DTLS方法；基于 DTLS加密的方法，由于在连接建立后，双方采用对称密钥加密，其耗时的增长幅度要小于 DNSDEA；由于多数 DNS 报文的大小一般都在 200Byte 以内，因此相较于 DTLS 方法，DNSDEA 可以明显降低 DNS 加密传输时延。此外，DNSDEA 基于 DNS传输，其无状态的特性也可以明显提升服务端的并发性。
随着互联网个人隐私问题得到更多人的关注，DNS隐私泄露问题将会越发突出。针对 DNS个人隐私问题的现有技术进行分析，在现有技术解决方法基础上提出了一种新的DNS加密通信方法：DNSDEA。与传统方法相比，该方法在现有 DNS 架构和报文格式下采用非对称加密算法的密文方式通信，不仅完成了 DNS 个人隐私保护，而且提升了域名解析核心算法的并行粒度，降低了 DNS终端与 DNS服务端之间的通信开销，有效保持了DNS低延迟的特性。
针对 RSA、椭圆加密算法（ECC）等加密算法进行了实验，以期为后续通信加密应用研究和 DNS 安全解析并行化研究提供一定参考，并且深入探索 DNSDEA 方法针对 DNSSEC TLSA协议的扩展，提升加密通信安全水平。后续将深入研究 DNSDEA方法对于网络社交和大数据交换领域的改进与影响，进一步减小互联网隐私泄露风险。
参考文献（略）
作者简介
本文作者：张海阔，陆忠华，陈闻宇，陈连栋，左鹏，王珏，徐彦之
作者简介：张海阔，中国科学院计算机网络信息中心，中国科学院大学，中国互联网络信息中心，博士研究生，研究方向为计算机系统结构；陈闻宇（通信作者），中国科学院计算机网络信息中心，中国科学院大学，中国互联网络信息中心，高级工程师，研究方向为计算机系统结构。
注：本文发表于《科技导报》2019 年第8期，有删节。
声明：本文来自科技导报，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
