do not stupidly delete ZSK files

[David Newman]

On 7/30/15 9:06 AM, Evan Hunt wrote:
> 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.

Sorry, I also didn't mention that this is a hidden primary server, which
may be relevant below...

> 
> 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.

Thanks for this.

After that second procedure (and also chown'ing the keyfiles to the bind
user), the command 'dig +dnssec +multi dnskey example.com' gives
different results depending on which nameserver gets the query:

Hidden primary (not authoritative for this zone): Key still in zone

Authoritative server for zone: Key not in zone

Google's recursive server: Key not in zone

Even after moving those 36114 key files into another directory and
rerunning 'rndc loadkeys example.com', the hidden primary still thinks
36114 is a valid key for this zone.

Is there some other step needed to remove it on the hidden primary?

Thanks again!

dn