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 _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users