GitLab

Summary

rndc dnssec -rollover does not trigger a KSK rollover as expected.

BIND version used

BIND 9.16.8-Debian (Stable Release) <id:539f9f0>
running on Linux x86_64 4.19.0-13-amd64 #1 SMP Debian 4.19.160-2 (2020-11-28)
built by make with '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=/usr/include' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-silent-rules' '--libdir=/usr/lib/x86_64-linux-gnu' '--runstatedir=/run' '--disable-maintainer-mode' '--disable-dependency-tracking' '--libdir=/usr/lib/x86_64-linux-gnu' '--sysconfdir=/etc/bind' '--with-python=python3' '--localstatedir=/' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--enable-static' '--with-gost=no' '--with-openssl=/usr' '--with-gssapi=/usr' '--with-libidn2' '--with-json-c' '--with-lmdb=/usr' '--with-gnu-ld' '--with-maxminddb' '--with-atf=no' '--enable-ipv6' '--enable-rrl' '--enable-filter-aaaa' '--disable-native-pkcs11' '--enable-dnstap' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fdebug-prefix-map=/build/bind9-Pv1hAF/bind9-9.16.8=. -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
compiled by GCC 8.3.0
compiled with OpenSSL version: OpenSSL 1.1.1d  10 Sep 2019
linked to OpenSSL version: OpenSSL 1.1.1d  10 Sep 2019
compiled with libuv version: 1.24.1
linked to libuv version: 1.24.1
compiled with libxml2 version: 2.9.4
linked to libxml2 version: 20904
compiled with json-c version: 0.12.1
linked to json-c version: 0.12.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.3.2
compiled with protobuf-c version: 1.3.1
linked to protobuf-c version: 1.3.1
threads support is enabled

default paths:
  named configuration:  /etc/bind/named.conf
  rndc configuration:   /etc/bind/rndc.conf
  DNSSEC root key:      /etc/bind/bind.keys
  nsupdate session key: //run/named/session.key
  named PID file:       //run/named/named.pid
  named lock file:      //run/named/named.lock
  geoip-directory:      /usr/share/GeoIP

Steps to reproduce

• on a domain with one single KSK currently in use and working properly as reported by dnsviz
• rndc dnssec -rollover -key

What is the current bug behavior?

Status before:

current time:  Wed Feb 10 20:16:26 2021

key: 43281 (RSASHA512), KSK
  published:      yes - since Fri Aug 28 00:31:44 2020
  key signing:    yes - since Fri Aug 28 00:31:44 2020

  Next rollover scheduled on Sun Sep 26 22:26:44 2021
  - goal:           omnipresent
  - dnskey:         omnipresent
  - ds:             omnipresent
  - key rrsig:      omnipresent

key: 20426 (RSASHA512), ZSK
  published:      yes - since Sat Nov 21 00:31:44 2020
  zone signing:   yes - since Mon Dec 21 00:31:44 2020

  Next rollover scheduled on Sat Mar 20 22:26:44 2021
  - goal:           omnipresent
  - dnskey:         omnipresent
  - zone rrsig:     omnipresent

Status after:

dnssec-policy: generated
current time:  Thu Feb 11 16:03:34 2021

key: 43281 (RSASHA512), KSK
  published:      yes - since Fri Aug 28 00:31:44 2020
  key signing:    yes - since Fri Aug 28 00:31:44 2020

  Next rollover scheduled on Wed Feb 10 20:21:50 2021
  - goal:           omnipresent
  - dnskey:         omnipresent
  - ds:             omnipresent
  - key rrsig:      omnipresent

key: 20426 (RSASHA512), ZSK
  published:      yes - since Sat Nov 21 00:31:44 2020
  zone signing:   yes - since Mon Dec 21 00:31:44 2020

  Next rollover scheduled on Sat Mar 20 22:26:44 2021
  - goal:           omnipresent
  - dnskey:         omnipresent
  - zone rrsig:     omnipresent

Except for the rollover date, which is now in the past, nothing happened.

What is the expected correct behavior?

I was expecting:

• the key to have a new goal state (there is no doc on the possible states, so I don't know which one would be appropriate)
• a new KSK to be automatically generated as per the policy
• the new key to be introduced so that I can mark it as seen when published (with rndc dnssec -checkds IIUC)
• and the rest of the rollover steps to follow

Since I asked for a forced rollover and the time when not set is now according to the doc (the scheduled time matches, so that's fine), then I would expect things to be set in motion very quickly. I did not try to restart to do anything that might supposedly trigger the scheduler but it should not be necessary. I'm also not expecting to have to create a new key by myself, as I think it's the policy's responsibility to create keys with the proper parameters.

Relevant configuration files

The policy:

dnssec-policy "generated" {
    keys {
        ksk key-directory lifetime P1Y algorithm rsasha512 4096;
        zsk key-directory lifetime 30d algorithm rsasha512 2048;
    };
    max-zone-ttl PT1H;
};

The zone config:

zone "_kage.hq.duckcorp.org" IN {
        type master;
        allow-transfer { key duckcorp-internal; };
        update-policy { grant duckcorp-le-Elwing name _acme-challenge.smtp._kage.hq.duckcorp.org TXT; grant duckcorp-le-Elwing name _25._tcp.smtp._kage.hq.duckcorp.org TLSA; };
        file "/var/cache/bind/masters/_kage.hq.duckcorp.org.zone";
        dnssec-policy "generated";
};

Possible fixes

Maybe this command is not doing what I expect but since there is no documentation about procedures with the new dnssec-policy system and it seems almost noone is writing on it on the Internet I'm at a loss to understand what to do.

Btw I was thinking about doing an algo rollover in the future, and I was wondering if simply changing the policy would automagically do the required steps the next time a key is replaced (or when you force a rollover).