Deleting a key

[Matthijs Mekking]

Hi Casey,

Don't muck around with dnssec-settime. As Peter mentioned earlier, your 
key seems to be in rollover, awaiting DS publication. I'll repeat what 
he said:

   The DS for the new key is only rumored. If you have seen the DS in the
   parent, tell BIND so:

   rndc dnssec -checkds -key 48266 published
   rndc dnssec -checkds -key 50277 withdrawn

Alternatively, you can configure "checkds yes" for your zone, and BIND 
will check the DS at the parent and continue rollover automatically.

Best regards,

Matthijs

On 8/7/24 08:02, Casey Deccio wrote:
> Hi all,
> 
> I'm probably missing something obvious here, but I'm trying to figure 
> out how to "delete" a DNSKEY from zone that uses inline signing.  The 
> zone statement looks like this:
> 
> zone "dns-lab.info" {
> type master;
> file "/var/cache/bind/db.dns-lab.info";
> dnssec-policy alg8;
> inline-signing yes;
> };
> 
> This is the current state:
> 
> https://dnsviz.net/d/dns-lab.info/ZrMLNw/dnssec/ 
> <https://dnsviz.net/d/dns-lab.info/ZrMLNw/dnssec/>
> 
> Or:
> 
> $ sudo rndc dnssec -status dns-lab.info
> dnssec-policy: alg8
> current time:  Tue Aug  6 23:48:14 2024
> 
> key: 50277 (ECDSAP256SHA256), CSK
>    published:      yes - since Thu Oct 19 09:59:06 2023
>    key signing:    yes - since Thu Oct 19 09:59:06 2023
>    zone signing:   yes - since Thu Oct 19 09:59:06 2023
> 
>    Rollover is due since Thu Oct 26 16:11:03 2023
>    - goal:           hidden
>    - dnskey:         omnipresent
>    - ds:             unretentive
>    - zone rrsig:     omnipresent
>    - key rrsig:      omnipresent
> 
> key: 48266 (RSASHA256), CSK
>    published:      yes - since Thu Oct 26 16:11:03 2023
>    key signing:    yes - since Thu Oct 26 16:11:03 2023
>    zone signing:   yes - since Thu Oct 26 16:11:03 2023
> 
>    No rollover scheduled
>    - goal:           omnipresent
>    - dnskey:         omnipresent
>    - ds:             rumoured
>    - zone rrsig:     omnipresent
>    - key rrsig:      omnipresent
> 
> Note that keys with two DNSSEC algorithms are in the zone, which might 
> be complicating things... ?
> 
> Now I use dnssec-settime to give key 50277 a "delete date":
> 
> $ sudo -u bind dnssec-settime -D+5mi 
> /var/cache/bind/Kdns-lab.info.+013+50277.
> /var/cache/bind/Kdns-lab.info.+013+50277.key
> /var/cache/bind/Kdns-lab.info.+013+50277.private
> 
> It seems to work:
> 
> $ sudo cat /var/cache/bind/Kdns-lab.info.+013+50277.key | grep Delete
> ; Delete: 20240807054556 (Tue Aug  6 23:45:56 2024)
> 
> $ sudo /etc/init.d/named reload
> Reloading named configuration (via systemctl): named.service.
> 
> I'm not really sure what the following lines mean in the log because 
> they don't seem to correspond to the times in the key file.
> 
> $ sudo tail -100 /var/log/syslog | grep key
> 2024-08-06T23:41:10.353023-06:00 bass named[216234]: zone 
> dns-lab.info/IN/authoritative-only (signed): reconfiguring zone keys
> 2024-08-06T23:41:10.356705-06:00 bass named[216234]: keymgr: retire 
> DNSKEY dns-lab.info/ECDSAP256SHA256/50277 (CSK)
> 2024-08-06T23:41:10.356888-06:00 bass named[216234]: zone 
> dns-lab.info/IN/authoritative-only (signed): next key event: 07-Aug-2024 
> 00:41:10.345
> 
> However, nothing ever changes with key 50277. I've done all this 
> multiple times over several days. It continues to sign records when I 
> add records to the zone.  If someone has ideas to point me in the right 
> direction, that would be great.
> 
> $ /usr/sbin/named -v
> BIND 9.18.28-1~deb12u2-Debian (Extended Support Version) <id:>
> 
> 
> Thanks,
> Casey
>