<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">Thank you for pointing me to that issue !<a href="https://gitlab.isc.org/isc-projects/bind9/-/issues/2857" rel="noreferrer" target="_blank" style="font-family:Arial,Helvetica,sans-serif;outline:none"><span class="gmail_default" style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0);outline:none"></span>2857</a>, that's exactly what I hit. Now when I see the details, it makes sense.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">I have cleared the domain from all keys and dnssec-policy settings. Then assigned the dnssec-policy to unsigned domain and bam, CDS+CDNSKEY records are published after time specified in policy.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">Josef</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 12, 2021 at 10:08 AM Matthijs Mekking <<a href="mailto:matthijs@isc.org">matthijs@isc.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
On 12-08-2021 09:02, Josef Vybíhal wrote:<br>
> Hi, for a second day, I am scratching my head over (automatic) <br>
> publishing CDS/CDNSKEY records. When I read Matthijs Mekkings KB article <br>
> at <a href="https://kb.isc.org/docs/dnssec-key-and-signing-policy" rel="noreferrer" target="_blank">https://kb.isc.org/docs/dnssec-key-and-signing-policy</a> <br>
> <<a href="https://kb.isc.org/docs/dnssec-key-and-signing-policy" rel="noreferrer" target="_blank">https://kb.isc.org/docs/dnssec-key-and-signing-policy</a>>, I wanted to try <br>
> dnssec-policy. Up until now, I successfully was using inline-signing <br>
> with auto-dnssec.<br>
> <br>
> I configured my dnssec-policy to match the current key setting, but I <br>
> probably made a mistake and it did not match it, so a new key was <br>
> generated. No big deal, it's a test domain, rollover is not a problem.<br>
<br>
I am sorry, I am afraid you hit a bug: <br>
<a href="https://gitlab.isc.org/isc-projects/bind9/-/issues/2857" rel="noreferrer" target="_blank">https://gitlab.isc.org/isc-projects/bind9/-/issues/<span class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"></span>2857</a><br>
<br>
The legacy key metadata has no information about the role of keys. It <br>
determines the role from the key flags: 256 means it is a ZSK, and 257 <br>
is converted to a KSK. In other words, migrating a CSK won't work.<br>
<br>
I am working on a fix so that you will be able to migrate CSKs.<br>
<br>
For now I have added a warning to the KB article.<br>
<br>
<br>
> Since my TLD supports CDNSKEY, I want to leverage it. So I removed <br>
> current DS record from the domain and expected Bind to publish <br>
> CDS/CDNSKEY <br>
> (<a href="https://bind9.readthedocs.io/en/latest/dnssec-guide.html#the-cds-and-cdnskey-resource-records" rel="noreferrer" target="_blank">https://bind9.readthedocs.io/en/latest/dnssec-guide.html#the-cds-and-cdnskey-resource-records</a> <br>
> <<a href="https://bind9.readthedocs.io/en/latest/dnssec-guide.html#the-cds-and-cdnskey-resource-records" rel="noreferrer" target="_blank">https://bind9.readthedocs.io/en/latest/dnssec-guide.html#the-cds-and-cdnskey-resource-records</a>>). <br>
> Unfortunately I can not get bind to automatically publish them. No clue <br>
> why. I kind of expected bind topublish them on PublishCDS: <br>
> 20210811135045 (Wed Aug 11 15:50:45 2021) automatically.<br>
<br>
The metadata is indeed an indication of when certain events are expected <br>
to happen. But if BIND determines it is not safe to do so, there may be <br>
a delay.<br>
<br>
From the output below, it looks like not all zone signatures have been <br>
propagated yet:<br>
<br>
> - zone rrsig: rumoured<br>
<br>
The PublishCDS metadata is usually set to the the time that the DNSKEY <br>
has been published, plus dnskey-ttl, zone-propagation-delay, and <br>
publish-safety. If it is the first key for the zone, the time to <br>
propagate the zone signatures is taken into account. But in your case <br>
two other keys already existed.<br>
<br>
The PublishCDS metadata can be set more accurately if we can detect that <br>
none of the other keys have a secure delegation (I think we can).<br>
<br>
<br>
Best regards,<br>
<br>
Matthijs<br>
<br>
<br>
> domain: <a href="http://irmorava.cz" rel="noreferrer" target="_blank">irmorava.cz</a> <<a href="http://irmorava.cz" rel="noreferrer" target="_blank">http://irmorava.cz</a>><br>
> version: BIND 9.16.19<br>
> OS: CentOS 8 Stream + packages from copr.<br>
> <br>
> named.conf:<br>
> dnssec-policy "pepa" {<br>
> keys {<br>
> csk key-directory lifetime unlimited algorithm 13;<br>
> };<br>
> <br>
> // Key timings<br>
> dnskey-ttl PT1H;<br>
> publish-safety PT1H;<br>
> retire-safety PT1H;<br>
> purge-keys P1D;<br>
> <br>
> // Signature timings<br>
> signatures-refresh P5D;<br>
> signatures-validity P14D;<br>
> signatures-validity-dnskey P14D;<br>
> <br>
> // Zone parameters<br>
> max-zone-ttl PT1H;<br>
> zone-propagation-delay PT5M;<br>
> parent-ds-ttl PT1H;<br>
> parent-propagation-delay PT1H;<br>
> nsec3param iterations 1 optout false salt-length 16;<br>
> };<br>
> <br>
> zone "<a href="http://irmorava.cz" rel="noreferrer" target="_blank">irmorava.cz</a> <<a href="http://irmorava.cz" rel="noreferrer" target="_blank">http://irmorava.cz</a>>" {<br>
> type master;<br>
> file "master/irmorava.cz.zone";<br>
> allow-update { none; };<br>
> key-directory "keys/<a href="http://irmorava.cz" rel="noreferrer" target="_blank">irmorava.cz</a> <<a href="http://irmorava.cz" rel="noreferrer" target="_blank">http://irmorava.cz</a>>";<br>
> dnssec-policy pepa;<br>
> notify yes;<br>
> allow-transfer { pepa_abc; };<br>
> };<br>
> <br>
> <br>
> dig <a href="http://irmorava.cz" rel="noreferrer" target="_blank">irmorava.cz</a> <<a href="http://irmorava.cz" rel="noreferrer" target="_blank">http://irmorava.cz</a>> @<a href="http://127.0.0.1" rel="noreferrer" target="_blank">127.0.0.1</a> <<a href="http://127.0.0.1" rel="noreferrer" target="_blank">http://127.0.0.1</a>> <br>
> DNSKEY +short +norec<br>
> 257 3 13 Xsfq5rEgoE+iT+cvq0OZz43MiLiRLeH8SUAEIprn0/J3PNZSYVlCeNuF <br>
> 5lfNo6uM0TeApujDhmQ1FPNINKxa2Q==<br>
> <br>
> <br>
> rndc dnssec -status <a href="http://irmorava.cz" rel="noreferrer" target="_blank">irmorava.cz</a> <<a href="http://irmorava.cz" rel="noreferrer" target="_blank">http://irmorava.cz</a>><br>
> dnssec-policy: pepa<br>
> current time: Thu Aug 12 08:38:40 2021<br>
> <br>
> key: 22788 (ECDSAP256SHA256), CSK<br>
> published: yes - since Wed Aug 11 10:20:00 2021<br>
> key signing: yes - since Wed Aug 11 10:20:00 2021<br>
> zone signing: yes - since Wed Aug 11 12:25:00 2021<br>
> <br>
> No rollover scheduled<br>
> - goal: omnipresent<br>
> - dnskey: omnipresent<br>
> - ds: hidden<br>
> - zone rrsig: rumoured<br>
> - key rrsig: omnipresent<br>
> <br>
> key: 44055 (ECDSAP256SHA256), CSK<br>
> published: no<br>
> key signing: no<br>
> zone signing: no<br>
> <br>
> Key has been removed from the zone<br>
> - goal: hidden<br>
> - dnskey: hidden<br>
> - ds: hidden<br>
> - zone rrsig: unretentive<br>
> - key rrsig: hidden<br>
> <br>
> key: 35549 (ECDSAP256SHA256), CSK<br>
> published: no<br>
> key signing: no<br>
> zone signing: no<br>
> <br>
> Key has been removed from the zone<br>
> - goal: hidden<br>
> - dnskey: hidden<br>
> - ds: hidden<br>
> - zone rrsig: hidden<br>
> - key rrsig: hidden<br>
> <br>
> <br>
> <br>
> /var/named/keys/<a href="http://irmorava.cz/Kirmorava.cz.+013+22788.state" rel="noreferrer" target="_blank">irmorava.cz/Kirmorava.cz.+013+22788.state</a> <br>
> <<a href="http://irmorava.cz/Kirmorava.cz.+013+22788.state" rel="noreferrer" target="_blank">http://irmorava.cz/Kirmorava.cz.+013+22788.state</a>>:<br>
> ; This is the state of key 22788, for <a href="http://irmorava.cz" rel="noreferrer" target="_blank">irmorava.cz</a> <<a href="http://irmorava.cz" rel="noreferrer" target="_blank">http://irmorava.cz</a>>.<br>
> Algorithm: 13<br>
> Length: 256<br>
> Lifetime: 0<br>
> Predecessor: 44055<br>
> KSK: yes<br>
> ZSK: yes<br>
> Generated: 20210811082000 (Wed Aug 11 10:20:00 2021)<br>
> Published: 20210811082000 (Wed Aug 11 10:20:00 2021)<br>
> Active: 20210811102500 (Wed Aug 11 12:25:00 2021)<br>
> DSPublish: 20210811131037 (Wed Aug 11 15:10:37 2021)<br>
> DSRemoved: 20210811131020 (Wed Aug 11 15:10:20 2021)<br>
> *PublishCDS: 20210811135045 (Wed Aug 11 15:50:45 2021)<br>
> *DNSKEYChange: 20210811102500 (Wed Aug 11 12:25:00 2021)<br>
> ZRRSIGChange: 20210811082000 (Wed Aug 11 10:20:00 2021)<br>
> KRRSIGChange: 20210811102500 (Wed Aug 11 12:25:00 2021)<br>
> DSChange: 20210811082000 (Wed Aug 11 10:20:00 2021)<br>
> DNSKEYState: omnipresent<br>
> ZRRSIGState: rumoured<br>
> KRRSIGState: omnipresent<br>
> DSState: hidden<br>
> GoalState: omnipresent<br>
> <br>
> <br>
> As you can see, I rolled over 2 more keys, but the desired records were <br>
> not published. Yesterday I tried manually 'dnssec-settime -P sync now <br>
> Kirmorava.cz.+013+22788.key'. I have waited as I read here <br>
> <a href="https://lists.isc.org/pipermail/bind-users/2020-April/102903.html" rel="noreferrer" target="_blank">https://lists.isc.org/pipermail/bind-users/2020-April/102903.html</a> <br>
> <<a href="https://lists.isc.org/pipermail/bind-users/2020-April/102903.html" rel="noreferrer" target="_blank">https://lists.isc.org/pipermail/bind-users/2020-April/102903.html</a>> but <br>
> still no luck.<br>
> <br>
> I am sure Iam missing something stupidly simple. Could someone please <br>
> give me any hint? Or are 'parental-agents' required to be configured? <br>
> Does not seem right way to me.<br>
> <br>
> Josef<br>
> <br>
> _______________________________________________<br>
> Please visit <a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a> to unsubscribe from this list<br>
> <br>
> ISC funds the development of this software with paid support subscriptions. Contact us at <a href="https://www.isc.org/contact/" rel="noreferrer" target="_blank">https://www.isc.org/contact/</a> for more information.<br>
> <br>
> <br>
> bind-users mailing list<br>
> <a href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a><br>
> <a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a><br>
> <br>
_______________________________________________<br>
Please visit <a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a> to unsubscribe from this list<br>
<br>
ISC funds the development of this software with paid support subscriptions. Contact us at <a href="https://www.isc.org/contact/" rel="noreferrer" target="_blank">https://www.isc.org/contact/</a> for more information.<br>
<br>
<br>
bind-users mailing list<br>
<a href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a><br>
</blockquote></div></div>