15 Pro
2021
15 Pro
'21
20:18
OK I recently decided to change the algorithm on all our domains
from RSASHA1 to RSASHA256. Before making the change globally; I
experimented with one domain. I did so by adding a new policy:
CURRENT
policy:
- id: rsa1
algorithm: RSASHA1
ksk-size: 2048
zsk-size: 1024
dnskey-ttl: 43200
zsk-lifetime: 30d
ksk-lifetime: 365d
NEW (PROPOSED)
policy:
- id: rsa2
algorithm: RSASHA256
ksk-size: 2048
zsk-size: 2048
dnskey-ttl: 43200
zsk-lifetime: 30d
ksk-lifetime: 365d
DOMAIN TESTED ON
# a-domain
- domain: a-domain
file: "masters/a-domain"
zonefile-load: difference
dnssec-signing: on
# dnssec-policy: rsa1
dnssec-policy: rsa2
semantic-checks: on
serial-policy: dateserial
acl: [locals, remotes01, remotes03, remotes04]
To preform the intended change. I first set the the current keys on the
test domain to: retire=+1hr
I then added the new policy and assigned it to the testing domain. Then
restarted the knot service. After the hour and some had passed. I performed a
keymgr a-domain del-all-old which removed the old algorithm (RSASHA1) keys.
But I think this was a mistake.
How would I best make this change? Is it enough to simply change algorithm:
and knot will just do the right thing?
Thanks!
-- Chris
15 Pro
15 Pro
22:01
On 15/12/2021 20:18, Chris wrote:
Hi Chris,
[snip config details]
How would I best make this change? Is it enough to
simply change algorithm:
and knot will just do the right thing?
Yes, please! Just change the algorithm and let Knot do its thing. It
will do the right thing. Please do *not* fiddle with things manually.
DNSSEC is complex, and algorithm roll-overs require care. The developers
of Knot have put in a lot of care into handling algorithm roll-overs.
Trust their expertise.
Regards,
Anand
22:28
On 2021-12-15 13:01, Anand Buddhdev wrote:
On 15/12/2021 20:18, Chris wrote:
Hi Chris,
[snip config details]
Thanks for the
reply, Anand! :-)
I'm well aware of all the complexities, and am well confident in knots
abilities
to DTRT. But "stuff" happens. fe; after creating the additional policy
some of the zones are _also_ adopting that new policy as _well_ as the
original
policy. IOW there are some zones with both RSASHA1 _and_ RSASHA256 hashes in
them.
config (diffs):
policy:
- id: rsa1
algorithm: RSASHA1
zsk-size: 1024
policy:
- id: rsa2
algorithm: RSASHA256
zsk-size: 2048
ALL zones but the test zone mentioned earlier:
- domain: domain.name
...
dnssec-signing: on
dnssec-policy: rsa1
So why do (some) zones arbitrarily pick up the added policy when it
it is not the policy declared within the domain block?
IOW dnssec-policy: rsa1 is the only dnssec-policy listed within all the
domain blocks, and it's listed within all of the domain blocks, save
the earlier test domain. So "stuff" happened. :-/
Thanks again, for taking the time to respond, Anand.
-- Chris
How would I best make this change? Is it enough
to simply change algorithm:
and knot will just do the right thing?
Yes, please! Just change the algorithm and let Knot do its thing. It will do
the
right thing. Please do *not* fiddle with things manually. DNSSEC is complex,
and
algorithm roll-overs require care. The developers of Knot have put in a lot
of
care into handling algorithm roll-overs. Trust their expertise.
Regards,
Anand
16 Pro
16 Pro
8:44
Hi Chris,
On 12/15/21 10:28 PM, Chris wrote:
On 2021-12-15 13:01, Anand Buddhdev wrote:
One zone cannot use more DNSSEC policies! I think you are confused by ongoing algorithm
rollover when there are both algorithms present in the zone (see
https://datatracker.ietf.org/doc/html/rfc6781#section-4.1.4).
On 15/12/2021 20:18, Chris wrote:
Hi Chris,
[snip config details]
Thanks for the
reply, Anand! :-)
I'm well aware of all the complexities, and am well confident in knots abilities
to DTRT. But "stuff" happens. fe; after creating the additional policy
some of the zones are _also_ adopting that new policy as _well_ as the original
policy. IOW there are some zones with both RSASHA1 _and_ RSASHA256 hashes in them.
How would I best make this change? Is it enough
to simply change algorithm:
and knot will just do the right thing?
Yes, please! Just change the algorithm and let Knot do its thing. It will do the
right thing. Please do *not* fiddle with things manually. DNSSEC is complex, and
algorithm roll-overs require care. The developers of Knot have put in a lot of
care into handling algorithm roll-overs. Trust their expertise.
config (diffs):
policy:
- id: rsa1
algorithm: RSASHA1
zsk-size: 1024
policy:
- id: rsa2
algorithm: RSASHA256
zsk-size: 2048
ALL zones but the test zone mentioned earlier:
- domain: domain.name
...
dnssec-signing: on
dnssec-policy: rsa1
So why do (some) zones arbitrarily pick up the added policy when it
it is not the policy declared within the domain block?
Isn't it possible that the policy is declared in a zone template?
Daniel
IOW dnssec-policy: rsa1 is the only dnssec-policy
listed within all the
domain blocks, and it's listed within all of the domain blocks, save
the earlier test domain. So "stuff" happened. :-/
Thanks again, for taking the time to respond, Anand.
-- Chris
>
> Regards,
> Anand
9:40
On 2021-12-15 23:44, Daniel Salzman wrote:
(technically)
answered above. But no. I define the DNSSEC policy separately.
Give it an id, then use the id within each domain/zone block.
Thanks for the reply, Daniel. :-)
-- Chris
Hi Chris,
On 12/15/21 10:28 PM, Chris wrote:
I don't think so.
But I think I'm probably saying it incorrectly.
Somehow after creating an additional policy "template" that defines RSASHA256
and a 2048 ZSK size. A couple of zones added 8/2 algo/digest to the 5/2
also/digest.
Which suggests to me that those zones arbitrarily picked up the new rsa2 I
added.
Even though the zone template for all the zones only state rsa1.
I'm nopt quite sure what to make of it. So I'll just freeze the offending
zones
and purge the history on them and recreate/sign them. I had intended to
convert them
all to the new RSASHA256 (rsa2) profile template anyway. Just hadn't intended
to do
it in the manner. ;-)
On 2021-12-15 13:01, Anand Buddhdev wrote:
One zone cannot use more DNSSEC policies! I think you are confused by
ongoing algorithm
rollover when there are both algorithms present in the zone (see
https://datatracker.ietf.org/doc/html/rfc6781#section-4.1.4). On 15/12/2021 20:18, Chris wrote:
Hi Chris,
[snip config details]
Thanks for the
reply, Anand! :-)
I'm well aware of all the complexities, and am well confident in knots
abilities
to DTRT. But "stuff" happens. fe; after creating the additional policy
some of the zones are _also_ adopting that new policy as _well_ as the
original
policy. IOW there are some zones with both RSASHA1 _and_ RSASHA256 hashes
in them. How would I best make this change? Is it enough
to simply change
algorithm:
and knot will just do the right thing?
Yes, please! Just change the algorithm and let Knot do its thing. It will
do the
right thing. Please do *not* fiddle with things manually. DNSSEC is
complex, and
algorithm roll-overs require care. The developers of Knot have put in a
lot of
care into handling algorithm roll-overs. Trust their expertise.
config (diffs):
policy:
- id: rsa1
algorithm: RSASHA1
zsk-size: 1024
policy:
- id: rsa2
algorithm: RSASHA256
zsk-size: 2048
ALL zones but the test zone mentioned earlier:
- domain: domain.name
...
dnssec-signing: on
dnssec-policy: rsa1
So why do (some) zones arbitrarily pick up the added policy when it
it is not the policy declared within the domain block?
Isn't it possible that the policy is declared in a zone template?
Daniel
> IOW dnssec-policy: rsa1 is the only dnssec-policy listed within all the
> domain blocks, and it's listed within all of the domain blocks, save
> the earlier test domain. So "stuff" happened. :-/
>
> Thanks again, for taking the time to respond, Anand.
>
> -- Chris
>>
>> Regards,
>> Anand
12:25
Hi Chris,
thank you for using Knot DNS, as well as for migrating to some better
DNSSEC algorithm :)
Despite an algorithm rollover can be performed very easily with Knot
DNS, it's not an easy process by itself and it's needed to first
understand it in general.
Algorithm rollover has several steps and there are necessary delays
between them, so it will probably take much more than an hour.
When you try for the first time, I would recommend to start with much
simpler ZSK rollover, than KSK rollover, and once you get familiar,
you'll be able to handle algorithm rollovers easily.
It's not recommended to modify your keys manually with keymgr while
automatic key management is doing things. And `del-all-old` feature is
only intended for special Offline KSK setup.
It might also surprise you that reverting the configuration does not
always lead to reverting the state. For example, if you trigger an
algorithm rollover by changing the configuration, the process will
start, and if you revert the configuration at that stage, I'm not sure
what will happen, but probably not a flawless return to the original
algorithm.
A final hint: use https://dnsviz.net/ to check your zone state.
Libor
18:00
On 2021-12-16 03:25, libor.peltan wrote:
Hi Chris,
thank you for using Knot DNS, as well as for migrating to some better DNSSEC
algorithm :)
Despite an algorithm rollover can be performed very easily with Knot DNS,
it's not
an easy process by itself and it's needed to first understand it in general.
Algorithm rollover has several steps and there are necessary delays between
them,
so it will probably take much more than an hour.
When you try for the first time, I would recommend to start with much
simpler ZSK
rollover, than KSK rollover, and once you get familiar, you'll be able to
handle
algorithm rollovers easily.
It's not recommended to modify your keys manually with keymgr while
automatic key
management is doing things. And `del-all-old` feature is only intended for
special
Offline KSK setup.
It might also surprise you that reverting the configuration does not always
lead
to reverting the state. For example, if you trigger an algorithm rollover by
changing the configuration, the process will start, and if you revert the
configuration at that stage, I'm not sure what will happen, but probably not
a
flawless return to the original algorithm.
Thank you very kindly for your
informative reply, Libor. :-)
FWIW I've switched to knot some 2 years ago. I was able to import all my bind
keys w/o problem -- thanks for the great docs. :-)
Since then I have added some 160 additional domains. Knot performed well w/o
incident.
It was enough to add an unsigned zone file and declare:
dnssec-signing: on
dnssec-policy: <the policy>
and it just worked. :-)
It appears that what I *should* have done; is simply changed (after defining)
the
dnssec-policy: and *assume* knot would know what I meant and DTRT. But I errd
on
the side of caution, and failed at testing what would/should happen.
A final hint: use https://dnsviz.net/ to check your zone state.
Funny you should
say...
I do use that link as well as others to attempt to obtain an "objective" view
of the overall "health" of some of my zones. In fact it was a trip to:
https://www.zonemaster.net that set this whole "adventure" off for me.
It complained about the 1024b size of my ZSK key(s). Which reminded me that
I had started out conservatively to ensure the broadest compatibility. But
that
that was probably too conservative for this day-and-age. :-) I also find:
https://dnssec-debugger.verisignlabs.com
a nice utility.
Thank you again, Libor. For the thoughtful reply. :-)
-- Chris
Libor
872
days inactive
873
days old
6 comments
4 participants
participants (4)
-
Anand Buddhdev -
Chris -
Daniel Salzman -
libor.peltan