第五章：签署区域

现在您已经了解了DNSSEC的一些基础知识，可以启用它了。管理DNSSEC比以前容易得多。所有广泛部署的名称服务器都可以通过名称服务器上的配置设置打开它，并且大多数情况下会自动为您生成（generate）和轮换（rotate）密钥。也有例外——NSD可以为已签名的区域提供服务，但不能生成密钥或对区域进行签名。关于管理DNSSEC的绝大多数博客文章现在都已经过时了（本书出版于2021年）。

在主名称服务器上执行所有DNSSEC配置。辅助名称服务器信任其主名称服务器，并将接受新的区域文件，而不进行任何配置更改。同样，我强烈建议您在首次部署时使用测试域。

管理DNSSEC最关键的部分是DS记录的发布。无论运行哪个名称服务器，都要等到区域签名后再发布DS记录。

我们将深入探讨在BIND上配置DNSSEC，但首先让我们谈谈一些通用的签名概念。

第五章：签署区域密钥状态带有 BIND的签名区密钥文件管理区域管理DNSSEC策略签署区域验证签名密钥文件验证DNSSEC发布 DS 记录

密钥状态

您可以创建密钥而不在区域中发布，也可以从区域中删除密钥，或者使用这些密钥对区域进行签名。密钥有四种正式状态来标识它们的使用方式。

带有 BIND的签名区

BIND允许您在一个区域中使用单个配置语句（statement）打开DNSSEC，但除非您希望到处都有一堆新文件，否则不要这样做。先花点时间建立一个组织（organization）。

不要让成功签署第一个区域的冲动驱使你立即签署所有区域。我鼓励您在大规模部署DNSSEC之前回顾接下来的三章。

密钥文件管理

每个签名区域都以主名称服务器上的 两个密钥文件 和 一个状态文件 开头。轮换（rotate）密钥时，密钥文件会累积。我强烈建议为每个区域提供一个以该区域命名的专用密钥目录。密钥由 named(8) 管理，因此目录必须由名为 named 的用户拥有。 /etc/namedb/working 目录是为 named 创建的文件和目录预留的，因此创建一个 keys 子目录及其下的每个域目录。使用 key-directory 配置选项设置区域的密钥目录。

如果你只有几个区域，你可以创建一个单一的密钥目录并全局设置 key-directory ，但每个域的目录更容易管理，有助于防止事故。

区域管理

您可以通过动态DNS和 nsupdate(1) 或静态区域文件来管理您的区域。DNS管理员经常对其中一个有强烈的依恋。两者都使用DNSSEC，但方式不同。

如果你使用的是动态DNS，BIND已经维护了你的区域文件和相关的日志文件。它可以将DNSSEC记录添加到该区域，而无需您进行任何特殊干预。

静态区域文件更棘手。静态区域文件的一个主要问题是 named 不能更新它。对区域进行签名需要将记录插入到区域中。BIND通过在内部将您精心注释的区域文件转换为动态区域来规避这一限制。当您编辑和重新加载区域文件时，named 会为其创建一个动态区域文件和日志文件，而不会弄脏您珍贵的手工编辑区域文件。旧版本的BIND称之为内联签名（inline signing），并有一个配置选项，但现在它是签名静态区域的默认选项。

内联签名的一个后果是，提供给世界的序列号与静态区域文件中的序列号并不完全相同。当 named 续订记录上的签名时，它还必须递增区域的序列号。然而，Named可以独立管理序列号。编辑分区文件时，必须碰撞（bump） named 的序列号才能注意到更改。

要创建静态区域所需的其他文件，用户 named 必须对区域文件目录具有写入权限。但是，它不需要对静态区域文件具有写权限。

DNSSEC策略

一个区域应该使用单独的KSK和ZSK，还是CSK就足够了？签名应多久更新一次？密钥什么时候到期，应该用什么样的密钥替换它？这些都是政策决定。BIND支持创建包含所有这些设置的命名密钥和签名策略（key and signing policies —— KASP）。

默认策略使用一个永不过期的CSK。这简化了初始DNSSEC部署，但随着时间的推移，您可能会想要一些不那么通用的东西。我们将在第8章中剖析KASP，让您制定自己的政策。

签署区域

告诉 named 使用 dnssec-policy 配置选项对区域进行签名。

