DNSSEC？禁止套娃！

最新推荐文章于 2024-09-01 16:14:54 发布

飞翔的红猪

最新推荐文章于 2024-09-01 16:14:54 发布

阅读量770

点赞数 6

文章标签： dnssec

本文链接：https://blog.csdn.net/WangWeb1998/article/details/114534117

版权

DNSSEC通过添加加密签名确保DNS解析的安全性，涉及ZSK和KSK密钥对以及DS记录。ZSK用于对DNS记录签名，KSK则对ZSK签名，DS记录在上一级服务器中验证KSK公钥。整个过程形成一个信任链，从根服务器开始，确保数据完整性和来源认证。

摘要由CSDN通过智能技术生成

简介

DNSSEC是DNS安全拓展，主要思想是通过在DNS记录中添加加密签名，从而为DNS解析流程提供来源可认证和数据完整性的保障。

本文的目的是帮助大家大致理解DNSSEC的工作流程

建议读者先掌握以下知识点再来阅读本文：

DNS解析流程
对数字签名有一个基本了解

ZSK and KSK？

在介绍DNSSEC之前，有必要先介绍一下区域签名密钥(ZSK)和密钥签名密钥(KSK)，此处只需要大家对这俩名词有一个简单的认识，当然了，这俩东西都是密钥对，也就是既有私钥也有公钥。

区域签名密钥ZSK：

假设现在有一个权威名称服务器A，

在这里插入图片描述

A会对服务器中的每个RRset（DNS资源记录集合，也就是说A类型的所有DNS记录看作一个集合、AAAA类型的所有DNS记录看作一个集合…等等）用ZSK私钥生成对应的数字签名，这些数字签名叫做RRSig记录，存储在服务器中。同时，A还会记录ZSK公钥，这种记录叫做DNSKEY，目的是为了以后请求方能够从服务器中获取公钥，进行签名验证。

在这里插入图片描述

因此，到目前为止，DNS解析流程似乎变成了以下这样：

当接收方B（通常是递归解析器）向权威名称服务器A请求特定域名对应的IP地址时，A将对应的DNS记录返回给接收方B，同时还会返回对应的RRSig（数字签名）。
B收到DNS响应时，就需要根据RRSig来判断这条DNS响应是否是权威名称服务器A发出的。这个时候，B需要向A请求ZSK公钥，紧接着A就会返回给B记录了ZSK公钥的DNSKEY。
B收到ZSK公钥后，就可以验证该签名是否是属于A了。

上述过程有问题吗？肯定是有的，既然普通的DNS流量可能存在被篡改或者是仿造的风险，那么B收到的DNSKEY记录就不存在这样的问题吗？因此，我们需要来认识下一个密钥。

密钥签名密钥KSK：

除了对不同类型的RRset进行加密签名以外，服务器A还会对记录ZSK公钥的DNSKEY记录进行加密签名，此处所用到的就是KSK私钥，加密签名后所生成的数字签名也叫做RRSig记录，同样地，为了请求方能够进行签名验证，服务器A同样会将KSK公钥存储在服务器中，形成另一个DNSKEY记录。因此，到目前为止，A中一共有两个DNSKEY记录，一个记录了ZSK公钥，另一个记录了KSK公钥。其中，记录着ZSK公钥的DNSKEY记录还有对应的RRSig记录。

那么，DNS解析流程应该又变成这样了：

（与上面相同）
B收到响应后，再向A请求ZSK公钥，紧接着，A返回给B记录了ZSK公钥的DNSKEY记录，以及对应的RRSig。
B收到包含了ZSK公钥的DNSKEY记录以及RRSig后，为了验证这个数字签名（这个数字签名是由KSK私钥生成的），需要向A请求KSK公钥。因此，A会返回给B记录了KSK公钥的DNSKEY记录。
B根据收到的KSK公钥就可以验证包含着ZSK公钥的DNSKEY记录的有效性，如果是正确的，那么可以用ZSK公钥去验证第1步中收到的DNS响应的有效性。

在这里插入图片描述

这个过程有问题吗？当然！就和上面那个一样，如何去保证B收到的包含KSK公钥的DNSKEY记录是正确的呢？难道再引入一个密钥吗？？？哈哈，本文禁止套娃！为了解决这个问题，我们一起来看下一个知识点。

签名委派者记录DS

为了能够帮助接收方验证所拿到的KSK公钥是否是正确的，DNSSEC引入了DS记录。通过对包含KSK公钥的DNSKEY记录进行哈希处理，将得到的值记录在上一级服务器当中，这种记录就叫做DS记录。因此，利用DS记录，B就可以判断收到的KSK公钥是否是正确的。

DNS解析流程就成了这样：（1.2.3.步均与上面相同）

B收到包含KSK公钥的DNSKEY记录后，向服务器A的上一级服务器进行查询（比如：C），C收到B的请求后将服务器A对应的DS记录返回给B。
B收到DS记录后，可以同样对KSK公钥进行哈希，比较这两个值是否匹配。

因此，通过ZSK、KSK以及DS，B如果要判断来自A的响应是否正确（是否被伪造、篡改等等），最终是需要向A的父区域C进行查询的，也就是说B对A的信任是由C决定的。

你以为这样就结束了吗…当然没有，既然B对A的信任是由C决定的，那么B就一定可以相信C吗？换句话说，B收到的C发来的DS记录会不会被篡改伪造？那么，为了解决这个问题，采用的方法和上面是类似的，C同样会用自己的ZSK私钥对DS记录进行加密签名，然后发送给B。B收到以后，就向C请求ZSK公钥。然后C发送给B一个包含ZSK公钥的DNSKEY记录以及对应的数字签名（这个数字签名是由C的KSK私钥加密的），然后B再向C请求它的KSK公钥，为了判断收到的公钥是否正确，B再向C的父区域（比如：D）请求DS记录…（这就是套娃呀！！）

最后，B会一直查询到根服务器，根服务器当然也有它自己的KSK公钥，那B接下来怎么办呢？套娃也套不了了呀，这都到头了…别慌，请看下面的“根区域签名仪式”。

在“根区域签名仪式”上，来自世界各地的特定几人以公开且经严格审核的方式签署根 DNSKEY RRset。这次仪式会产生一个 RRSIG 记录，该记录可用于验证根名称服务器的公共 KSK 和 ZSK。

至此，相信大家应该理解了DNSSEC信任链的概念，请看下图：

在这里插入图片描述