Hi Michel, could you please report this to the upstream issue tracker at:
https://gitlab.isc.org/isc-projects/bind9 My colleague Matthijs will need more details and it’s better to track upstream issues in the upstream issue tracker. Thanks, -- Ondřej Surý (He/Him) ond...@sury.org > On 1. 2. 2021, at 10:04, Michel Lespinasse <mic...@lespinasse.org> wrote: > > Package: bind9 > Version: 1:9.16.11-2~bpo10+1 > > I'm running a debian buster system, with a small number of packages > installed from buster-backports, one of them being bind9 (for the > dnssec inline signing / policy enhancements). > > My setup seemed to work fine with bind9 version 1:9.16.8-1~bpo10+1 , > but as I updated to version 1:9.16.11-2~bpo10+1 today, something went > wrong and one of my zones kept being assigned a new KSK every time > bind9 gets restarted or reloaded. That is quite a bummer because > KSK rotations are not fully automated, and my dnssec policy specifically > asks for the KSK not to be rotated. > > After some investigation I was able to make a guess that the issue seems to > be triggered by having two zones with identical names in separate views: > > - in my "public" view, the "lespinasse.org" zone is loaded from > /var/lib/bind/db.lespinasse.public, and has the "secure" dnssec-policy > applied to it. > > - in my "internal" view, the "lespinasse.org" zone is loaded from > /etc/bind/db.lespinasse, and has not dnssec applied to it. > The view also includes a "public.lespinasse.org" zone which loads > the same db.lespinasse.public file as in the public view, but does > not apply any dnssec policy to it. > > > > Simplified configuration (I can provide more details on private request): > > options { > directory "/var/cache/bind"; > > dnssec-validation auto; > > // Default settings, may be overriden for specific views or zones. > recursion no; > allow-query { any; }; > allow-transfer { none; }; > allow-update { none; }; > > serial-update-method date; > key-directory "/var/lib/bind/keys"; > }; > > dnssec-policy "secure" { > // quite similar to the default policy, but I was put off by > // the note that ksk might get rotated if the default dnssec > // policy changes signing algorithms in the future > // so I was trying to avoid that > > dnskey-ttl 3h; > keys { > ksk lifetime unlimited algorithm ecdsap256sha256; > zsk lifetime 4w algorithm ecdsap256sha256; > }; > publish-safety 12h; > retire-safety 12h; > signatures-refresh 2w; > signatures-validity 4w; > signatures-validity-dnskey 4w; > }; > > view "public" { > match-clients { > // requests from 192.168.1.1 with the axfr-key > !{ !key "axfr-key"; any; }; 192.168.1.1; > }; > > notify explicit; > also-notify { 192.168.1.1; }; > allow-transfer { 192.168.1.1; }; > > zone "lespinasse.org" { > type master; > file "/var/lib/bind/db.lespinasse.public"; > dnssec-policy "secure"; > }; > zone "test.lespinasse.org" { > type master; > file "/var/lib/bind/db.lespinasse.test"; > dnssec-policy "secure"; > }; > }; > > view "internal" { > match-clients { 127.0.0.1; 10.0.0.0/8; }; > recursion yes; > > include "/etc/bind/named.conf.default-zones"; > zone "lespinasse.org" { > type master; > file "/etc/bind/db.lespinasse"; > }; > zone "public.lespinasse.org" { > type master; > file "/etc/bind/db.lespinasse.public"; > }; > zone "test.lespinasse.org" { in-view "public"; }; > }; > > > > During server reload or restart, I am seeing logs as below. The big > hint for me was the complain about not being to create > /etc/bind/db.lespinasse.jnl - db.lespinasse is only loaded in a zone > that doesn't allow updates or use any dnssec policy, so there is no > reason for it to require a journal... > > > /var/log/daemon.log extracts: > > all zones loaded > running > zone lespinasse.org/IN/internal: reconfiguring zone keys > zone test.lespinasse.org/IN/public (signed): receive_secure_serial: unchanged > zone public.lespinasse.org/IN/internal: sending notifies (serial 2021013101) > zone lespinasse.org/IN/public (signed): receive_secure_serial: unchanged > keymgr: retire DNSKEY lespinasse.org/ECDSAP256SHA256/58127 (KSK) > keymgr: retire DNSKEY lespinasse.org/ECDSAP256SHA256/3104 (KSK) > keymgr: retire DNSKEY lespinasse.org/ECDSAP256SHA256/34562 (KSK) > keymgr: retire DNSKEY lespinasse.org/ECDSAP256SHA256/6553 (ZSK) > keymgr: retire DNSKEY lespinasse.org/ECDSAP256SHA256/5499 (ZSK) > keymgr: retire DNSKEY lespinasse.org/ECDSAP256SHA256/61198 (KSK) > zone test.lespinasse.org/IN/public (signed): sending notifies (serial > 2021013101) > zone test.lespinasse.org/IN/public (signed): reconfiguring zone keys > Fetching lespinasse.org/ECDSAP256SHA256/34562 (KSK) from key repository. > DNSKEY lespinasse.org/ECDSAP256SHA256/34562 (KSK) is now published > Fetching lespinasse.org/ECDSAP256SHA256/6553 (ZSK) from key repository. > DNSKEY lespinasse.org/ECDSAP256SHA256/6553 (ZSK) is now published > DNSKEY lespinasse.org/ECDSAP256SHA256/6553 (ZSK) is now active > CDNSKEY (DELETE) for zone lespinasse.org is now published > CDS (DELETE) for zone lespinasse.org is now published > zone test.lespinasse.org/IN/public (signed): next key event: 04-Feb-2021 > 11:27:58.679 > /etc/bind/db.lespinasse.jnl: create: permission denied > zone lespinasse.org/IN/internal: zone_rekey:dns_journal_open -> unexpected > error > zone lespinasse.org/IN/public (signed): sending notifies (serial 2021013118) > zone lespinasse.org/IN/public (signed): reconfiguring zone keys > keymgr: DNSKEY lespinasse.org/ECDSAP256SHA256/44492 (KSK) created for policy > secure > DNSKEY lespinasse.org/ECDSAP256SHA256/34562 (KSK) is now inactive > Removing expired key 61198/ECDSAP256SHA256 from DNSKEY RRset. > DNSKEY lespinasse.org/ECDSAP256SHA256/61198 (KSK) is now deleted > Fetching lespinasse.org/ECDSAP256SHA256/44492 (KSK) from key repository. > DNSKEY lespinasse.org/ECDSAP256SHA256/44492 (KSK) is now published > DNSKEY lespinasse.org/ECDSAP256SHA256/44492 (KSK) is now active > zone lespinasse.org/IN/public (signed): update_soa_serial:new serial would be > lower than old serial, using increment method > > zone lespinasse.org/IN/public (signed): next key event: 01-Feb-2021 > 00:31:56.691 > zone lespinasse.org/IN/public (signed): update_soa_serial:new serial would be > lower than old serial, using increment method > > zone lespinasse.org/IN/public (signed): update_soa_serial:new serial would be > lower than old serial, using increment method > > > > I did verify that the issue with rotating the public lespinasse.org > zone KSK key on every bind9 restart or reload, disappears if I comment > out the internal lespinasse.org zone from my config.... but then I am > missing that zone from the internal view, which of course creates > other issues on my end. > > > > -- System Information: > Debian Release: 10.7 > APT prefers stable-updates > APT policy: (500, 'stable-updates'), (500, 'stable') > Architecture: amd64 (x86_64) > > Kernel: Linux 4.19.0-13-amd64 (SMP w/4 CPU cores) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), > LANGUAGE=en_US.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled >
signature.asc
Description: Message signed with OpenPGP
