第二章：DNSSEC记录

负责管理域名系统的人员都熟悉常见的资源记录，如 A 、 PTR 或 CNAME 。但DNS支持数十种不同的记录类型，如A FSDB 、HIP 和 OPENPGPKEY 。DNSSEC增加了八种新的记录类型，并利用了您以前可能忽略的DNS方面，这并不奇怪。这些资源记录包含验证DNSSEC所需的信息和签名。

记录类型和条目

您应该已经熟悉DNS记录的开头。所有DNS记录都以相同的四个条目开头。

mwl.io. 3600 IN AAAA 2001:db8::f00d

任何记录中的第一个字段都是域名或所有者名称。此条目适用于域 mwl.io 。

第二个字段是生存时间，以秒为单位。这些数据可以缓存3600秒，即一小时。许多DNSSEC记录的生存时间很短，告诉您不要缓存超过签名过期的密钥。

在互联网上，第三个字段几乎总是IN（互联网）。

最后，我们有记录类型。此示例用于 AAAA 记录。DNSSEC提供了多种记录类型：DNSKEY 、DS、RRSIG、NSEC、NSEC3、NSEC3PARAM、CDS 和 CDNSKEY 。

与所有其他DNS记录一样，每个DNSSEC记录在第五个字段及以后都有自己的记录数据格式（rdata —— record data）。我们将对rdata中出现的字段进行编号。

DNSKEY

DNSKEY 资源记录包含区域的公钥并标识密钥算法。域的 DNSKEY 记录看起来像这样：

xxxxxxxxxx
mwl.io.  3600 IN DNSKEY 256 3 13 zEo0…

rdata的第一个字段（256）给出了密钥标志，指示后面公钥的用途。DNSSEC主要使用两个密钥标志。

• 256 表示区域签名密钥（Zone Signing Key —— ZSK）。
• 257 是密钥签名密钥（Key Signing Key —— KSK）。组合签名密钥（Combined Signing Key —— CSK）通常为 257 ，尽管一些软件将其标记为 256 。要么验证。
• 您可能还会看到标志 385 ，这意味着密钥已被撤销，不应被信任。

rdata的第二个字段是协议，它应该始终是 3 。DNSKEY 记录来源于一种早期的、现已废弃的资源记录类型（ KEY ），该类型在一条记录中支持多种类型的密钥。协议字段是向后兼容性的遗留部分，从未被清理过。您可以使用其他记录类型来提供非DNSSEC公钥，我们将在第12章中看到。

第三个rdata字段是签名算法。与SSH或TLS等协议相比，DNSSEC使用的密钥算法选择范围很窄。您最常看到的两个是算法 8（RSASHA256）和 13 （ECDSAP256SHA256），如第1章所述。

最后一个字段是公钥的base64表示。客户端将使用此公钥验证签名。

DNSKEY记录出现在它支持的区域中。

【以下是实际情况：】

​x
$ drill io DNSKEY
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 2877
;; flags: qr rd ra ; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; io.  IN      DNSKEY
​
;; ANSWER SECTION:
io.     3600    IN      DNSKEY  256 3 8 AwEAAbhoeBc...
io.     3600    IN      DNSKEY  256 3 8 AwEAAfPlU+F...
​
;; AUTHORITY SECTION:
​
;; ADDITIONAL SECTION:
​
;; Query time: 242 msec
;; SERVER: 2402:4e00::
;; WHEN: Mon Apr  7 13:57:15 2025
;; MSG SIZE  rcvd: 316
​
 $ drill mwl.io DNSKEY
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 16326
;; flags: qr rd ra ; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; mwl.io.      IN      DNSKEY
​
;; ANSWER SECTION:
mwl.io. 3600    IN      DNSKEY  257 3 13 8Xuoa4GrXr...
mwl.io. 3600    IN      DNSKEY  257 3 13 6ttuzeOal...
​
;; AUTHORITY SECTION:
​
;; ADDITIONAL SECTION:
​
;; Query time: 455 msec
;; SERVER: 2400:3200::1
;; WHEN: Mon Apr  7 13:59:00 2025
;; MSG SIZE  rcvd: 184

DS

