15 Srp
2018
15 Srp
'18
19:02
Dear all,
I use knot 2.7.1 with automatic DNSSEC signing and key management.
For some zones I have used "cds-cdnskey-publish: none".
As .CH/.LI is about to support CDS/CDNSKEY (rfc8078, rfc7344) I thought
I should enable to publish the CDS/CDNSKEY RR for all my zones. However,
the zones which are already secure (trust anchor in parent zone) do not
publish the CDS/CDNSKEY record when the setting is changes to
"cds-cdnskey-publish: always".
I have not been able to reproduce this error on new zones or new zones
signed and secured with a trust anchor in the parent zone for which I
then change the cds-cdnskey-publish setting from "none" to "always".
This indicates that there seems to be some state error for my existing
zones only.
I tried but w/o success:
knotc zone-sign <zone>
knotc -f zone-purge +journal <zone>
; publish a inactive KSK
keymgr <zone> generate ... ; knotc zone-sign <zone>
Completely removing the zone (and all keys) and restarting fixes the
problem obviously. However, I cannot do this for all my zones as I would
have to remove the DS record in the parent zone prior to this...
Any idea?
Daniel
15 Srp
15 Srp
20:26
Any idea?
I found a fix. I noticed a difference in the "keymgr" output for zones
which publish CDS/CDNSKEY and for zones which don't.
Zones not showing the CDS/CDNSKEY have "ready=0" in the output of:
keymgr <zone> list
Changing "ready=0" to some value e.g. now and resigning the zone fixes
the problem and publishes the CDS/CDNSKEY record.
Fix:
keymgr <zone> set <key_spec> ready=1534356842
kzonec zone-sign <zone>
If I manually create a key it has ready set to 0, e.g.:
keymgr <zone> generate algorithm=13 ksk=yes zsk=yes
keymgr <zone> list
1ae97d2478865aad20148abcb0a02a59748dad6a ksk=yes zsk=yes tag=64141
algorithm=13 public-only=no created=1534357158 pre-active=0
publish=1534357158 ready=0 active=1534357158 retire-active=0 retire=0
post-active=0 remove=0
....
I can't remember how the keys for my old zones have been created. In any
case, I guess it should be sufficient to publish the "CDS/CDNSKEY"
records if "publish" is set to some value in the past. Is this a bug?
Daniel
21 Srp
21 Srp
16:31
Hi Daniel,
Dne 15.8.2018 v 20:26 Daniel Stirnimann napsal(a):
Changing "ready=0" to some value e.g. now
and resigning the zone fixes
the problem and publishes the CDS/CDNSKEY record.
Fix:
keymgr <zone> set <key_spec> ready=1534356842
kzonec zone-sign <zone>
Good point. You can also use some relative scale like ready=-1h
If I manually create a key it has ready set to 0, e.g.:
keymgr <zone> generate algorithm=13 ksk=yes zsk=yes
keymgr <zone> list
1ae97d2478865aad20148abcb0a02a59748dad6a ksk=yes zsk=yes tag=64141
algorithm=13 public-only=no created=1534357158 pre-active=0
publish=1534357158 ready=0 active=1534357158 retire-active=0 retire=0
post-active=0 remove=0
....
Hmm, my guess is that "ready" should be in this case automatically set
to the same value as "active", since "active" state comes after
"ready".
I can't remember how the keys for my old zones have been created. In any
case, I guess it should be sufficient to publish the "CDS/CDNSKEY"
records if "publish" is set to some value in the past. Is this a bug?
In the "publish" state, the key is not yet usable as there may be caches
caching old keysets. So publishing CDS/CDNSKEY in "ready" state is the
right thing to do.
I think it is a bug not to set "ready" key tag to the same value as
"publish" and "active" tags during manual key generation, though.
--
Ondřej Caletka
CESNET
22 Srp
22 Srp
15:07
Hi Ondřej,
This topic has moved to https://gitlab.labs.nic.cz/knot/knot-dns/issues/605
Best,
Daniel
On 08/21/2018 04:31 PM, Ondřej Caletka wrote:
Hi Daniel,
Dne 15.8.2018 v 20:26 Daniel Stirnimann napsal(a):
Changing "ready=0" to some value e.g.
now and resigning the zone fixes
the problem and publishes the CDS/CDNSKEY record.
Fix:
keymgr <zone> set <key_spec> ready=1534356842
kzonec zone-sign <zone>
Good point. You can also use some relative scale like ready=-1h
If I manually create a key it has ready set to 0, e.g.:
keymgr <zone> generate algorithm=13 ksk=yes zsk=yes
keymgr <zone> list
1ae97d2478865aad20148abcb0a02a59748dad6a ksk=yes zsk=yes tag=64141
algorithm=13 public-only=no created=1534357158 pre-active=0
publish=1534357158 ready=0 active=1534357158 retire-active=0 retire=0
post-active=0 remove=0
....
Hmm, my guess is that "ready" should be in this case automatically set
to the same value as "active", since "active" state comes after
"ready".
I can't remember how the keys for my old zones have been created. In any
case, I guess it should be sufficient to publish the "CDS/CDNSKEY"
records if "publish" is set to some value in the past. Is this a bug?
In the "publish" state, the key is not yet usable as there may be caches
caching old keysets. So publishing CDS/CDNSKEY in "ready" state is the
right thing to do.
I think it is a bug not to set "ready" key tag to the same value as
"publish" and "active" tags during manual key generation, though.
--
Ondřej Caletka
CESNET
2631
days inactive
2638
days old
3 comments
3 participants
participants (3)
-
Daniel Salzman -
Daniel Stirnimann -
Ondřej Caletka