tsig zone sharing between zones check + scream

Sat Aug 8 09:15:22 UTC 2015

-----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-----