CDNSKEY / CDS for key is now published - but why?

Danilo Godec danilo.godec at agenda.si
Wed Oct 2 10:42:12 UTC 2024


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
>


Lep pozdrav / Best regards,
--
Danilo Godec | Sistemska podpora / System Administration
AGENDA d.o.o. | Ul. Pohorskega bataljona 49, Sl-2000 Maribor
E: danilo.godec at agenda.si | T: +386 (0)2 421 61 31
Agenda OpenSystems <https://www.agenda.si/> | Največji slovenski 
odprtokodni integrator
Red Hat v Sloveniji <http://www.redhat.si/> | Red Hat Premier Business 
Partner
ElasticBox <http://elasticbox.eu/> | Poslovne rešitve v oblaku
Agenda d.o.o. <https://www.agenda.si/>
Izjava o omejitvi odgovornosti / Legal disclaimer statement 
<https://www.agenda.si/index.php?id=228>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20241002/5d4cbf0e/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GaifMdj9YH50xNX3.webp
Type: image/webp
Size: 2176 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20241002/5d4cbf0e/attachment.webp>


More information about the bind-users mailing list