☰

DNSSEC 自动签名并非自动的

tag-icon • tag-icon bind dns-zone dnssec
DNSSEC 自动签名并非自动的

我无法让 DNSSEC 自动签名真正实现自动化。它无法自动签名（好吧，它确实会自动签名，但显然签名错误，见下文）。此外，偶尔会在不可预测的时间生成神秘错误，然后似乎又消失了。

设置：

zone "example.com" in {
   # file "/etc/bind/zones/db.example.com";  # raw data comment out
   file "/etc/bind/zones/db.example.com.signed";
   key-directory "/etc/bind/keys";
   auto-dnssec maintain;
   inline-signing yes;
};

然后我签署区域：

dnssec-signzone -o example.com -t -k ../keys/Kexample.com.+008+04309.key db.example.com ./keys/Kexample.com.+008+21996.key

然后更新所有内容：

rndc reload
rndc reconfig
rndc loadkeys example.com
rndc signing -list example.com

似乎一切都正常。没有错误，甚至在 中也没有syslog，并且dig @ns.example.com example.com响应正确。 也是如此dig @ns.example.com +dnssec +cd +multiline example.com。看起来像马一样健康。好吧，差不多。当我查看目录时：ls -la /etc/bind/zones我看到了一些让我感到奇怪的事情：

-rw-r--r-- 1 root root  4578 Apr 14 11:06 db.example.com
-rw-r--r-- 1 root bind 21189 Apr 14 13:01 db.example.com.signed
-rw-r--r-- 1 bind bind   512 Apr 14 13:01 db.example.com.signed.jbk
-rw-r--r-- 1 bind bind  4720 Apr 14 13:15 db.example.com.signed.signed
-rw-r--r-- 1 bind bind 67248 Apr 14 13:24 db.example.com.signed.signed.jnl

签名文件？嗯？好的，但一切正常。好吧，几乎所有事情都正常。此后不久，我开始在系统日志中看到错误：

named[25494]: malformed transaction: /etc/bind/zones/db.example.com.signed.signed.jnl last serial 2021041421 != transaction first serial 2021041404
named[25494]: zone example.com/IN (signed): zone_sign:dns_journal_write_transaction -> unexpected error

它会间歇性地出现，每分钟重复一次，然后消失一段时间（没有可预测的模式）。当我说 时，它们似乎会消失rndc sync -clean。 新的 副本db.example.com.signed.signed会不时出现，时间范围不可预测：可能是 5 分钟后，可能是半小时后，也可能是几个小时后。

不管怎样。现在一切都很好。忽略一个月，回来发现 DNSSEC 签名已过期！怎么会这样？ls -la显示db.example.com.signed.signed和上的时间戳db.example.com.signed.signed.jnl是最近的：显然，bind9 认为这些需要定期更新。上的时间戳db.example.com.signed很旧 - 一个月前，查看它的内容，我发现它RRSIG SOA上面确实有一个现已过期的时间戳。

显然，有些地方不对劲。由于双重签名的db.example.com.signed.signed文件似乎不对劲，而且db.example.com.signed从未自动更新过，所以我想，啊哈！我不应该手动签名！所以我回去编辑区域文件，内容如下：

zone "example.com" in {
   file "/etc/bind/zones/db.example.com";  # oh, maybe use this, the unsigned zone
   # file "/etc/bind/zones/db.example.com.signed"; # manual signing must be wrong.
   ...
};

但是如果我使用上述方法，启动和停止 bind9 或发出 rndc 命令的组合都无法使事情正常进行：没有签名，区域不会得到服务，也没有错误。这包括rndc sign example.com似乎什么也没做的尝试：没有错误，没有消息，没有对正在提供的内容进行任何更改。

我当然可以通过将手册粘贴dnssec-signzone到 crontab 文件中来解决上述问题，但这似乎回避了“自动签名”的整个要点。这里出了什么问题？我做错了什么？

这是named -v版本BIND 9.11.3-1ubuntu1.14-Ubuntu。

答案1

您的问题是您的区域配置启用了该inline-signing选项。

根据ISC：

随着 BIND 9.9 的发布，ISC 为 BIND 9 引入了新的“内联签名”选项，允许命名者完全透明地对区域进行签名。服务器可以加载或传输未签名的区域，并创建其签名版本以回答所有查询和传输请求，而无需更改原始未签名版本。

因此，BIND 期望file区域配置中的选项是未签名的文件，然后它会透明地为您签名和管理该文件。

答案2

我发现了一个“核选项”，它似乎可以将系统恢复到与文档一致的状态。它包括以下步骤：

service bind9 stop

在我们处理事务时暂停守护进程。其他名称服务器将弥补不足。

接下来，删除自动生成/缓存的文件：

rm -r /var/cache/bind/*

此目录包含各种自动生成的文件。这些文件似乎包含过时的数据，会干扰区域文件的解释和 ZSK/KSK 状态（即包含不适当的缓存值）。这些文件将在启动时重新创建。

接下来，编辑全部区域文件（不只是其中的一些！），并将序列号增加 50 到 100。此数字需要足够大，以避免潜在的投诉malformed transaction, last serial != transaction first serial。这个大增量可能需要多次执行。

编辑 全部区域文件，将所有$INCLUDE语句转换为使用绝对路径，而不是相对路径。虽然相对路径对于未签名的区域来说工作得很好，但似乎当区域被签名时，相对路径会被误解（这bind9对我来说就像一个错误……很难看出它为什么会很重要。）。

在中还发现了更多自动生成/缓存的文件/etc/bind/zones；这些文件应该被删除。

rm *.signed *.jnl *.jbk

这些文件将在服务器启动时全部重新创建。它们包含导致虚假错误的缓存信息（例如旧序列号）。

做不是使用dnssec-signzone。这不是必需的，并且使用它会生成与自动区域签名相冲突的文件。

最后，重新启动服务器。

service bind9 start

以上内容似乎足以清除不一致的缓存数据，并且目前似乎正在生成有效的签名区域。需要一些 TTL 和翻转才能查看是否继续正常工作。至少就目前而言，对我来说，行为与文档和“常识”一致。

相关内容