tsig zone sharing between zones check + scream

Lawrence K. Chen, P.Eng. lkchen at ksu.edu
Sat Aug 8 01:06:49 UTC 2015



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


More information about the bind-users mailing list