key type change causing errors

[Alan Batie]

I've been using bind 9.9 to do inline signing for a while
experimentally.  The keys were initialized with a basic "dnssec-keygen
$zone_name".  I decided to upgrade the keys from sha1 to sha256 and from
nsec to nsec3; using the instructions at
https://kb.isc.org/article/AA-00711 I moved all the old keys out and
regenerated then with "dnssec-keygen -a RSASHA256 -b 2048 -3
$zone_name", then ran the "rndc loadkeys $zone_name" and "rndc signing
-nsec3param 1 0 10 $random_salt $zone_name" commands given, for each of
the domains.

Several problems have now appeared after restarting named:

1.  The log file is spewing "dns_dnssec_findzonekeys2: error reading
private key file <domain>/RSASHA1/57843: file not found"

2.  Why is it apparently still doing sha1 when I believe I told it to
use sha256 with the keygen command.

3.  It is still generating NSEC records, not NSEC3 records

I've moved the old keys back and the spewing stopped, but there is one
test domain that was generating that "file not found" error even before
this attempt, even though the key is there with the rest of them
(key-directory "/var/named/keys";), so I clearly don't understand what
the error is trying to tell me...  The number doesn't match so I wonder
if that's a clue?

Dec 27 13:06:58 ns6 named[20141]: zone ghat.peak.org/IN (signed):
sending notifies (serial 2013060537)
Dec 27 13:06:58 ns6 named[20141]: dns_dnssec_findzonekeys2: error
reading private key file ghat.peak.org/RSASHA1/43536: file not found

<ns6.peak.org> [475] # lf -l *ghat*
-rw-r--r-- 1 named named  435 Dec 27 13:06 Kghat.peak.org.+005+10701.key
-rw------- 1 named named 1010 Dec 27 13:06 Kghat.peak.org.+005+10701.private

By "number doesn't match", I mean 43536 vs 10701, which I believe is the
"key tag", but not sure where it would be getting the wrong one from?

Thanks for any pointers...

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4249 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20131227/ceda6ef9/attachment.bin>