-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 08.08.2015 um 03:06 schrieb Lawrence K. Chen, P.Eng.: > > > On 2015-08-07 10:08, Heiko Richter wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> Am 07.08.2015 um 08:52 schrieb Lawrence K. Chen, P.Eng.: >>> Grrrr....just noticed that about 12 hours ago, the business >>> office person finally update our KSK with registrar. (where >>> window was last month.) >>> >>> Well, apparently history must repeat.... >>> >>> 3 years ago, we rolled over from RSASHA256 to RSASHA256... but >>> the person that did all the interaction with >>> registrars....where the criteria is that they be in position >>> to pay as needed (which did used to be dns >>> administrator/department manager/etc....but when they left the >>> new manager he didn't want us to continue to have that >>> responsibility...but would've taken it...anyhoo) They >>> selected algorithm type as RSASHA1-NSEC3... >>> >>> Which caused a bit of an outage, especially since they went on >>> vacation right after having left it to the last minute. we >>> had a 60 day rollover window)...original I had gone around end >>> of fiscal year, but decided to shift it... >>> >>> >>> Well, this time....still going RSASHA256 to RSASHA256.... (I >>> had done the roll from RSASHA1-NSEC to RSASHA256 before it was >>> possible to register do such things with registrar...so only >>> DLV was involved....though I did run into a problem since I >>> had a DS record in my zone, etc. the mismatch doing one than >>> the other apparently was the wrong way to go...or soemething.) >>> >>> So this time...RSASHA1 (#5) got selected. >>> > >> If you change the algorithm of your KSK it shoudn't be necessary >> to change your server's configuration. Neither is it necessary >> to change the TSIG keys. >> >> Just dump the keys into your domain's key-directory and bind will >> eventually import and use them. If you're in a hurry, you can >> force the import by running rndc loadkeys >> >> Of course you will also need to retire your old key and remove >> them from the zone by running dnssec-keygen -D now -I now >> >> And you should (should, not must!) generate new ZSKs, using the >> same algorithm, so change your ZSK-rollover-script to generate >> RSASHA1 from now on. >> >> But looking at your algorithm you will have a slight problem, >> which you need to take care of, BEFORE you publish your new key: >> RSASHA1 is not NSEC3-aware. So if you decide to run with that >> key, you have to remove the NSEC3-parameters from your zone (if >> you have any). >> > > The TSIG stuff is related to a separate issue I'm trying to resolve > caused by upgrading to 9.9.7-P2. > > While for KSK, I have no intention of change my algorithm, in > violation of previous rulings by Chief Info Security Officer.... > just because the business office staff person had changed the > algorithm we use when putting up the new DS I had forwarded up to > get set with our registrar. No error was made when DS was added > for our other domain done at the same time. > > I sure wish there was an automated way to do our KSK > rollovers....especially if they want to do DNSSEC for the 100's of > other domains we serve. > There are a few registrars available that support api access for changing KSKs. > But, on second try today, it got fixed. (though I suspect the > first was valid, but differed from how k-state.edu got done. > > Also not sure what the implications are. That I sent two DS > records (per domain) up. And, only the SHA-1 has been entered. > Today in fixing the RSASHA1 + SHA1 entry, it was first replaced as > being RSASHA256 + SHA256, but then replaced with SHA-1 digest > version (though the SHA256 attempt might have been a real error? > Nope...the last 4 digits match the SHA256 DS....) > > What's odd is that in all cases, the confirmation email says > "DNSKEY was Verfied" I'd expect that with the two tries today, > but how was that possible when they had selected the wrong > algorithm? Hmmm, wonder if all they're 'verifying' is the key id? > You are not done completely.The DS for your new key has been published in .edu tld. But there is still a DS record for your old KSK there that must be removed. You can check the status here: http://dnsviz.net/d/k-state.edu/dnssec/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJVxcipAAoJECKEz6pWghImqBwP/A+ExDiOZKrMOP9zIPYNwokn YH8vuIodl3I69tVFBT2S7LdzflhH22kl7+lY4QI7W5aV2RtbANI73MdhDC1ppq1r UxmWyV3eHpHvp4Eh3Z7AC4rHrpmVAEkEj7XAHQQ6jvQt2dogRoSWlPFyh1CsNNUX Vo6xIbBjI1e5sCqObl8JA4in7INrKaMfgTLai7FIyHChpYdbc8/UvJxfMGTPwDyi 5tRzoNj4Zg8WUMrmWfJdmS6cZ3VghZFve9xn8cEI1eVXmUWcgCbIvAS09yr167gA 5ZH0E2I4o91Gs+IXTs46BsQ48xTqt4PXT5ReFcwPkmFZ2Lts+17skV5QVqgfNqHs 8ZfzmXnhGXXdjK9Pba/i0E+fCP3yJERGvqyNMY0MbLjN17JQjCcQ8WsubOpgKcP6 Ga9AyTl9+1NAuQ2qGxfucfPLwGKCD4H9ReYRaBqSJ+zd/gZGgXvwTx+43GpcoWMR Fxvd4Mb1Oy8RJizRX83s0ePhZthHDBUoWhL7tg5MpX1ukSS2DeWmt8eTE5ruH33b /67lRnWGmc1wtPpInvHQ6y/9DkquqTUu+fRE0lJ+xqb+kEgzUh4/mYR+LiYTRogR VyWoQ44En01E81OHGFqB3V2zkCMXECbVIJ5VQLXNsjnFXyVgvkDEc4CJ1F2Up0u4 rvWkm3Cl2H6IC0++9wJ8 =qlZZ -----END PGP SIGNATURE----- _______________________________________________ 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