CDNSKEY / CDS for key is now published - but why?
Matthijs Mekking
matthijs at isc.org
Wed Oct 2 13:13:20 UTC 2024
Hi,
The change from rumoured to omnipresent is TTL dependent. To be precise:
it is the sum of the configured parent-ds-ttl, parent-propagation-delay,
and retire-safety.
- Matthijs
On 10/2/24 14:55, Danilo Godec via bind-users wrote:
> Hi Matthijs,
>
>
> thanks, that explains a bunch.
>
> I checked both domain with '/rndc dnssec -status/' and they do show
> different states:
>
> # rndc dnssec -status psihopat.si
> dnssec-policy: nsec3_no_rotate
> current time: Wed Oct 2 14:25:31 2024
>
> key: 37651 (ECDSAP256SHA256), ZSK
> published: yes - since Tue Oct 1 20:23:24 2024
> zone signing: yes - since Tue Oct 1 20:23:24 2024
>
> No rollover scheduled
> - goal: omnipresent
> - dnskey: omnipresent
> *- zone rrsig: rumoured*
>
> key: 7162 (ECDSAP256SHA256), KSK
> published: yes - since Tue Oct 1 20:23:24 2024
> key signing: yes - since Tue Oct 1 20:23:24 2024
>
> No rollover scheduled
> - goal: omnipresent
> - dnskey: omnipresent
> *- ds: hidden*
> - key rrsig: omnipresent
>
>
> # rndc dnssec -status sociopat.si
> dnssec-policy: nsec3_no_rotate
> current time: Wed Oct 2 14:25:34 2024
>
> key: 17354 (ECDSAP256SHA256), ZSK
> published: yes - since Tue Oct 1 10:09:53 2024
> zone signing: yes - since Tue Oct 1 10:09:53 2024
>
> No rollover scheduled
> - goal: omnipresent
> - dnskey: omnipresent
> - zone rrsig: omnipresent
>
> key: 61220 (ECDSAP256SHA256), KSK
> published: yes - since Tue Oct 1 10:09:53 2024
> key signing: yes - since Tue Oct 1 10:09:53 2024
>
> No rollover scheduled
> - goal: omnipresent
> - dnskey: omnipresent
> *- ds: rumoured*
> - key rrsig: omnipresent
>
>
> So I ran /rndc dnssec -checkds published**/for both zones:
>
> # rndc dnssec -checkds published sociopat.si
> Marked DS as published since 02-Oct-2024 14:33:33.000
>
> # rndc dnssec -checkds published legenda.si
> Marked DS as published since 02-Oct-2024 14:33:47.000
>
> That changed KSK DS state from *hidden* to *rumoured* for psihopat.si,
> but made no change to sociopat.si.
>
>
> Should the change be immediate or is it also TTL dependent?
>
>
>
> Regards,
>
> Danilo
>
>
>
>
> On 2. 10. 24 13:10, Matthijs Mekking wrote:
>> Hi Danilo,
>>
>> When you enable DNSSEC for the first time, first the DNSKEY and the
>> signatures need to be introduced in the zone, and propagated to the
>> world. The propagation depends on the TTL values, and these are
>> derived from the dnssec-policy configuration. By default it takes more
>> than a day because of max-zone-ttl is set to 86400.
>>
>> Only then it is fully safe to publish the DS, so at that point BIND
>> will publish the CDS/CDNSKEY records.
>>
>> Note that this long delay is only when you enable DNSSEC, key
>> rollovers only need to take the DNSKEY TTL into account (plus some
>> safety and propagation values).
>>
>> So you submitted the DS too soon. Luckily the delay on the first sign
>> is pretty conservative and your zones appear to be fine after
>> publishing the DS. But in an automated way (CDS polling), the DS would
>> have been submitted later than you did.
>>
>> Three more comments:
>>
>>
>> 1.
>> > I thought that Bind checks the DS on the parent and only publishes
>> CDS > / CDNSKEY if DS doesn't exist or is in some way different.
>>
>> No. The CDS/CDNSKEY RRset is published and won't be removed from the
>> zone.
>>
>> The RFC says that when the Parent DS is in sync with the CDS/CDNSKEY
>> RRset, the Child DNS Operator MAY delete the CDS/CDNSKEY RRset.
>>
>> We chose not to do so, because it can be handy to see what the DS
>> records in the parent should be given what CDS/CDNSKEY RRset is
>> published in the child zone.
>>
>>
>> 2.
>> Depending on your configuration, BIND will check if the DS is actually
>> in the parent zone. If it does not, you have to check it manually and
>> tell BIND with the 'rndc dnssec -checkds' command. Otherwise, the DS
>> may stay in the "Rumoured" state indefinitely, and this can influence
>> future key rollovers.
>>
>>
>> 3.
>> You can use the options 'cds-digest-types' and 'cdnskey' to set what
>> RRsets need to be published.
>>
>>
>> Hope this helps, best regards,
>>
>> Matthijs
>>
>>
>> On 10/2/24 12:42, Danilo Godec via bind-users wrote:
>>> Hi Greg,
>>>
>>> thanks for the answer.
>>>
>>> I knew that CDS and CDNSKEY are just in my own zone and (as far as I
>>> understand), serve to inform the parent DNS about (upcoming?) changes
>>> in DS / DNSKEY records. I'm not quite sure about establishing the
>>> initial trust with the parent, but as our ccTLD parent DNS doesn't
>>> support CDS / CDNSKEY it's not a big deal anyway.
>>>
>>>
>>> What I don't understand is why Bind published CDS / CDNSKEY just for
>>> one of two very similar domains? Initially I thought that Bind checks
>>> the DS on the parent and only publishes CDS / CDNSKEY if DS doesn't
>>> exist or is in some way different.
>>>
>>>
>>>
>>> Regards,
>>>
>>> Danilo
>>>
>>>
>>>
>>> On 2. 10. 24 12:19, Greg Choules wrote:
>>>> Hi Danilo.
>>>> The CDS and CDNSKEY are published in your own zone, not anywhere
>>>> else. You can confirm this by doing a dig for them directly, or AXFR
>>>> if you permit transfers on your server.
>>>>
>>>> They are intended for use with registrars that *do* support
>>>> automatic DS creation using one of them. If yours doesn't and you
>>>> already published your DS in the parent, then no big deal. The CDS
>>>> and CDNSKEY will just sit in your zone and you don't have to do
>>>> anything with them.
>>>>
>>>> Does that help?
>>>> Cheers, Greg
>>>>
>>>> On Wed, 2 Oct 2024 at 10:58, Danilo Godec via bind-users
>>>> <bind-users at lists.isc.org> wrote:
>>>>
>>>> Hi all,
>>>>
>>>> yesterday I filled my day fiddling with DNSSEC for a couple of my
>>>> test domains - both have been signed 'manually' before, but I
>>>> haven't published the DS record.
>>>>
>>>>
>>>> So yesterday I setup both for dnssec-policy, while also changing
>>>> the signing algorithm and keys (basically started from scratch):
>>>>
>>>> dnssec-policy "nsec3_no_rotate" {
>>>> keys {
>>>> ksk key-directory lifetime unlimited algorithm 13;
>>>> zsk key-directory lifetime unlimited algorithm 13;
>>>> };
>>>> nsec3param iterations 0 optout false;
>>>> };
>>>>
>>>> ...
>>>>
>>>> zone "sociopat.si <http://sociopat.si>" {
>>>> type master;
>>>> file "master/Danci/sociopat.si.hosts";
>>>> key-directory "master/Danci/keys";
>>>> dnssec-policy "nsec3_no_rotate";
>>>> inline-signing yes;
>>>> };
>>>>
>>>> zone "psihopat.si <http://psihopat.si>" {
>>>> type master;
>>>> file "master/Danci/psihopat.si.hosts";
>>>> key-directory "master/Danci/keys";
>>>> dnssec-policy "nsec3_no_rotate";
>>>> inline-signing yes;
>>>> };
>>>> ...
>>>>
>>>>
>>>> I published DS records through my registrar and after a couple of
>>>> hours all seemed fine - both Verisign dnssec-analyzer and DNSViz
>>>> show no errors or warnings for them.
>>>>
>>>>
>>>> However, today bind logged this:
>>>>
>>>> named[17379]: general: info: CDNSKEY for
>>>> keysociopat.si/ECDSAP256SHA256/61220
>>>> <http://sociopat.si/ECDSAP256SHA256/61220> is now published
>>>> named[17379]: general: info: CDS for
>>>> keysociopat.si/ECDSAP256SHA256/61220
>>>> <http://sociopat.si/ECDSAP256SHA256/61220> is now published
>>>>
>>>>
>>>> I'm pretty sure this is not bad or wrong, but I would like to
>>>> sort-of understand, why Bind decided it needs to publish CDS /
>>>> CDNSKEY for this one and not the other one, given that DS records
>>>> are published in ccTLDs:
>>>>
>>>> # dig dssociopat.si <http://sociopat.si>
>>>> ;; QUESTION SECTION:
>>>> ;sociopat.si <http://sociopat.si>. IN DS
>>>>
>>>> ;; ANSWER SECTION:
>>>> sociopat.si <http://sociopat.si>. 5826 IN DS 61220
>>>> 13 2 D8C1553B3D6BCF7A704A3D821069F57B6946DCA1D198D303E3B4C730 616F92AD
>>>>
>>>>
>>>> # dig dspsihopat.si <http://psihopat.si>
>>>>
>>>> ;; QUESTION SECTION:
>>>> ;psihopat.si <http://psihopat.si>. IN DS
>>>>
>>>> ;; ANSWER SECTION:
>>>> psihopat.si <http://psihopat.si>. 7200 IN DS 7162
>>>> 13 2 3C5A5625F848DBCF99A0B85017AFE04FD1F681037B61BE970D57AE9F 90F21CD8
>>>>
>>>>
>>>> Also, as far as I know, .si DNS servers don't support CDS /
>>>> CDNSKEY, so publishing them might be futile.
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Danilo
>>>>
>>>>
>>>> -- Visit https://lists.isc.org/mailman/listinfo/bind-users to
>>>> unsubscribe from this list
>>>>
>>>> ISC funds the development of this software with paid support
>>>> subscriptions. Contact us at https://www.isc.org/contact/ for more
>>>> information.
>>>>
>>>>
>>>> bind-users mailing list
>>>> bind-users at lists.isc.org
>>>> https://lists.isc.org/mailman/listinfo/bind-users
>>>>
>>>
>
More information about the bind-users
mailing list