> 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 -- e...@isc.org
Internet Systems Consortium, Inc.
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
