CDNSKEY / CDS for key is now published - but why?
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" {
type master;
file "master/Danci/sociopat.si.hosts";
key-directory "master/Danci/keys";
dnssec-policy "nsec3_no_rotate";
inline-signing yes;
};
zone "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 key sociopat.si/ECDSAP256SHA256/61220
is now published
named[17379]: general: info: CDS for key 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 ds sociopat.si
;; QUESTION SECTION:
;sociopat.si. IN DS
;; ANSWER SECTION:
sociopat.si.5826IN DS 61220 13 2
D8C1553B3D6BCF7A704A3D821069F57B6946DCA1D198D303E3B4C730 616F92AD
# dig ds psihopat.si
;; QUESTION SECTION:
;psihopat.si. IN DS
;; ANSWER SECTION:
psihopat.si.7200IN 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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: CDNSKEY / CDS for key is now published - but why?
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@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" {
> type master;
> file "master/Danci/sociopat.si.hosts";
> key-directory "master/Danci/keys";
> dnssec-policy "nsec3_no_rotate";
> inline-signing yes;
> };
>
> zone "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 key
> sociopat.si/ECDSAP256SHA256/61220 is now published
> named[17379]: general: info: CDS for key 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 ds sociopat.si
> ;; QUESTION SECTION:
> ;sociopat.si. IN DS
>
> ;; ANSWER SECTION:sociopat.si.5826IN DS 61220 13 2
> D8C1553B3D6BCF7A704A3D821069F57B6946DCA1D198D303E3B4C730 616F92AD
>
>
> # dig ds psihopat.si
>
> ;; QUESTION SECTION:
> ;psihopat.si. IN DS
>
> ;; ANSWER SECTION:psihopat.si.7200IN 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@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
--
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: CDNSKEY / CDS for key is now published - but why?
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
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 " {
type master;
file "master/Danci/sociopat.si.hosts";
key-directory "master/Danci/keys";
dnssec-policy "nsec3_no_rotate";
inline-signing yes;
};
zone "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
is now published
named[17379]: general: info: CDS for keysociopat.si/ECDSAP256SHA256/61220
is now published
I'm pretty sure this is not bad or wrong, but I would like to
Re: CDNSKEY / CDS for key is now published - but why?
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
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 " {
type master;
file "master/Danci/sociopat.si.hosts";
key-directory "master/Danci/keys";
dnssec-policy "nsec3_no_rotate";
inline-signing yes;
};
zone "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
is now published
named[17379]: general: info: CDS for keysociopat.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
;; QUESTION SECTION:
;sociopat.si . IN DS
;; ANSWER SECTION:
sociopat.si .5826IN DS 61220
13 2 D8C1553B3D6BCF7A704A3D821069F57B6946DCA1D198D303E3B4C730 616F92AD
# dig dspsihopat.si
;; QUESTION SECTION:
;psihopat.si . IN DS
;; ANSWER SECTION:
psihopat.si .7200IN 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@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.go...@agenda.si | T: +386 (0)2 421 61 31
Agenda OpenSystems
--
Visit https://l
Re: Some Statistics Channel Cache Memory Stats either at 0 or accumulating
On 30. 09. 24 22:35, Jason Creviston wrote: I've noticed TreeMemTotal seems to be ever-increasing, while TreeMemMax and HeapMemMax remain at 0. I didn't find any related fixes in the newer versions of 9.18, 9.20, or 9.21. Just started keeping track of stats via the JSON API. Running BIND 9.18.28 on Ubuntu 22.04. In short, most of the memory statistics are undocumented, version-dependent, things for debugging. Look only at "inuse" values which reflect BIND's view of how much memory we actually use and you can safely ignore the rest. I hope it helps. -- Petr Špaček Internet Systems Consortium -- 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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Multi Master/Primary Authoritative DNSSEC DNS Nameserver With Synced/Replicated COMMON Dir/Vol For BIND
On 01. 10. 24 8:15, Terik Erik Ashfolk wrote: Please scratch the below line previous post. Upon detail look, they have Multi-Master support, but not with DNSSEC support. If you really wanted multi-master with DNSSEC you can have a look at FreeIPA.org, their DNS integration has that. It supports disconnected operation with eventual consistency, but it is very very _very_ complex beast which combines: - BIND - bind-dyndn-ldap LDAP backend for DNS data and zone config - OpenDNSSEC to manage keys - SoftHSM to store keys - extra magic scripts to synchronize keys via LDAP That way lies madness! (Please note I'm saying that as a person who designed and implemented it!) -- Petr Špaček Internet Systems Consortium -- 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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: CDNSKEY / CDS for key is now published - but why?
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 anyth
Re: CDNSKEY / CDS for key is now published - but why?
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. T
