Can't get Bind to publish CDS/CDNSKEY using dnssec-policy

Josef Vybíhal josef.vybihal at gmail.com
Thu Aug 12 10:46:34 UTC 2021


Thank you for pointing me to that issue !2857
<https://gitlab.isc.org/isc-projects/bind9/-/issues/2857>, that's exactly
what I hit. Now when I see the details, it makes sense.

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.

Josef

On Thu, Aug 12, 2021 at 10:08 AM Matthijs Mekking <matthijs at isc.org> wrote:

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


More information about the bind-users mailing list