![DNSSEC 自动签名并非自动的](https://linux22.com/image/765694/DNSSEC%20%E8%87%AA%E5%8A%A8%E7%AD%BE%E5%90%8D%E5%B9%B6%E9%9D%9E%E8%87%AA%E5%8A%A8%E7%9A%84.png)
我无法让 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
选项。
随着 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 和翻转才能查看是否继续正常工作。至少就目前而言,对我来说,行为与文档和“常识”一致。