9.7.0rc1 auto-dnssec control of RRSIG generation
Johan Ihren
johani at autonomica.se
Wed Feb 10 15:24:33 UTC 2010
All,
I lost this thread about a month ago. I'm sorry...
On 4 Jan 2010, at 02:40, Evan Hunt wrote:
>> why is auto-dnssec only available for zones that are automatically updated?
>
> Because it works by automatically updating the zone. :)
;-)
>> But re-signing is also needed for static zones and to me it seems that a
>> timer that wakes up the re-signing urge on a suitable clock would be an
>> obvious thing.
>
> ...in which case it *isn't* a static zone: the RRSIGs are changing.
Sure.
> It's certainly possible to have a cron job periodically running
> dnssec-signzone and issuing "rndc reload", but it's easier to have
> named keep track for you.
My point exactly. Just as I can have a cron job do "rndc freeze" + bump the SOA serial + "rndc thaw". An ugly hack, would be much better to have named keep track for me.
> But that means the zone is no longer static;
> it's under the control of named. You can't just edit the zone file by
> hand; you must either do the freeze-edit-thaw dance, or use DDNS updates.
Agreed.
> In a DNSSEC world, I believe it makes the most sense to treat nearly all
> zones as dynamic. (That's why we added "update-policy local;" as a new
> feature in 9.7. The goal of the release is to make it easier to configure
> DNSSEC. I felt that making it easier to configure DDNS would be a
> necessary piece of that.)
All this is fine, but I still don't really see why I should have to fake DDNS updates to trigger re-signing of a static zone. I get that the RRSIGs are changing and that it is mostly a semantic discussion whether the zone is static or not, but I think you understand what I mean.
Regards,
Johan
More information about the bind-workers
mailing list