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.
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?
--
Who: Lawrence K. Chen, P.Eng. - W0LKC - Sr. Unix Systems Administrator
with LOPSA Professional Recognition.
For: Enterprise Server Technologies (EST) -- & SafeZone Ally
_______________________________________________
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
