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

2021-08-12 Thread Josef Vybíhal
Thank you for pointing me to that issue !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  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
> > , 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 
> > 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 " {
> > type master;
> > file "master/irmorava.cz.zone";
> > allow-update { none; };
> > key-directory "keys/irmorava.cz ";
> > dnssec-policy pepa;
> > notify yes;
> > allow-transfer { pepa_abc; };
> > };
> >
> >
> > dig irmorava.cz  @127.0.0.1 
> > DNSKEY +short +norec
> > 257 3 13 Xsfq5rEgoE+iT+cvq0OZz43MiLiRLeH8SUAEIprn0/J3PNZSYVlCeNuF
> > 5lfNo6uM0TeApujDhmQ1FPNINKxa2Q==
> >
> >
> > rndc dnssec -status 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
> >publ

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

2021-08-12 Thread Matthijs Mekking

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 
, 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 
). 
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 
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 " {
type master;
file "master/irmorava.cz.zone";
allow-update { none; };
key-directory "keys/irmorava.cz ";
dnssec-policy pepa;
notify yes;
allow-transfer { pepa_abc; };
};


dig irmorava.cz  @127.0.0.1  
DNSKEY +short +norec
257 3 13 Xsfq5rEgoE+iT+cvq0OZz43MiLiRLeH8SUAEIprn0/J3PNZSYVlCeNuF 
5lfNo6uM0TeApujDhmQ1FPNINKxa2Q==



rndc dnssec -status 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 
:

; This is the state of key 22788, for 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: 20210

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

2021-08-12 Thread Josef Vybíhal
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, 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.

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).
Unfortunately I can not get bind to automatically publish them. No clue
why. I kind of expected bind to publish them on PublishCDS: 20210811135045
(Wed Aug 11 15:50:45 2021) automatically.

domain: 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" {
type master;
file "master/irmorava.cz.zone";
allow-update { none; };
key-directory "keys/irmorava.cz";
dnssec-policy pepa;
notify yes;
allow-transfer { pepa_abc; };
};


dig irmorava.cz @127.0.0.1 DNSKEY +short +norec
257 3 13 Xsfq5rEgoE+iT+cvq0OZz43MiLiRLeH8SUAEIprn0/J3PNZSYVlCeNuF
5lfNo6uM0TeApujDhmQ1FPNINKxa2Q==


rndc dnssec -status 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:
; This is the state of key 22788, for 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 but still
no luck.

I am sure I am 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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users