KASP Rollover = Immediate Loss of DNSKEY (Why Do Inactive Keys Disappear?)
When performing a key rollover using the KASP I continue to see the DNSKEY IMMEDIATELY disappear rather than staying active for the appropriate period of time with the test zone having a 3 hour TTL. I first encountered this behavior with RHEL 9.2 with BIND 9.16.23-RH (Extended Support Version) with a ZSK key in testing and now with Fedora and 9.18.19 with as generic as a setup that you can have with the default DNSSEC policy. I know the manner that rollovers are handled with the default policy may be different, but I still do not think the DNSKEY should disappear immediately on rollover since it is set to being inactive. Said another way...why do keys that are set to an inactive state by the KASP process immediately disappear as they should still be in the zone but no longer used to sign data? Steps to Reproduce: 1. Setup generic BIND installation with a test zone with default DNSSEC policy with inline signing. 2. Run dig to see the DNSKEY. 3. Run the rollover command. 4. Run dig to see the DNSKEY - note the original DNSKEY is gone and the new one appears. Expected Result: 1. Two DNSKEY values immediately after the rollover. 2. The original DNSKEY should be removed from cache at a later time based on the TTL of the zone and the KASP handles this. These date/times appear in the .key and .state after the rollover but the key appears to no longer be available which I believe cause a DNSSEC failure. - [root@localhost dnssec.example]# named -v BIND 9.18.19 (Extended Support Version) - [root@localhost dnssec.example]# yum info bind Last metadata expiration check: 1:34:57 ago on Fri 06 Oct 2023 04:14:09 PM CDT. Installed Packages Name : bind Epoch: 32 Version : 9.18.19 Release : 1.fc38 Architecture : x86_64 Size : 1.6 M Source : bind-9.18.19-1.fc38.src.rpm Repository : @System >From repo: updates Summary : The Berkeley Internet Name Domain (BIND) DNS (Domain Name System) server URL : https://www.isc.org/downloads/bind/ License : MPL-2.0 AND ISC AND MIT AND BSD-3-Clause AND BSD-2-Clause Description : BIND (Berkeley Internet Name Domain) is an implementation of the DNS : (Domain Name System) protocols. BIND includes a DNS server (named), : which resolves host names to IP addresses; a resolver library : (routines for applications to use when interfacing with DNS); and : tools for verifying that the DNS server is operating properly. - [root@localhost ~]# dig @localhost dnssec.example dnskey +multi ; <<>> DiG 9.18.19 <<>> @localhost dnssec.example dnskey +multi ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11680 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 9e07c9760c4d71fc010065208d2a6696e86824aebb8e (good) ;; QUESTION SECTION: ;dnssec.example.IN DNSKEY ;; ANSWER SECTION: dnssec.example. 3600 IN DNSKEY 257 3 13 ( KHL+WEwOQA3iK5hTllDiZEZGsj3muffHMtFQLVz7yf1w GqQipJ4ARhlwALPRlPJNaNRBmOj5bJZwTqYXglH9cQ== ) ; KSK; alg = ECDSAP256SHA256 ; key id = 22645 ;; Query time: 5 msec ;; SERVER: ::1#53(localhost) (UDP) ;; WHEN: Fri Oct 06 17:41:46 CDT 2023 ;; MSG SIZE rcvd: 151 - [root@localhost dnssec.example]# cat *22645.key ; This is a key-signing key, keyid 22645, for dnssec.example. ; Created: 20231006172923 (Fri Oct 6 12:29:23 2023) ; Publish: 20231006172923 (Fri Oct 6 12:29:23 2023) ; Activate: 20231006193423 (Fri Oct 6 14:34:23 2023) ; SyncPublish: 20231006193423 (Fri Oct 6 14:34:23 2023) dnssec.example. 3600 IN DNSKEY 257 3 13 KHL+WEwOQA3iK5hTllDiZEZGsj3muffHMtFQLVz7yf1wGqQipJ4ARhlw ALPRlPJNaNRBmOj5bJZwTqYXglH9cQ== - [root@localhost dnssec.example]# cat *22645.state ; This is the state of key 22645, for dnssec.example. Algorithm: 13 Length: 256 Lifetime: 0 Predecessor: 12805 KSK: yes ZSK: yes Generated: 20231006172923 (Fri Oct 6 12:29:23 2023) Published: 20231006172923 (Fri Oct 6 12:29:23 2023) Active: 20231006193423 (Fri Oct 6 14:34:23 2023) PublishCDS: 20231006193423 (Fri Oct 6 14:34:23 2023) DNSKEYChange: 20231006193423 (Fri Oct 6 14:34:23 2023) ZRRSIGChange: 20231006172923 (Fri Oct 6 12:29:23 2023) KRRSIGChange: 20231006193423 (Fri Oct 6 14:34:23 2023) DSChange: 20231006172923 (Fri Oct 6 12:29:23 2023) DNSKEYState: omnipresent ZRRSIGState: rumoured KRRSIGState: omnipresent DSState:
Re: Bind forgets my changes with nsupdate
Paul van der Vlis via bind-users wrote: > But how could I refresh the key without loosing the IP? I was in a similar situation. I managed my zone files mostly manually, but a few records needed to be updated automatically. Either manual changes would obliterate automatically updated records, as you found, or else automatic updates would cause Bind to rearrange the zone files and lose all comments, making manual editing much harder. I have arrived at what I think is a working solution. I'm still monitoring to see how it works. I now make all changes through dynamic updates (like with nsupdate), using different TSIG keys with different privileges in update-policy. Signing and key rotation are handled automatically by Bind, using dnssec-policy. I use nsdiff (https://dotat.at/prog/nsdiff/) and nsupdate to apply manual changes. That way I still have hand-written zone files with comments, so I can keep an overview, but Bind never sees them. The zone files that Bind uses are managed by Bind and don't need to be easy to read. I have a wrapper script that calls nsdiff to compare each hand- written zone file to the corresponding zone on the server, specifying a pattern with -i to tell nsdiff which records are managed in other ways. The wrapper then displays the changes, asks for approval, and then applies the changes through nsupdate. My TSIG key for manual changes, which has much greater privileges than the keys for specific automatic updates, is stored in an encrypted keyring managed with Pass (https://www.passwordstore.org/). My wrapper requests the key from Pass – which requires me to type the master passphrase – and passes it to nsdiff and to nsupdate using pipes so that the decrypted key is never written to even a temporary file. I found that inline-signing breaks nsdiff. I recommend an explicit "inline-signing no;" in each zone to prevent problems. Bind will then not keep an unsigned version of the zone, and it doesn't need to when all changes are made through dynamic updates. Björn Persson pgpZuA42cOsQH.pgp Description: OpenPGP digital signatur -- 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
