第五章：DNSSEC

DNS安全扩展（DNS Security Extensions —— DNSSEC）提供可靠的保护，防止缓存中毒(cache poisoning)攻击。同时，这些扩展还提供了其他好处：它们限制了随机子域攻击对解析器缓存和权威服务器的影响，并为身份验证和私人电子邮件传输等现代应用程序提供了基础。

为了实现这一目标，DNSSEC在权威DNS区域的DNS记录中添加数字签名，DNS解析器验证接收到的记录上签名的有效性。如果签名与接收到的数据匹配，解析器可以确保数据在传输过程中没有被修改。

注： DNSSEC和传输级加密是互补的！与DNS-over-TLS、DNS-over-HTTPS或VPN等典型的传输级加密不同，DNSSEC使DNS记录在DNS解析链的所有点上都是可验证的。

本节重点介绍使用BIND部署DNSSEC的方法。有关DNSSEC原理的更深入讨论（例如DNSSEC如何更改DNS查找？），请参阅DNSSEC指南。

5.1. 区域签名

BIND提供了几种方法来生成签名并在DNS区域的生命周期内保持其有效性：

• 全自动（密钥和签名策略）- 强烈建议
• 手动签名-不鼓励，仅用于调试

5.1.1. 区域密钥

无论使用哪种区域签名方法，加密密钥都存储在名为 Kdnssec.example.+013+12345.key 和 Kdnssec.example.+013+12345.private 的文件中。私钥（位于.private文件中）用于生成签名，公钥（位于.key文件中）则用于签名验证。此外，全自动（密钥和签名策略）方法创建了第三个文件 Kdnssec.example+013+12345.state ，用于跟踪DNSSEC密钥定时并安全地执行密钥翻转。

文件名包含：

• 键名，始终与区域名称匹配 (dnssec.example.),
• 算法编号 (013 是 ECDSAP256SHA256, 008 is RSASHA256, 诸如此类),
• 以及密钥标签，即非唯一密钥标识符 (本例中为 12345).

警告： 完全灾难恢复需要私钥。将关键文件备份到安全位置，防止未经授权的访问。任何有权访问私钥的人都可以创建虚假但看似有效的DNS数据。

5.1.2. 全自动（密钥和签名策略）

密钥和签名策略（Key and Signing Policy —— KASP）是一种配置方法，描述了如何维护DNSSEC签名密钥以及如何对区域进行签名。

这是推荐的、完全自动化的DNS区域签名和维护方式。对于大多数用例，用户可以简单地使用内置的默认策略，该策略应用了最新的DNSSEC实践：

  zone "dnssec.example" {
      type primary;
      file "dnssec.example.db";
      dnssec-policy default;
  };

dnssec-policy 声明要求设置动态DNS或启用 inline-signing 。在上面的示例中，我们使用后者，因为 default 策略使用 inline-signing 。

这足以创建必要的签名密钥，并为该区域生成 DNSKEY 、 RRSIG 和 NSEC 记录。BIND还负责此区域的任何DNSSEC维护，包括替换即将过期的签名和管理密钥翻转(Key Rollovers)。

注： dnssec-policy 需要对该区域的写访问权限。有关区域存储影响的更多详细信息，请参阅dnssec-policy 。

默认策略创建一个密钥，用于对整个区域进行签名，并使用 NSEC 启用经过身份验证的拒绝存在（一种安全的方式来判断区域中不存在哪些记录）。建议使用此政策，通常不需要更改。

如果需要，可以通过在配置中添加 dnssec-policy 语句来定义自定义策略：

xxxxxxxxxx
dnssec-policy "custom" {
    dnskey-ttl 600;
    keys {
        ksk lifetime P1Y algorithm ecdsap384sha384;
        zsk lifetime 60d algorithm ecdsap384sha384;
    };
    nsec3param iterations 0 optout no salt-length 0;
};

例如，此 custom 策略：

