key type change causing errors

[Mark Andrews]

In message <52BDEE40.2070701 at peak.org>, Alan Batie writes:
> 
> 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.priv=
> ate
> 
> 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...

https://kb.isc.org/article/AA-00711 shows how to *start* doing DNSSEC.

It does *not* describe how to do a DNSSEC key algorithm roll which is
what you were attempting to do.

As for "ghat.peak.org/RSASHA1/43536: file not found", 43536 is the
key id of key currently in the zone.

; <<>> DiG 9.10.0a1 <<>> +multi dnskey ghat.peak.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31897
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ghat.peak.org.		IN DNSKEY

;; ANSWER SECTION:
ghat.peak.org.		377 IN DNSKEY 256 3 5 (
				AwEAAbyY10qxfkSX09VZDXaXIUYmF7qgOQQp8/oi9W4G
				s/71bom35cUrWia0k4K+7HKJ9H/Sgz/C8fZf90ssfJeg
				El37c0fnGFVkfN9aIR4za128O+bVeY8TZ1jsAWGfPhjX
				OumW9i8WGOtdye7BtS3Z1aAIPJrlbdmnMVmSUWR3LJaH
				) ; ZSK; alg = RSASHA1; key id = 43536

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Dec 28 13:57:32 EST 2013
;; MSG SIZE  rcvd: 190

To do a DNSKEY algorithm roll you need to introduce the new keys
with the new algorithm then use dnssec-settime to tell named to
stop using the old keys.  You also need to ensure that DS records
are properly managed while this is happening and that the timing
of all these events are correct.

The DS records have to be removed from the parent zone and have to
expired from caches before you can remove the corresponding DNSKEY
records.

If you don't want the zone to be treated as insecure you need to
ensure that DS records for the new algorithm are published and
all of the old DS RRsets have expired from cachess before you
start to remove the old DS records.

Before you publish the new DS records you need to ensure that all
cached responses have RRSIGs for both algorithms or else validating
of answers from a cache may fail.

There are more timing constraints than these.   If there are trust
anchors for the zones in config files these also need to be accounted
for.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org