Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
BIND
BIND
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 580
    • Issues 580
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 113
    • Merge Requests 113
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • ISC Open Source Projects
  • BINDBIND
  • Issues
  • #1543

Closed
Open
Opened Jan 05, 2020 by Graham Clinch@gclinch

dnssec-keymgr, if called frequently, may repeatedly move successor key publication/activation times forward

Summary

Calling dnssec-keymgr every five minutes or more rapidly will cause any successor keys' publication/activation times to move indefinitely forward, preventing the rollover from occuring.

I believe this is a regression caused by the fix for GL #848 (closed) "dnssec-keymgr: Add a five-minute margin to better handle key events close to 'now'".

BIND version used

$ named -V
BIND 9.14.9 (Stable Release) <id:623e23e>
running on Darwin x86_64 19.2.0 Darwin Kernel Version 19.2.0: Sat Nov  9 03:47:04 PST 2019; root:xnu-6153.61.1~20/RELEASE_X86_64
built by make with '--prefix=/usr/local/Cellar/bind/9.14.9' '--with-openssl=/usr/local/opt/openssl@1.1' '--with-libjson=/usr/local/opt/json-c' '--with-python=/usr/local/opt/python/bin/python3' '--with-python-install-dir=/usr/local/Cellar/bind/9.14.9/libexec/vendor/lib/python3.7/site-packages' '--without-lmdb' 'CC=clang' 'PKG_CONFIG_PATH=/usr/local/opt/json-c/lib/pkgconfig:/usr/local/opt/openssl@1.1/lib/pkgconfig:/usr/local/opt/readline/lib/pkgconfig:/usr/local/opt/sqlite/lib/pkgconfig:/usr/local/opt/xz/lib/pkgconfig:/usr/local/opt/python/lib/pkgconfig' 'PKG_CONFIG_LIBDIR=/usr/lib/pkgconfig:/usr/local/Homebrew/Library/Homebrew/os/mac/pkgconfig/10.15'
compiled by CLANG 4.2.1 Compatible Apple LLVM 11.0.0 (clang-1100.0.33.16)
compiled with OpenSSL version: OpenSSL 1.1.1d  10 Sep 2019
linked to OpenSSL version: OpenSSL 1.1.1d  10 Sep 2019
compiled with libxml2 version: 2.9.4
linked to libxml2 version: 20904
compiled with libjson-c version: 0.13.1
linked to libjson-c version: 0.13.1
threads support is enabled

default paths:
  named configuration:  /usr/local/Cellar/bind/9.14.9/etc/named.conf
  rndc configuration:   /usr/local/Cellar/bind/9.14.9/etc/rndc.conf
  DNSSEC root key:      /usr/local/Cellar/bind/9.14.9/etc/bind.keys
  nsupdate session key: /usr/local/Cellar/bind/9.14.9/var/run/named/session.key
  named PID file:       /usr/local/Cellar/bind/9.14.9/var/run/named/named.pid
  named lock file:      /usr/local/Cellar/bind/9.14.9/var/run/named/named.lock
$ 

Steps to reproduce

Start in an empty directory, create keys for a zone, then move the ZSK's publication and activation times before the roll-period (simulating importing keys created a long time ago):

$ dnssec-keymgr example.net
# /usr/local/Cellar/bind/9.14.9/sbin/dnssec-keygen -q -K . -L 3600 -a RSASHA256 -b 2048 example.net
# /usr/local/Cellar/bind/9.14.9/sbin/dnssec-keygen -q -K . -L 3600 -fk -a RSASHA256 -b 2048 example.net
$ fgrep signing *.key
Kexample.net.+008+39648.key:; This is a zone-signing key, keyid 39648, for example.net.
Kexample.net.+008+61345.key:; This is a key-signing key, keyid 61345, for example.net.
$ dnssec-settime -P 20150101 -A 20150101 Kexample.net.+008+39648
./Kexample.net.+008+39648.key
./Kexample.net.+008+39648.private

Run dnssec-keymgr to see a successor key created, then repeatedly run dnssec-keymgr to see the old key's inactivation and deletion times and the new key's publication and activation keys move forward on each call:

$ dnssec-keymgr 
# /usr/local/Cellar/bind/9.14.9/sbin/dnssec-settime -K . -I 20200204224432 -D 20200305224432 Kexample.net.+008+39648
# /usr/local/Cellar/bind/9.14.9/sbin/dnssec-keygen -q -K . -S Kexample.net.+008+39648 -L 3600 -i 2592000
$ dnssec-keymgr 
# /usr/local/Cellar/bind/9.14.9/sbin/dnssec-settime -K . -I 20200204224440 -D 20200305224440 Kexample.net.+008+39648
# /usr/local/Cellar/bind/9.14.9/sbin/dnssec-settime -K . -P 20200105224440 -A 20200204224440 Kexample.net.+008+46923
$ dnssec-keymgr 
# /usr/local/Cellar/bind/9.14.9/sbin/dnssec-settime -K . -I 20200204224445 -D 20200305224445 Kexample.net.+008+39648
# /usr/local/Cellar/bind/9.14.9/sbin/dnssec-settime -K . -P 20200105224445 -A 20200204224445 Kexample.net.+008+46923
$ dnssec-keymgr 
# /usr/local/Cellar/bind/9.14.9/sbin/dnssec-settime -K . -I 20200204224450 -D 20200305224450 Kexample.net.+008+39648
# /usr/local/Cellar/bind/9.14.9/sbin/dnssec-settime -K . -P 20200105224450 -A 20200204224450 Kexample.net.+008+46923
$ dnssec-keymgr 
# /usr/local/Cellar/bind/9.14.9/sbin/dnssec-settime -K . -I 20200204224455 -D 20200305224455 Kexample.net.+008+39648
# /usr/local/Cellar/bind/9.14.9/sbin/dnssec-settime -K . -P 20200105224455 -A 20200204224455 Kexample.net.+008+46923
$ 

What is the current bug behavior?

Frequent calls to dnssec-keymgr cause key times to be continuously pushed into the future, causing keys to never roll.

What is the expected correct behavior?

Frequent calls to dnssec-keymgr should not interfere with key timing.

Relevant configuration files

None

Relevant logs and/or screenshots

None

Possible fixes

Unclear

Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: isc-projects/bind9#1543