• 使用非常短的 DNSKEY TTL（600秒）
• 使用两个密钥对区域进行签名：一个密钥签名密钥（Key Signing Key —— KSK）对与密钥相关的RRset（ DNSKEY 、 CDS 和 CDNSKEY ）进行签名，另一个区域签名密钥（Zone Signing Key —— ZSK）对区域的其余部分进行签名。KSK在一年后自动轮换，ZSK在60天后自动轮换。

而且：

• 配置的密钥具有生命周期设置，并使用ECDSAP384SHA384算法。
• 最后一行指示BIND使用零额外迭代和无盐生成NSEC3记录以证明不存在。NSEC3选择退出已禁用，这意味着不安全的委托也会获得NSEC3记录。

有关KASP配置的更多信息，请参阅 dnssec-policy 。

DNSSEC指南中的“Advanced Discussions”部分讨论了各种策略设置，可能有助于确定特定需求的值。

5.1.2.1. 密钥翻转

使用 dnssec-policy 时，可以设置密钥生存期(key lifetime)以触发密钥翻转。ZSK翻转是全自动的，但对于KSK和CSK翻转，需要向家长提交DS记录。有关可能的方法，请参阅安全委派(Secure Delegation)。

一旦DS在父密钥中（并且前导密钥的DS被撤回），BIND需要被告知此事件已经发生。这可以通过配置家长代理自动完成：

xxxxxxxxxx
  zone "dnssec.example" {
      type primary;
      file "dnssec.example.db";
      dnssec-policy default;
      parental-agents { 192.0.2.1; };
      checkds explicit;
  };

这里为BIND配置了一个服务器 192.0.2.1 ，用于向其发送DS查询，以便在密钥翻转期间检查DS RRset的 dnssec-example 。这需要是一个受信任的服务器，因为BIND不会验证响应。checkds 选项使BIND使用显式配置的父代理，而不是通过查询父NS记录来查找它们。

如果设置父代理是不可取的，也可以告诉BIND DS是在父代理中发布的：rndc dnssec -checkds -key 12345 published dnssec.example. 。并且前任密钥的DS已被删除，其中： rndc dnssec -checkds -key 54321 withdrawn dnssec.example 。其中12345和54321分别是后继密钥和前导密钥的密钥标签。

要比计划更早地滚动密钥，或滚动具有无限生命周期的密钥，请使用：rndc dnssec -rowloon -key 12345 dnssec.example. 。

要将签名区域还原为不安全区域，请更改区域配置以使用内置的“不安全”策略。详细说明请参见“还原为未签名”(Reverting to Unsigned)。

5.1.2.2. 多签名者模型

动态区域提供了由多个提供者对区域进行签名的能力，这意味着每个提供者独立地对同一区域进行签名和服务，如 RFC 8901 中所述。BIND 9能够支持Model 2，其中每个提供商都有自己的KSK和ZSK（或CSK）。其他提供者的密钥可以通过动态更新导入。对于每个活动的KSK，父区域中必须有一个相应的DS记录。密钥翻转需要协调才能更新DS和DNSKEY RRset。

5.1.3. 手工签字

有几种工具可用于手动签署区域。

警告： 请注意，手动程序主要用于向后兼容性，只有有特定需求的专家用户才能使用。

要手动设置DNSSEC安全区域，必须遵循一系列步骤。有关更多信息，请参阅DNSSEC指南中的“手动签名”一章。

5.1.4. 使用私有类型记录进行监控

签名过程的状态由私有类型记录（默认类型值为65534）发出信号。签名完成后，具有非零初始八位字节的记录的最后一个八位字节具有非零值。

如果私有类型记录的第一个八位字节为非零，则该记录表示需要使用与记录匹配的密钥对区域进行签名，或者应删除与记录匹配地所有签名。以下是第一个八位字节的不同值的含义：

• algorithm ——算法 (octet 1)
• key ID in network order ——网络顺序中的密钥ID (octet 2 and 3)
• removal flag —— 删除标志 (octet 4)
• complete flag —— 完整标志 (octet 5)

