bind makes RRSIG disappear?

[Evan Hunt]

> Thanks, this works indeed.
> 
> This raises a few questions, as I'd really like to understand bind's
> behavior:
> 
> - is there any description of exactly how/when Bind assumes signing
> authority over a zone? Or simply where some kind of zone-manipulating
> intelligence kicks in?
> 
> - is it possible to disable this kind of intelligence (possibly at
> compile time)?
> 
> - if not: a config switch (or compile-time option) would really be
> appreciated. The zone option "auto-dnssec off;" did not prevent bind
> from trying to sign the zone.

BIND will try to maintain the signatures in a zone if the zone is
configured to be dynamic--i.e, if it has an update-policy or allow-update
option.  It won't create signatures where there were none, but it will try
to keep existing RRSIGs up to date for you.

In this case, there's a bug where it thinks "update-policy { none; };"
counts as an update-policy statement.  So, the zone isn't dynamic and
shouldn't be re-signed, but named was confused and thought it was and
should.  This will be fixed in future releases.

The "auto-dnssec" option relates to automated changes based on timing
metadata stored with the key.  For example, you can schedule a key to be
published on a certain date, and named will insert the DNSKEY record into
the zone at the right time; or, you can schedule a key to become active,
and named will start signing with it.  But routine RRSIG maintenance
happens in *any* dynamic zone, with or without "auto-dnssec".

Having RRSIGs disappear from a zone when there's no private key available
for re-signing is probably a problem (at least, it would seem to violate
the principle of least astonishment).  I'll look into that.

-- 
Evan Hunt -- each at isc.org
Internet Systems Consortium, Inc.