CDNSKEY / CDS for key is now published - but why?
Danilo Godec
danilo.godec at agenda.si
Wed Oct 2 12:55:17 UTC 2024
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
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20241002/9782ef7c/attachment-0001.htm>
More information about the bind-users
mailing list