只有标记为“complete”的记录才能通过动态更新删除；删除其他私有类型记录的尝试将被自动忽略。

如果第一个八位字节为零（这是一个不应出现在 DNSKEY 记录中的保留算法号），则该记录表示正在对 NSEC3 链进行更改。记录的其余部分包含 NSEC3PARAM 记录，而标志字段告诉根据标志位执行什么操作：

0x01 OPTOUT

0x80 CREATE

0x40 REMOVE

0x20 NONSEC

5.2. 安全委派

在权威服务器上对区域进行签名后，最后一步是在父区域（例如）和本地区域（dnssec.example）之间建立信任链。

一般来说，程序是：

• Wait 缓存中的过时数据过期。所需的时间等于签名前区域中使用的最大TTL值。此步骤可确保未签名的数据从缓存中过期，并且解析器不会因缺少签名而混淆。
• 在父区域中插入/更新DS记录（ dnssec.example. DS记录）。

有多种方法可以更新父区域中的DS记录。请参阅父区域的文档，了解哪些选项适用于给定的案例区域。一般来说，从最推荐到最不推荐的选项是：

• 使用BIND自动生成的 CDS / CDNSKEY 记录自动更新父区域中的DS记录。这需要在父区域、注册表或注册器中支持 RFC 7344。在这种情况下，配置BIND以监视父区域中的DS记录，一切都会在正确的时间自动发生。
• 使用 dig 在区域中查询自动生成的 CDS 或 CDNSKEY 记录，然后使用父区域指定的方法（web表单、电子邮件、API…）将这些记录插入父区域。
• 使用区域键上的 dnssec-dsfromkey 实用程序手动生成DS记录，然后将它们插入父区域。

5.3. DNSSEC 验证

BIND解析器默认验证来自权威服务器的答案。此行为由配置语句 dnssec-validation 控制。

默认情况下，使用DNS根区域的信任锚点。此信任锚作为BIND的一部分提供，并使用动态信任锚管理保持最新状态。

注： DNSSEC验证“开箱即用”，不需要额外配置。其他配置选项仅适用于特殊情况。

为了验证答案，解析器需要至少一个受信任的起点，即“信任锚”。本质上，信任锚是用于形成加密信任链中第一个链接的区域的 DNSKEY RR的副本。可以使用 trust-anchors 指定替代信任锚，但这种设置非常不寻常，建议仅供专家使用。有关更多信息，请参阅DNSSEC指南中的信任锚。

BIND权威服务器在加载时不验证签名，因此不需要在配置文件中指定权威区域的区域密钥。

5.3.1. 验证失败

配置DNSSEC验证后，解析器会拒绝来自签名的安全区域的任何未验证的答案，并向客户端返回SERVFAIL。

响应可能因多种原因而无法验证，包括签名丢失、过期或无效；与父区域中的DS RRset不匹配的密钥；或者来自一个区域的不安全响应，根据其父区域的说法，该响应应该是安全的。

有关更多信息，请参阅基本DNSSEC故障排除。

5.3.2. 与未签名（不安全）区域共存

不受DNSSEC保护的区域称为“不安全”，这些区域与已签名区域无缝共存。

当验证器收到来自具有已签名父区域的未签名区域的响应时，它必须与父区域确认该区域是故意未签名的。它通过签名和验证的NSEC/NSEC3记录验证父区域是否不包含子区域的DS记录来实现这一点。

如果验证器可以证明该区域是不安全的，则接受响应。然而，如果不能，验证器必须假设不安全的响应是伪造的；它拒绝响应并记录错误。

记录的错误为“不安全证明失败”和“收到不安全响应；父级表示它应该是安全的”

5.4. 动态信任锚管理

BIND能够使用 RFC 5011 密钥管理来维护DNSSEC信任锚。此功能允许 named 跟踪关键DNSSEC密钥的更改，而无需操作员对配置文件进行任何更改。

5.4.1. 正在验证解析器