DS （Delegation Signer —— 委派签名者）资源记录链接DNS的不同级别。它将根区域（.）绑定到 .com，将 .com 绑定到 tiltedwindmilpress.com ，将 tiltedwingmilpress.com 绑定到其子域。区域的DS记录出现在父区域中，是子区域已签名的无可辩驳的声明。如果父区域有某个区域的DS记录，但子区域未签名，则子区域将不会生效。它从互联网上消失了。在与您的区域的父级交互之前，请先签署您的区域。

作为区域的维护者，您向注册商或父区域维护者提供用于创建DS记录的DS记录或DNSKEY记录。这被称为出版。在发布之前，请验证该区域是否已使用该密钥签名，并已复制到所有次级服务器。

DS记录包含区域活动KSK或CSK的哈希值，以及有关算法和相关密钥标签的信息。DS记录看起来是这样的：

xxxxxxxxxx
mwl.io.  86400  IN  DS  7250  13 2 A30B3F78B6DDE9A4A9A2…

rdata的第一个字段（7250）是 key tag （密钥标签），也称为 key id 。标签是一个五位数的数字，可以方便地识别特定的密钥。没有要求标签在区域、算法之间，甚至在同一区域内都是唯一的。如果您的权威名称服务器支持多个区域，则两个区域可能具有相同的标签。如果你的区域使用多个算法签名——比如在算法翻转过程中——而你非常不走运，那么该区域可能有不同算法的密钥和相同的标签。一个区域可以在后续密钥中重用相同的标签。随机机会可以同时为一个区域分配两个具有相同标签的密钥，但这极不可能。您不需要显示标签的前导零（上面例子中实际上应该是 07250 ）。

下一个字段是算法（13）。该区域使用 SHA-256 和标准椭圆曲线算法用 ECDSAP256SHA256 签名。

下一个字段给出了用于标识公钥的哈希算法。请记住，DS记录不包含完整的公钥。它只包含该公钥的哈希值。算法2 —— SHA-256 —— 是标准。算法1是过时的SHA-1，客户端必须能够验证它，但不应该部署它。最佳做法是始终为2。

DS记录必须出现在该区域的父区域中，紧邻该区域的名称服务器记录。要获取已签名区域mwl.io的DS记录，请查询.io名称服务器。

【以下是实际情况：】

xxxxxxxxxx
$ drill io DS
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 29370
;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; io.  IN      DS
​
;; ANSWER SECTION:
io.     1326    IN      DS      57355 8 2 95a57c3bab7849dbcdd...
​
;; AUTHORITY SECTION:
​
;; ADDITIONAL SECTION:
​
;; Query time: 9 msec
;; SERVER: 2400:3200::1
;; WHEN: Mon Apr  7 13:52:55 2025
;; MSG SIZE  rcvd: 68
​
$ drill mwl.io DS
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 3526
;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; mwl.io.      IN      DS
​
;; ANSWER SECTION:
mwl.io. 3600    IN      DS      30172 13 2 7e1526ec8720e578...
​
;; AUTHORITY SECTION:
​
;; ADDITIONAL SECTION:
​
;; Query time: 172 msec
;; SERVER: 2400:3200::1
;; WHEN: Mon Apr  7 14:00:10 2025
;; MSG SIZE  rcvd: 72

DS记录指向的密钥称为安全入口点（Secure Entry Point —— SEP）。它是验证解析器首次进入区域的地方。

RRSIG

资源记录签名（Resource Record Signature —— RRSIG）给出了一组资源记录的数字签名。资源记录集是DNS中经常被忽视的一部分，因此我们将对其进行详细介绍。

资源记录集（Resource Record Set —— RRSet）是具有相同域名、记录类（IN）和记录类型的记录的集合。解析程序在回答查询时返回完整的RRSet。如果你查询 www.mwl.io 的地址，你会得到一条A记录。该区域只有该主机的一条A记录。这是一个完整的RRSet。如果我请求 www.yahoo.com 的地址，我会得到六条A记录。这六条记录也是一个完整的RRSet。

