为什么 dnssec 签名区域无法重新加载

Question

FreeBSD-12
BIND-9.11

经过一番努力，我改变了错误。现在我看到的是：

07-Jun-2019 18:01:25.299 zone parschecks/IN/public (unsigned): loaded serial 2019070701 (DNSSEC signed)
07-Jun-2019 18:01:25.299 dns_master_load: file format mismatch (not raw)
07-Jun-2019 18:01:25.299 zone parschecks.ca/IN/public (signed): loading from master file /usr/local/etc/namedb/master/parschecks.ca.hosts.signed failed: not implemented
07-Jun-2019 18:01:25.299 zone parschecks/IN/public (signed): not loaded due to errors.

原始问题：

我有这个域名，当我重新加载时它会报告其密钥已过期：

Jun  7 15:32:24 dns38 named[19583]: /usr/local/etc/namedb/master/parschecks.ca.hosts:53: signature has expired
Jun  7 15:32:25 dns38 named[19583]: zone parschecks.ca/IN/public (signed): receive_secure_serial: unchanged

但是我已经手动签署了这个域名：

2019-06-07 15:26:34: dnssec-keygen -f KSK -a ECDSAP256SHA256 -n ZONE parschecks.ca
2019-06-07 15:26:50: dnssec-keygen -a ECDSAP256SHA256 -n ZONE parschecks.ca
2019-06-07 15:27:05: dnssec-signzone -N increment -S -o parschecks.ca parschecks.ca.hosts Kparschecks.ca.+013+37572

并且 hosts 文件似乎已经更新：

-rw-r--r--  1 bind  bind     609 Mar 12 12:59 Kparschecks.ca.+008+29077.key
-rw-------  1 bind  bind    1776 Mar 12 12:59 Kparschecks.ca.+008+29077.private
-rw-r--r--  1 bind  bind     479 Mar 12 12:59 Kparschecks.ca.+008+32223.key
-rw-------  1 bind  bind    1200 Mar 12 12:59 Kparschecks.ca.+008+32223.private
-rw-r--r--  1 bind  bind     479 Feb 19 21:17 Kparschecks.ca.+008+43116.key
-rw-------  1 bind  bind    1200 Feb 19 21:17 Kparschecks.ca.+008+43116.private
-rw-r--r--  1 bind  bind     346 Jun  7 15:24 Kparschecks.ca.+013+35858.key
-rw-------  1 bind  bind     187 Jun  7 15:24 Kparschecks.ca.+013+35858.private
-rw-r--r--  1 bind  bind     346 Jun  7 15:26 Kparschecks.ca.+013+37572.key
-rw-------  1 bind  bind     187 Jun  7 15:26 Kparschecks.ca.+013+37572.private
-rw-r--r--  1 bind  bind     345 Jun  7 15:26 Kparschecks.ca.+013+50724.key
-rw-------  1 bind  bind     187 Jun  7 15:26 Kparschecks.ca.+013+50724.private
-rw-r--r--  1 bind  bind     344 Jun  7 15:27 dsset-parschecks.ca.
-rw-r--r--  1 bind  bind    9515 Apr 18 12:03 parschecks.ca.hosts
-rw-r--r--  1 bind  bind     512 Mar 22 17:28 parschecks.ca.hosts.jbk
-rw-r--r--  1 bind  bind    2395 Apr 18 12:28 parschecks.ca.hosts.jnl
-rw-r--r--  1 bind  bind   15960 Jun  7 15:32 parschecks.ca.hosts.signed
-rw-r--r--  1 bind  bind  128161 Jun  7 15:43 parschecks.ca.hosts.signed.jnl

named.conf 包含以下内容：

zone "parschecks.ca" {
type master;
file "/usr/local/etc/namedb/master/parschecks.ca.hosts";
key-directory "/usr/local/etc/namedb/master/";
auto-dnssec maintain;
inline-signing yes;
};

我们正在转向内联签名，但目前还无法让它正常工作。如果我们从 named.conf 中的区域条目中删除自动维护条款，区域文件仍会报告为已过期。