要配置验证解析器以使用 RFC 5011 来维护信任锚，请使用 trust-anchors 语句和 initial-key 关键字来配置信任锚。关于这一点的信息可以在 trust-anchors 声明描述中找到。

5.4.2. 权威服务器

要为 RFC 5011 信任锚维护设置权威区域，请为该区域生成两个（或多个）密钥签名密钥（key signing keys —— KSK）。与其中一个签署区域；这就是“主动(active)”KSK。所有未签署该区域的KSK都是“备用(stand-by)”密钥。

任何配置为使用活动KSK作为 RFC 5011 托管信任锚的验证解析器都会记录该区域DNSKEY RRset中的备用KSK，并将其存储以供将来参考。解析器定期重新检查该区域；30天后，如果新密钥仍然存在，则解析器会接受该密钥作为该区域的有效信任锚。在30天接受定时器完成后的任何时候，都可以撤销活动的KSK，并将该区域“滚动”到新接受的密钥。

在区域中放置备用密钥的最简单方法是使用 dnssec-keygen 和 dnssec-signzone 的“智能签名”功能。如果密钥的发布日期是过去的，但激活日期是未设置的或将来的，dnssec-signzone -S 会在区域中包含DNSKEY记录，但不会使用它进行签名：

xxxxxxxxxx
$ dnssec-keygen -K keys -f KSK -P now -A now+2y example.net
$ dnssec-signzone -S -K keys example.net

要撤销密钥，请使用命令 dnssec revoke 。这将REVOKED位添加到密钥标志中，并重新生成 K*.key 和 K*.private 文件。

撤销活动密钥后，必须使用撤销的KSK和新的活动KSK对区域进行签名。智能签名会自动处理此问题。

一旦密钥被撤销并用于对其出现的DNSKEY RRset进行签名，解析器将不再接受该密钥作为有效的信任锚。但是，可以使用新的活动密钥进行验证，该密钥在作为备用密钥时被解析器接受。

有关密钥翻转场景的更多详细信息，请参阅 RFC 5011 。

当一个密钥被撤销时，它的密钥ID会发生变化，增加128，并在65535处环绕。例如，密钥“ Kexample.com.+005+10000 ”变为“ Kexapple.com.+005+10128 ”。

如果两个密钥的ID相距128，其中一个密钥被撤销，则这两个密钥ID将发生冲突，从而导致几个问题。为了防止这种情况，如果存在可能发生冲突的另一个密钥， dnssec-keygen 不会生成新的密钥。仅当新密钥写入到包含该区域使用的所有其他密钥的同一目录时，才会发生此检查。

旧版本的BIND 9没有这种保护。如果对以前版本生成的密钥使用密钥吊销，或者使用存储在多个目录或多台计算机上的密钥，请务必小心。

预计BIND 9的未来版本将以不同的方式解决这个问题，通过将撤销的密钥与其原始的未撤销密钥ID一起存储。

5.5. PKCS#11 (Cryptoki) 支持

公钥加密标准#11（Public Key Cryptography Standard —— PKCS#11）定义了一个依赖于平台的API，用于控制硬件安全模块（hardware security modules —— HSMs）和其他加密支持设备。

PKCS#11使用“提供者库”：一个动态可加载的库，它提供了一个低级PKCS#11接口来驱动HSM硬件。PKCS#11提供程序库来自HSM供应商，它特定于要控制的HSM。

BIND 9通过OpenSSL扩展访问PKCS#11库。OpenSSL3及更新版本的扩展名是pkcs11-provider；对于较旧的OpenSSL版本，可以使用OpenSC项目中的engine_pkcs11。

在这两种情况下，扩展都是动态加载到OpenSSL中的，HSM是间接操作的；HSM不支持的任何加密操作都可以由OpenSSL执行。

5.5.1. 先决条件

有关安装、初始化、测试和排除HSM故障的信息，请参阅HSM供应商提供的文档。

5.5.2. 构建 SoftHSMv2

