24 Zář
2021
24 Zář
'21
13:14
Hi dear knot users,
Back again with a yet another question on the same subject. Hopefully
this time the last one...
We are a sub domain: sub.company.com, and in order to eanble DNSSEC, I
need to enable DNSSEC on our knot zone sub.company.com, and send the DS
key to company.com DNS admins for publication in the parent.
My goal is to minimize the time between enabling DNSSEC and having our
DS key published in the parent zone.
As it turns out, is it incredibly difficult for company.com DNS admins
to schedule a date/time to do this 'in sync' with us.
The parent zone is now asking me to simply enable DNSSEC, and send them
the DS keys. They will then submit a support request for that already
active DS key to be published into the company.com DNS.
Thing is: They are not sure how quickly that support request would be
processed. So we could potentially face a significant amount of time
(hours, days) of running knot with DNSSEC, without the DS key publised
at the parent.
(so basically: a broken chain of trust situation)
My question: How disastrous (if at all) would that be? What consequences
(if any) to expect?
Or is there perhaps another approach at this that we fail to see?
(other than asking company.com to change their dns hosting)
(I was thinking perhaps: quickly enable dnssec, take note of the
generated DS key, disable dnssec again, sent the DS key to parent, wait
for it to become published, and then re-enable dnssec on knot)
Enjoy your weekends everybody!
MJ
Op 31-08-2021 om 12:04 schreef mj:
ok, good to know!
Thanks (again!) for the quick reply!
MJ
Op 31-08-2021 om 12:01 schreef Daniel Salzman:
> Hi,
>
> The extra white space is just a redundant separation of a long hex
> string. You can ignore it.
>
> Daniel
>
> On 8/31/21 11:49 AM, mj wrote:
>> Hi,
>>
>> We have a (hopefully last) follow-up question on the knot-generated
>> dnssec keys for our domain.
>>
>> Our policy is is set to algorithm: ECDSAP256SHA256. Upon knot start,
>> knot generates the key:
>>
>>> knotd[25835]: info: [company.com.] DNSSEC, key, tag 54011, algorithm
>>> ECDSAP256SHA256, KSK, public, ready, active+
>>> knotd[25835]: info: [company.com.] DNSSEC, key, tag 49404, algorithm
>>> ECDSAP256SHA256, public, active
>>> knotd[25835]: info: [company.com.] DNSSEC, signing started
>>
>> Then we query the DS key to be published, the result is:
>>
>>> keymgr company.com ds
>>> company.com. DS 54011 13 2
>>> f0892debae240caa01827becdd3d3cb0ef2512f5691ca525895777571a67e680
>>> company.com. DS 54011 13 4
>>>
462211ea3e8d3ea19a2ae803b926af8df851369527879911318f59ff72973a72452e3f29265c339c6a61537a778c43da
>>>
>>
>>
>> Now the question. In most (if not all?) docs we read on the subject,
>> the DS key looks something like:
>>
>>> knot-dns.cz. 3600 IN DS 54959 13 2
>>> 268DE6EB7E0630953B8AF0F0037BF68FD10443BF01B5E17805AF94C2 6921897D
>> or
>>> dnssec-tools.org. 21600 IN DS 9638 13 2
>>> 92551AA25C4ADE8E2882FBF4BEB5B54F9D84379B153848852B68BB3C 793F4B0B
>>
>> note the spaces at the end of the key string.
>>
>> Our knot-generated DS key does not have a space in it.
>>
>> Is something wrong? Do we need to add a space somewhere, or..?
>>
>> Thanks again in advance for providing insight :-)
>>
>> MJ