xxxxxxxxxx
$ drill www.mwl.io
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 13026
;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 6
;; QUESTION SECTION:
;; www.mwl.io.  IN      A
​
;; ANSWER SECTION:
www.mwl.io.     600     IN      A       23.139.82.3
​
;; AUTHORITY SECTION:
mwl.io. 578     IN      NS      bewilderbeast.blackhelicopters.org.
mwl.io. 578     IN      NS      pestilence.michaelwlucas.com.
mwl.io. 578     IN      NS      ns.theapt.org.
​
;; ADDITIONAL SECTION:
ns.theapt.org.  578     IN      A       81.209.183.114
pestilence.michaelwlucas.com.   578     IN      A       23.139.82.3
bewilderbeast.blackhelicopters.org.     578     IN      A       45.76.65.103
ns.theapt.org.  578     IN      AAAA    2001:67c:12f4::53
pestilence.michaelwlucas.com.   578     IN      AAAA    2602:fb89:1:5f::3
bewilderbeast.blackhelicopters.org.     578     IN      AAAA    2001:19f0:6001:734:5400:5ff:fe16:52a9
​
;; Query time: 658 msec
;; SERVER: 192.168.0.1
;; WHEN: Mon Apr  7 14:03:37 2025
;; MSG SIZE  rcvd: 290
​
​
$ drill www.yahoo.com
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 40618
;; flags: qr rd ra ; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; www.yahoo.com.       IN      A
​
;; ANSWER SECTION:
www.yahoo.com.  8       IN      CNAME   me-ycpi-cf-www.g06.yahoodns.net.
me-ycpi-cf-www.g06.yahoodns.net.        58      IN      A       69.147.80.15
me-ycpi-cf-www.g06.yahoodns.net.        58      IN      A       69.147.80.12
​
;; AUTHORITY SECTION:
​
;; ADDITIONAL SECTION:
​
;; Query time: 9 msec
;; SERVER: 2400:3200::1
;; WHEN: Mon Apr  7 14:04:01 2025
;; MSG SIZE  rcvd: 108

为什么RRSets很重要？DNSSEC不会对DNS记录进行签名。它签署了RRSets。我的web服务器的条目只有一个RRSet。雅虎的六台网络服务器也只有一个RRSet。我的域名有两个名称服务器，列出它们的记录是一个RRSet。一组记录是签名的，而不是个人地址。

一个RRSIG记录类似以下内容：

xxxxxxxxxx
<<<fix wrap in production>>>
​
mwl.io.  86400  IN  RRSIG  DNSKEY  13 2 7200 20210711042116 20210611040902 7250 mwl.io. F5OZTjzST1IKSJNTWzkZbO

rdata的第一个字段告诉您此签名适用于哪种DNS资源。此条目用于DNSKEY记录。这可能是A、SOA(Start of Authority)、MX或出现在您的区域中或DNSSEC添加到您的区域的任何其他类型的DNS记录。

第二rdata字段（13）给出了用于生成该区域的算法。算法13是ECDSAP256SHA256。第一章讨论了关键算法。

第三个rdata字段（2）具有资源记录集中的标签数。这有助于客户端确定RRSet是否包含通配符DNS条目。

第四个字段（7200）给出了此数据的原始生存时间（TTL），中间缓存名称服务器没有进行任何减法。验证签名需要原始TTL。

接下来的两个字段给出了签名到期的UTC日期（20210711042116）和签名生效的日期（2021061104902）。此签名于2021年6月11日4:09:02 UTC生效。它将于2021年7月11日4:21:16 UTC到期。签名过期与DNS生存时间（TTL）无关。签名的持续时间应该远远长于TTL，因为与向客户端提供记录相比，生成签名的计算成本很高。一个月是很常见的。这些时间戳是名称服务器时间同步如此重要的原因。如果主名称服务器和递归名称服务器上的时间不同，递归服务器可能会拒绝其他有效记录。

第七个rdata字段（7250）给出了生成此签名的密钥的密钥标签（key tag ，也称为 key id ）。

第八个字段是签名者的姓名。这应该是包含此记录的区域。正如您所期望的那样，mwl.io上的此签名包含在mwl.io区域中。

记录以包含实际数字签名的几个长字符串结束。

ZSK用于对区域数据进行签名并生成RRSIG。包含ZSK和KSK的DNSKEY RRSet使用KSK进行签名。CDS和CDNSKEY RRSets也是如此。如果你使用CSK，它会签署所有内容。

NSEC