SoftHSMv2是SoftHSM的最新开发版本，可从以下网址获得https://github.com/opendnssec/SoftHSMv2.它是由OpenDNSSEC项目开发的软件库(https://www.opendnssec.org)其以本地文件系统上的SQLite3数据库的形式实现向虚拟HSM提供PKCS#11接口。它提供的安全性不如真正的HSM，但它允许用户在HSM不可用时尝试使用本机PKCS#11。SoftHSMv2可以配置为使用OpenSSL或Botan库来执行加密功能，但在BIND中将其用于本机PKCS#11时，需要OpenSSL。

默认情况下，SoftHSMv2配置文件为 prefix/etc/softhsm2.conf （其中prefix 在编译时配置）。此位置可以被SOFTHSM2_CONF环境变量覆盖。在将SoftHSMv2加密存储与BIND一起使用之前，必须先安装并初始化它。

xxxxxxxxxx
$  cd SoftHSMv2
$  configure --with-crypto-backend=openssl --prefix=/opt/pkcs11/usr
$  make
$  make install
$  /opt/pkcs11/usr/bin/softhsm-util --init-token 0 --slot 0 --label softhsmv2

5.5.3. 使用 engine_pkcs11的OpenSSL 1.x.x

基于OpenSSL引擎的PKCS#11使用libp11项目中的engine_pkcs11 OpenSSL引擎。

engine_pkcs11试图将PKCS#11 API适配到OpenSSL的引擎API中。也就是说，它提供了PKCS#11模块和OpenSSL引擎API之间的网关。必须向OpenSSL注册引擎，并且必须提供应网关连接的PKCS#11模块的路径。这可以通过编辑OpenSSL配置文件、特定于引擎的控件或使用p11-kit代理模块来完成。

建议使用libp11>=0.4.12。

有关更详细的说明，包括示例，我们建议阅读： https://gitlab.isc.org/isc-projects/bind9/-/wikis/BIND-9-PKCS11

使用engine_pkcs11时，请确保将 -E pkcs11 参数传递给所有可能使用密钥的BIND二进制文件，以激活引擎支持。

尽管OpenSSL 3支持Engine API的兼容性，但由于OpenSSL和libp11中存在错误，因此不建议使用它。

无法通过engine_pkcs11生成新密钥，因此不建议在 dnssec-policy 设置中使用它。但是，可以将以前生成的密钥放在 key-directory 中，并在启动密钥滚动时让密钥管理器选择这些密钥。

5.5.4. 配置 engine_pkcs11

配置engine_pkcs11的规范文档在libp11/README.md文件中，但为了方便用户，这里包含了一个示例工作配置：

在我们的示例中，我们使用了一个由名为OpenSSL_CONF的环境变量驱动的OpenSSL配置的自定义副本。首先，复制全局OpenSSL配置（通常在 etc/ssl/openssl.conf 中找到），并将其自定义为使用engine_pkcs11。

xxxxxxxxxx
cp /etc/ssl/openssl.cnf /opt/bind9/etc/openssl.cnf

然后，导出环境变量：

xxxxxxxxxx
export OPENSSL_CONF=/opt/bind9/etc/openssl.cnf

然后在定义任何部分（方括号内）之前，在文件顶部添加以下行：

xxxxxxxxxx
openssl_conf = openssl_init

确保文件中没有其他“openssl_conf=…”行。

在文件底部添加以下行：

​x
[openssl_init]
engines=engine_section
​
[engine_section]
pkcs11 = pkcs11_section
​
[pkcs11_section]
engine_id = pkcs11
dynamic_path = <PATHTO>/pkcs11.so
MODULE_PATH = <FULL_PATH_TO_HSM_MODULE>
# if automatic logging to the token is needed, PIN can be specified as below
#PIN = 1234
init = 0

5.5.5. 在BIND命令中启用OpenSSL引擎

当使用基于OpenSSL引擎的PKCS#11时，可以使用 -E <Engine> 命令行选项在 named 和所有BIND dnssec-* 工具中指定OpenSSL要使用的“engine”。此引擎名称与上一节中创建的 openssl.cnf 中的 engine_id 匹配。

