do not stupidly delete ZSK files

[Evan Hunt]

On Wed, Jul 29, 2015 at 07:29:29PM -0700, David Newman wrote:
> It's a static zone. The zone file did not have the key in it.

... oh, it's inline-signing.

Unfortunately, by its nature, inline-signing gives you less direct
control over the signed side of the zone.

There are two ways you can go go:

First, since this appears to be an example zone, you could blow away the
signed zone entirely: "rm -f example.com.db.signed.*". Start named over
again and it'll recreate the signed zone from scratch, this time without
the key in it.

Or second, if it's important to preserve the signed zone, then you can
create new key files from the zone contents, then set the broken key to
be deleted while other keys remain in place.

$ cd /tmp
$ dig @localhost dnskey example.com | dnssec-importkey -f - example.com
$ dnssec-settime -D now Kexample.com.+007+36114.key
$ mv Kexample.com.+007+35114.* /path/to/key/directory
$ rndc loadkeys example.com

"dnssec-importkey" creates a pair of key files containing the public key,
but with the private key data omitted; named can't use it for signing
data, but it can use it for determining what changes to make in the DNSKEY
rrset.  "dnssec-settime" sets the timing metadata for the key so that named
will delete it next time it reads the key file. "rndc loadkeys" tells
it to read the file.

The key should be deleted from the zone now, and you can remove the
key files safely.

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