我正在用绑定9.7.2-P2testingDNSSEC。 我有一个关于在已经存在的区域上创build的第一个签名的问题。 我正在使用dynamicDNS。
我创build了前两个键：一个KSK和一个ZSK。 根据https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-key-timing/ ，第一个ZSK需要在等于Ipub的时间间隔内发布，才能被激活。
我创build的ZSK的激活date之前的发布date。 我重新启动服务，我可以看到该密钥在出版date发布，但在激活date到达时，它不会激活。
这是named.conf文件中的区域dnssec.es的configuration：
zone "dnssec.es" { auto-dnssec maintain; update-policy local; sig-validity-interval 1; key-directory "dnssec/keys_dnssec"; type master; file "dnssec/db.dnssec.es"; }; 任何线索？
问候
在这个互联网草案中讨论的时间考虑因素是当你从一个密钥滚动到另一个密钥时，为了让来自先前的ZSK的签名有时间从caching中过期。 当您首次签署区域时，没有必要预先发布ZSK。
这里发生的事情是，你告诉它只使用一个密钥KSK开始签署区域。 由于没有其他已发布的密钥，所以它用可用的密钥KSK对整个区域进行了签名。 （这是合法的DNSSEC，但不是典型的configuration，如果有一个活跃的ZSK，它将用KSK签署DNSKEYlogging，并且只用ZSK签署其他所有内容，但是它必须与提供的内容一起工作。 ）
过了一段时间，ZSK被发布（但未被激活），所以它被添加到DNSKEYlogging中，但不被用于签名。 后来ZSK确实变得活跃起来了，但是这个区域的logging已经全部签了，所以这个名字估计现在没有必要去做任何工作。 当KSK签名接近其到期时间时，它们应该被自动刷新出区域，并由现在活动的ZSK中的签名replace。 由于您将sig-validity-interval设置为一天，因此应该在明天某个时候开始。
无论如何，为了您的目的，您只需要制作两个即时发布并激活的密钥。 在您滚动密钥之前，您不需要考虑预先准备的时间间隔。
Evan（BIND 9.7的主要作者）