区域签名照常开始，只有一个小区别：我们需要使用 -E 命令行选项提供OpenSSL引擎的名称。

xxxxxxxxxx
dnssec-signzone -E pkcs11 -S -o example.net example.net

5.5.6. OpenSSL 3 和 pkcs11-provider

基于OpenSSL提供程序的PKCS#11使用pkcs11提供程序项目。

pkcs11-provider试图将PKCS#11 API适配到OpenSSL的provider API中；也就是说，它提供了PKCS#11模块和OpenSSL Provider API之间的网关。该引擎必须在OpenSSL中注册，并且必须提供PKCS#11模块网关的路径。这可以通过编辑OpenSSL配置文件、特定于引擎的控件或使用p11-kit代理模块来完成。

必须使用2023年10月2日或以后的pkcs11提供程序git commit 2e8c26b4157fd21422c66f0b4d7b26cf8c320570。

内置了对pkcs11-provider的BIND支持；对于pkcs11-provider，不应使用上面解释的 -E 命令行选项。

5.5.7. 配置 pkcs11-provider

配置pkcs11-provider的规范文档在provider-pkcs11.7手册页中，但为了方便起见，这里提供了一个工作配置的副本：

在这个例子中，我们使用了一个由名为OpenSSL-CONF的环境变量驱动的OpenSSL配置的自定义副本。首先，复制全局OpenSSL配置（通常在 etc/ssl/openssl.conf 中找到），并将其自定义为使用pkcs11-provider。

xxxxxxxxxx
cp /etc/ssl/openssl.cnf /opt/bind9/etc/openssl.cnf

接下来，导出环境变量：

xxxxxxxxxx
export OPENSSL_CONF=/opt/bind9/etc/openssl.cnf

然后在定义任何部分（方括号内）之前，在文件顶部添加以下行：

xxxxxxxxxx
openssl_conf = openssl_init

确保文件中没有其他“openssl_conf=…”行。

在文件底部添加以下行：

xxxxxxxxxx
[openssl_init]
providers = provider_init
​
[provider_init]
default = default_init
pkcs11 = pkcs11_init
​
[default_init]
activate = 1
​
[pkcs11_init]
module = <PATHTO>/pkcs11.so
pkcs11-module-path = <FULL_PATH_TO_HSM_MODULE>
# bind uses the digest+sign api. this is broken with the default load behaviour,
# but works with early load. see: https://github.com/latchset/pkcs11-provider/issues/266
pkcs11-module-load-behavior = early
# no-deinit quirk is needed if you use softhsm2
#pkcs11-module-quirks = no-deinit
# if automatic logging to the token is needed, PIN can be specified as below
# the file referenced should contain just the PIN
#pkcs11-module-token-pin = file:/etc/pki/pin.txt
activate = 1

5.5.8. 密钥生成

现在可以创建和使用HSM密钥。我们假设BIND 9已经安装，无论是从包中还是从源代码中，并且工具在 $PATH 中都很容易获得。

为了生成密钥，我们将使用OpenSC套件中的 pkcs11-tool 。在基于DEB和基于RPM的发行版上，该包都称为opensc。

我们需要生成至少两个RSA密钥：

xxxxxxxxxx
pkcs11-tool --module <FULL_PATH_TO_HSM_MODULE> -l -k --key-type rsa:2048 --label example.net-ksk --pin <PIN>
pkcs11-tool --module <FULL_PATH_TO_HSM_MODULE> -l -k --key-type rsa:2048 --label example.net-zsk --pin <PIN>

请记住，每个密钥都应该有唯一的标签，我们将使用该标签来引用私钥。

将存储在HSM中的RSA密钥转换为BIND 9可以理解的格式。BIND 9的 dnssec-keyfromlabel 工具可以将存储在HSM中的原始密钥与 K<zone>+<alg>+<id> 文件链接起来。