作为 next secure 的资源记录，NSEC提供了记录不存在的证明。如果你试图找到一个没有出现在该区域中的记录，你需要DNS服务器权威地说该记录不存在。证明 piratebooks.mwl.io 不存在与证明它存在同样重要，甚至可能更重要。

NSEC记录看起来像这样：

xxxxxxxxxx
osx.mwl.io. 7200  IN  NSEC  printer.mwl.io. A RRSIG NSEC

第一个字段是标准名称记录，但在NSEC中它有一个转折点。这可能不是您要求的记录。这是一个较早的记录。第二、第三和第四个字段都是标准的。

第五个字段是rdata中的第一个条目，是区域中下一个有效主机的名称。

为什么一条记录中有多个主机名？此NSEC记录显示 osx.mwl.io 和 printer.mwl.io 之间没有有效的主机。名称服务器维护一个排序的名称列表，并提供您请求前后的条目。

接下来，我们在条目的开头有一个与主机关联的记录类型列表。主机 osx 有A、RRSIG和NSEC记录。它证明没有TXT或MX记录。

你可能听说过一种叫做积极的NSEC（aggressive NSEC）的东西。审计员偶尔想知道你是否在使用它。它在2017年成为标准（RFC 8198），所有主要的域名服务器都尽快采用了它。积极的NSEC保护域名服务器免受某些极端情况和拒绝服务攻击。但是，如果您被困在旧的名称服务器软件上，您可能需要验证它是否支持积极的NSEC。

NSEC记录存在缺陷，因为它们可用于列出区域中的所有条目。此NSEC记录显示主机 osx.mwl.io 和 printer.mwl.io 是合法的，但这两者之间不存在记录。查询 osx.mwl.io 的NSEC记录告诉我，下一个有效主机是 printer.mwl.io 。我可以查询 printer.mwl.io 的NSCE记录，看看下一个NSEC记录公开了什么。这是一种笨拙的区域转移方式，但入侵者会发现这些信息非常宝贵。对于某些区域，特别是IPv4反转，这并不重要。众所周知， 3.2.0.192-in-addr.arpa 遵循 2.2.0.192-in-address.arpa ，可以在不进行区域转移的情况下进行侦察。然而，前方区域是不可预测的。您可以使用NSEC3来提高区域机密性。

NSEC3/NSEC3PARAM

NSEC3类似于NSEC，但它对所有现有条目的名称进行哈希运算。DNS侦察只会发现其他条目的存在，而不是名称。

xxxxxxxxxx
DRVR6JA3E4VO5UIPOFAO5OEEVV2U4T1K.mwl.io. 3600 IN NSEC3 1 0 10 03F92714 GJPS66MS4J1N6TIIJ4CL58TS9GQ2KRJ0 A RRSIG

第一个字段是前一个有效主机名的哈希值，与NSEC记录完全相同。

第二、第三和第四个字段是标准DNS字段。

第五个字段（1）是用于生成哈希的算法。

第六个字段（0）用于NSEC3标志。它几乎总是0。1表示某些子区域故意未签名。

第七个字段（10）是主机名通过哈希算法的次数。最初被认为是一种安全增强，但在2021年，重复哈希被证明没有提供额外的好处。

如果你设置了一个盐，接下来会显示盐及其长度。盐不再被认为是一种有用的安全增强手段。这条记录有一个盐，03F92714。

最后，您将获得下一个条目的哈希值和记录类型位图。几乎没有理由用肉眼来分析这些。 与NSEC一样，您可能会听到积极的NSEC3（aggressive NSEC3）。就像积极的NSEC一样，每个主要供应商都默认部署了它。如果您在使用旧的名称服务器软件时遇到困难，您只需要担心NSEC3的非攻击性（non-aggressive）。

如果您的区域使用NSEC3，它也将有一个NSEC3PARAM条目。这提供了权威服务器计算NSEC3记录所需的信息。NSEC3PARAM条目不涉及验证或名称解析，也不适合人类阅读。

CDS 和 CDNSKEY

CDS和CDNSKEY记录允许名称服务器与域注册器通信，而无需通过任何专有注册器API。这些记录看起来与DS和DNSKEY记录完全相同，但代表了孩子希望父母的DS RRSet是什么样子。如果父区域已经更新了其DS记录，则这些记录可能代表当前密钥。

