基于隐私保护技术的DNS通信协议( 二 ) _DNS

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