如果使用OpenSSL引擎和算法（ RSASHA256 ），则必须提供OpenSSL引擎名称（ pkcs11 ）。密钥用PKCS#11 URI方案引用；它可以包含PKCS#11令牌标签（我们假设它已初始化为bind9）、PKCS#11对象标签（使用 pkcs11-tool 生成密钥时称为“标签”）和HSM PIN。有关完整的PKCS#11 URI规范，请参阅 RFC 7512 。

转换KSK：

xxxxxxxxxx
dnssec-keyfromlabel -E pkcs11 -a RSASHA256 -l "pkcs11:token=bind9;object=example.net-ksk;pin-value=0000" -f KSK example.net

和 ZSK：

xxxxxxxxxx
dnssec-keyfromlabel -E pkcs11 -a RSASHA256 -l "pkcs11:token=bind9;object=example.net-zsk;pin-value=0000" example.net

注意：存储在磁盘上的PIN可以通过指定 pin-source=<path_to>/<file> 来使用，例如：

xxxxxxxxxx
(umask 0700 && echo -n 0000 > /opt/bind9/etc/pin.txt)

然后在标签规范中使用：

xxxxxxxxxx
pin-source=/opt/bind9/etc/pin.txt

确认当前目录中存在一个KSK和一个ZSK：

xxxxxxxxxx
ls -l K*

输出应该如下（第二个数字将不同）：

xxxxxxxxxx
Kexample.net.+008+31729.key
Kexample.net.+008+31729.private
Kexample.net.+008+42231.key
Kexample.net.+008+42231.private

关于生成ECDSA密钥的说明：在查找密钥时，libp11中存在一个错误。该函数仅比较密钥的ID，而不是标签，因此在查找密钥时，它返回第一个密钥，而不是匹配的密钥。要在创建ECDSA密钥时解决此问题，请指定一个唯一的ID：

xxxxxxxxxx
ksk=$(echo "example.net-ksk" | openssl sha1 -r | awk '{print $1}')
zsk=$(echo "example.net-zsk" | openssl sha1 -r | awk '{print $1}')
pkcs11-tool --module <FULL_PATH_TO_HSM_MODULE> -l -k --key-type EC:prime256v1 --id $ksk --label example.net-ksk --pin <PIN>
pkcs11-tool --module <FULL_PATH_TO_HSM_MODULE> -l -k --key-type EC:prime256v1 --id $zsk --label example.net-zsk --pin <PIN>

5.5.9. 使用自动区域重新签名运行named

该区域也可以通过 named 自动签名。同样，如果使用OpenSSL 1.x.x和engine_pkcs11，我们需要使用 -E 命令行选项提供OpenSSL引擎的名称；使用OpenSSL 3.x.x提供程序时不需要这样做。

xxxxxxxxxx
named -E pkcs11 -c named.conf

日志应包含以下行：

xxxxxxxxxx
Fetching example.net/RSASHA256/31729 (KSK) from key repository.
DNSKEY example.net/RSASHA256/31729 (KSK) is now published
DNSKEY example.net/RSA256SHA256/31729 (KSK) is now active
Fetching example.net/RSASHA256/42231 (ZSK) from key repository.
DNSKEY example.net/RSASHA256/42231 (ZSK) is now published
DNSKEY example.net/RSA256SHA256/42231 (ZSK) is now active

对于 named 使用HSM密钥对区域进行动态重新签名，和/或对通过nsupdate插入的新记录进行签名，named 必须能够访问HSM PIN。在基于OpenSSL的PKCS#11中，这是通过将PIN放入 openssl.cnf 文件（在上述示例中为 /opt/pkcs11/usr/ssl/openssl.cnf ）来实现的。

有关在全局级别配置PIN的说明，请参阅OpenSSL扩展特定文档；这样做允许 dnssec-\* 工具在不输入PIN的情况下访问HSM。（ pkcs11-\* 工具直接访问HSM，而不是通过OpenSSL，因此使用它们仍然需要PIN。）