DNS( Domain Name System)服务简介

DNS( Domain Name System)是“域名系统”的英文缩写，是一种组织成域层次结构的计算机和网络服务命名系统，使用的是UDP协议的53号端口，它用于TCP/IP网络，它所提供的服务是用来将主机名和域名转换为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所示。密钥的具体内容存放在上面的选项数据中，其中前两个字节为算法标记位，标识该密钥使用的加密算法，之后两个字节为预留的标识位，最后一部分为具体的公钥数据。具体格式如图2所示。3)密报文格式。加密的 DNS报文的头部与普通的 DNS报文保持一致，头部后一个字节为加密标记位。标记位后两个字节为加密数据的长度，最后一部分为的加密数据，具体格式如图3所示。

加密查询方法

使用 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的应答内容。

实验及分析

为测试 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所示。从实验结果来看，在密钥长度相等的情况下，基于DTLS 加密的 DNS 查询由于在建立连接的过程中密钥协商耗时较大，DNS 查询整体延时大于 DNSDEA 方法下DNS延时。在RSA加密算法下，加密强度越小，密钥越短，与 DTLS方法比较，DNSDEA性能是 DTLS方法的2.79倍(定义加速比为DTLS方法与DNSDEA时延之比，其比率越高则说明 DNSDEA 时延越低，速度越快);随着RSA密钥长度的增长到2048 Bit时，由于DNSDEA需要将客户端的密钥加密后，通过 DNS 报文传送给服务端，加密耗时明显增长，但总时延仍低于 DTLS 加密方法。使用 ECDSA 加密算法情况下，密钥长度为 112、160、256 Bit时，DNSDEA对密钥加密的开销小于DTLS密钥协商的通信开销，因此总体网络延时优于 DTLS方法，但随着加密强度增加到521Bit时，DNSDEA对密钥本身加密的开销显著增长，明显大于 DTLS密钥协商的通信开销，造成加密后的 DNS 查询时延急剧增长，在ECDSA 512下，性能低于DTLS方法。2)固定密钥长度时延对比。使用RSA算法，选取密钥长度为1024位，测试了不同长度的DNS报文在DNSDEA、DTLS方法的时延情况，实验结果如图7所示。由于 DTLS在密钥协商成功后，采用对称密钥加密数据，因此随着 DNS报文的加大，基于 DTLS 的 DNS加密方法时延增长不明显，而 DNSDEA 在 DNS 报文较大时，其传输时延明显增长。实验可以看出，在 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方法对于网络社交和大数据交换领域的改进与影响，进一步减小互联网隐私泄露风险。

以上就是良许教程网为各位朋友分享的Linu系统相关内容。想要了解更多Linux相关知识记得关注公众号“良许Linux”，或扫描下方二维码进行关注，更多干货等着你 ！