运行 rndc reload 。BIND将创建密钥文件并签署此区域。

如果您对静态区域文件中包含的区域进行签名，named 将为该区域的DNSSEC感知版本（DNSSEC-aware versions）创建三个新文件。如果您的区域位于文件 zonename 中，您还将看到 zonename.jbk 、zonename.signed 和 zonename.shigned.jnl 。

验证签名

在继续之前，请仔细检查您的名称服务器是否签署了该区域。签名是RRSIG记录。

响应应包含RRSIG记录，但不会设置 ad 标志。您的父域还没有您的DS记录。让我们解决这个问题。

密钥文件

转到此域的密钥目录。您将找到三个以K开头的文件，表示它们是密钥或与密钥相关。文件使用命名标准：

Kdomain.+algorithm+tag.purpose

例如，这是我的域名mwl.io的文件：

此密钥使用算法（algorithm）是13或ECDSAP256SHA256（根据第1章）。密钥标签（tag）是44950。每个密钥都有一个五位数的标签。标签并非普遍唯一，但确实有助于区分区域内的密钥。如果您运行DNSSEC足够长的时间并定期滚动密钥，域最终将获得具有相同ID的第二个密钥。不过，带有该标签的原始密钥早已过期。

以 .private 结尾的文件是私钥。 .state 文件包含有关区域状态的详细信息。只有策略创建的密钥才有 .state 文件。最有趣的是 .key 文件，其中包含此密钥的DNSKEY记录和关于密钥的注释。

第七章将讨论密钥时间。

验证DNSSEC

在发布DS记录之前，请使用 rndc dnssec 命令验证您的区域是否已真正签名。 -status 选项和区域名称为您提供了名称服务器对区域DNSSEC健康状况的意见。此检查仅适用于配置了 dnssec-policy 语句的区域。

成功的状态检查并不意味着外界可以验证您的区域。这只意味着您的名称服务器的本地DNSSEC设置正常，如果您正确发布其DS记录，则该区域应进行验证。

此区域使用默认的DNSSEC策略。我们将在第8章中对此进行更改。

您将看到当前密钥（CSK）及其发布日期和开始使用的时间。此信息也记录在密钥的状态文件中。密钥44950已经使用了足够长的时间，应该可以在任何地方使用，但DS记录显示为“rumoured”（传闻）状态。你还没有发布你的DS记录，所以传闻中的状态是有道理的。

让我们解决这个问题。

发布 DS 记录

一旦你的区域被签名，并且你有RRSIG和DNSKEY记录，你就可以告诉父区域你的密钥。每个支持DNSSEC的注册商在其网站上都有一个位置，用于输入您域名的关键信息。注册商将要求实际的域注册机构发布您所在区域的DS记录，包括密钥的哈希值和哈希算法。一些注册商希望您提供DS记录，而另一些注册商则希望您提供DNSKEY记录。

如果您提供DNSKEY记录，注册商将自行计算DS记录。当注册商需要更改哈希算法时，它可以在不涉及域所有者的情况下执行该计算。在2000年代和2010年代初部署的密钥中，有令人震惊的比例从未被轮换过，他们的DS记录使用了弱哈希算法。通过要求DNSKEY记录，这些注册商可以为其记录提供未来保障。

其他人希望你发送一份完整的DS记录，因为他们相信你有能力，并将每年轮换你的密钥。如果使用BIND，请使用 dnssec-dsfromkey(1) 命令从密钥文件中提取DS记录。此命令将密钥文件作为参数，并返回完全格式化的DS记录。

默认算法是SHA-256。

将此记录提供给您的注册商。一旦DS记录传播到任何地方，您将拥有可用的DNSSEC。

第7章讨论了发布DS记录时的时间考虑因素，但这些因素在您第一次在区域上配置DNSSEC时并不适用。互联网上的任何名称服务器都没有尝试过验证此域上的DNSSEC，因此它们不会缓存旧的RRSIG记录。但是，如果您要添加新密钥或删除旧密钥，请仔细阅读第7章。

如果你使用BIND，你可以更新密钥状态。这对于从不执行密钥翻转的区域没有用，但我们在第8章中需要它，所以现在就开始吧。

密钥仍将如传闻中那样出现，直到父区域从远程名称服务器的缓存中过期为止。

现在您已经有了一个签名区域，让我们看看DNSSEC是如何出错的。