In message <52bdee40.2070...@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: ma...@isc.org _______________________________________________ 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