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