域注册商应监控其每个客户端区域是否出现CDS和DNSKEY记录。当记录出现时，注册器会检查记录是否由当前密钥签名。如果是，注册商将现有的DS记录更改为CDS记录中给出的记录。我们将在第7章中进一步讨论这个问题。

记录与信任链

第1章包括DNSSEC使用的信任链的简化图。现在您已经了解了各种记录类型，您可以更现实地了解信任链。在这里，我们看看我的主机 www.tiltedwindmilpress.com 的链，由 DNSViz.net 生成。（我们将在第3章中查看其他DNSViz图。）

链的起点是解析器中配置的信任锚点。它用于验证根区域（.）的KSK。根区域的KSK在根区域的ZSK上签名。到目前为止，这一切都是完全内部的。链中的下一个链接是 .com 管理员提供给根区域的 .com DS记录。 .com DS记录位于根区域，并由根区域ZSK签名。直接签名链到此结束，客户端必须继续到 .com 域的安全入口点（Secure Entry Point —— SEP）。

一个客户端向下移动到 www.tiledwindmillpress.com ，将继续访问.com的权威名称服务器。 .com KSK的DNSKEY记录与根区域中的 .com DS记录匹配，因此它是一个SEP。链继续。

.com KSK已经签署了 .com ZSK，后者又签署了 tiltedwindmilpress.com DS记录。

客户将前进到 tiltedwindmillpress.com 域名服务器。由于 tiltedwindmillpress.com 的威胁情况与根区域的威胁情况有很大不同，因此该域使用组合签名密钥，而不是单独的KSK和ZSK。CSK与 .com 中的签名DS记录匹配，因此它是一个SEP。CSK已为 www.tiltedwindmilpress.com 的资源记录签名。我们有一个完整的信任链。

这进一步说明了为什么客户端从下到上验证每个信任链。运行时间很短的客户端可能已经缓存了 .org 、 .net 和 .beer 等主要顶级域的DNSKEY记录。客户端可以抓取特定目标主机的记录并向上搜索，快速找到它已经知道有效的内容。

发布DS记录

在任何人都可以验证域的签名之前，域必须使其DS记录在父区域中可用。如果我想保护 tiltedwindmillpress.com ，我必须将我的DS记录发送到 .com 。这与注册您的域名服务器没有太大区别：您可以在注册商处的web表单中输入信息，然后等待更新传播。

在发布这些DS记录之前，您必须签署您的区域。如果您的父区域有您的区域的DS记录，但您的域尚未使用匹配的密钥对其记录进行签名，则DNSSEC验证将中断。父区域的DS记录是子区域使用该密钥签名的权威声明，因此任何未签名的记录都是明显伪造的，应该被拒绝。您的区域将从Internet上消失。

如果从区域中删除DNSSEC，请从删除DS记录开始。只有在这些记录有足够的时间从每个人的缓存中过期后，才能从该区域中删除签名。

通过您的注册商、ISP或RIR在父区域中发布您的区域的DS记录。

您的域名注册商是管理有关您域名的公共信息（包括DS记录）的中心点。遗憾的是，并非所有注册商都支持DS记录。如果您的注册商不支持DS记录，您必须切换注册商以实施DNSSEC。

在反向区域上实施DNSSEC需要在父区域中为您的地址输入DS记录。如果您有自己的地址空间，请在您的区域互联网注册中心（Regional Internet Registry —— RIR）进行操作。这些组织包括

• ARIN（北美）
• RIPE（欧洲）
• APNIC（亚太地区）
• LACNIC（拉丁美洲）
• AFRINIC（非洲）

RIR都支持从其web界面管理DS记录。

但是，如果您没有自己的地址空间，则必须要求所有者管理您的DS记录。如果他们还不支持DNSSEC，他们就无法在内部支持信任链。不过，如果您有IPv4/24或更大版本，他们可以在RIR代表您输入DS记录。他们是否会这样做是另一回事。如果您的ISP不能或不愿支持DNSSEC，请鼓励他们加入现代千年。

现在您已经对DNSSEC的工作原理以及全面实施DNSSEC的外部要求有了基本的了解，让我们来看看现实世界中的DNSSEC。