tsig zone sharing between zones check + scream
Heiko Richter
email at heikorichter.name
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-----
More information about the bind-users
mailing list