rndc -s 127.0.0.1 reload parschecks.ca
zone reload up-to-date

hosts 文件中没有任何更改。但退出后无法加载。我遗漏了什么步骤？

Answer 1

named配置为您处理签名过程 ( auto-dnssec maintain)，使用手动管理的区域文件（据称未签名）作为输入 ( inline-signing yes)，然后手动签名区域（通过调用） ，这种组合dnssec-signzone并不是预期的工作方式，而且很可能解释了事情为什么变得混乱。

至于如何清理混乱局面（无论你决定朝哪个方向走，我预计这都是必需的），我建议从区域文件的未签名版本开始（如果需要，可以手动清理，尽管听起来应该是未签名的parschecks.ca.hosts）。
我这样说是因为现在你有所有这些自动生成的文件（区域文件本身的日志文件，带有日志的自动签名区域），其中包含的数据可能与你的意图不符，而日志文件存在日志可能与相应的区域文件不同步的问题。（听起来你已经覆盖了自动生成的签文件，正如命名的那样，抱怨说这个文件不是设置的预期格式inline-signing，然后那个日志文件可能也不同步）。
我还看到该目录中有大量的关键文件，但如果没有看到关键元数据，很难说这是否会导致问题（清理它也可能是一个明智的选择）。

无论如何，当然要先备份所有内容，但清理过程可能包括删除除未签名的区域文件 + 实际正在使用的密钥文件之外的所有内容，然后从named配置为您实际打算使用的签名模式的干净文件开始（您需要决定）。

总的来说，我建议完全避免使用，dnssec-signzone因为它相当过时且不方便（进行更改时需要额外的步骤，而且无论您是否进行任何更改，都需要重复基于时间的额外步骤来刷新签名，并且需要以某种方式处理）。
BIND 中的自动签名流程已经存在很长时间了（至少接近 10 年），所以dnssec-signzone当你甚至没有基于此的工作设置作为起点时，对我来说考虑它真的没有意义（当然，除非你非常熟悉该设置并且需要在切换之前做更多准备）。
有关如何设置自动签名，请参阅BIND DNSSEC 指南。

Answer 2

就我的情况而言，为了让 dnssec-signzone 正常工作，解决方法是：

1. 确保 SOA 中的域名匹配确切地正在发布 DNS 区域的域。

2. 确保删除该区域的所有文件.jnl。.jbk

3. 确保.signed该区域的所有文件都已被删除。

4. 确保所有嵌入的 RRSIG 记录都已从主文件中删除。

5. 确保所使用的区域签名密钥 (ZSK) 由该区域的密钥签名密钥 (KSK) 正确签名。

6. 确保区域中的 DSKEY 资源记录与您要使用的密钥的哈希值匹配。

7. 删除该区域可能存在的任何其他密钥。

8. 当主区域文件不具有与区域完全相同的名称时，使用 -S“智能签名”选项和 -o domain.name 选项使用 dnssec-signzone。不要提供特定的密钥文件。不要使用 -N 选项覆盖“增量”的默认区域编号方案。（除非你比我更了解这个主题）

9. 使用内联签名时，区域不必是动态的。（ISC BIND 9.9.0 中的 ISC 内联签名 - 示例

最初，许多区域主文件都存在上述一个或多个已更正的缺陷，但后来，由于诊断问题的努力导致遗留了区域中的工件，许多缺陷变得更加严重大师目录。这些区域文件与 BIND-9.8 配合良好，但显然有些与 9.11 的期望相冲突。和内联签名要求。

这些缺陷可能是内联签名对某些区域不起作用而对其他区域起作用的原因。我找不到任何日志条目来标识错误类型，也named-checkconf -z没有标识任何错误。在不同端口的前台运行命名并使用调试选项加载有缺陷的区域提供了如何继续的提示，但从未指出区域文件中的确凿记录。

这是否能解决自动维护、内联签名的问题还有待观察。