From Newsgroup: comp.protocols.dns.bind
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --d6hKXDL9GbeTzU7e8I3JhfCTG8ico5oKl
Content-Type: multipart/mixed; boundary="RfARtNtuWoBq0W5sC0v6PDlw0TLHkhZX2";
protected-headers="v1"
From: Matthijs Mekking <
matthijs@isc.org>
To:
bind-users@lists.isc.org
Message-ID: <
22ff7e34-d329-24e4-e954-6ec3643faba1@isc.org>
Subject: Re: KASP Inactive/Retired timestamps
References: <
20200520003720.62lknfqeuhlvofjp@smallberries.local>
In-Reply-To: <
20200520003720.62lknfqeuhlvofjp@smallberries.local>
--RfARtNtuWoBq0W5sC0v6PDlw0TLHkhZX2
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Hi Gregory,
Thanks for trying out out the new KASP. Let me try to answer your
questions below.
On 5/20/20 2:37 AM, Gregory Shapiro via bind-users wrote:
After the fantastic ISC DNSSEC webinar series last month, I began
using KASP for my DNSSEC signed zones. I have noticed an odd
behavior with regards to the files BIND keeps in keys/ (K*.key,
K*.private, and K*.state). For inactive/retired keys, every BIND
restart updates the dates in those files (see below). This raises
two questions:
=20
1. Should the time a key becomes inactive or retired be a fixed point
in time rather than changing to the last time BIND restarted for
every restart?
Named now takes care of the rollover, taking over the job of fiddling
with dnssec-keymgr. That means that named will set the key times.
Note that a key time is an indication of an event happening: if the
underlying state machine thinks it is not yet safe to do so, the event
will happen at a later point in time.
In other words, the keymgr embedded in named is making decisions on
rollover actions based on this state machine, not the key times. The
key times do help the user to see when key rollovers will happen.
In principle these times are fixed, but changes in key files (a key gets published, a change in key lifetime, ...) will trigger updating the key
times.
2. When, if ever, is it safe to remove the files from the keys
directory for inactive/retired keys (i.e., is there a state after
Inactive or Retired)?
There is a Deleted time as well, at this point the key and corresponding signatures should no longer occur in the zone. When looking at the key
state files: if all states are in "hidden" it is safe to prune the files.=
An example set of changes is shown in the pruned diff below. Note
that for this particular key, the state file shows the following
states:
Thanks for showing this example. This is a minor bug. What happens is
that the key file matches your dnssec-policy but most likely another
active key also matches. Any excess keys are retired immediately (even
if this key was already retired previously).
Best regards,
Matthijs
DNSKEYState: hidden ZRRSIGState: hidden GoalState: hidden
=20
--- Kgshapiro.net.+008+05640.key 18 May 2020 02:06:14 -0000
1.9 +++ Kgshapiro.net.+008+05640.key 19 May 2020 23:53:06
-0000 -; Inactive: 20200518020420 (Tue May 18 02:04:20 2020) +;
Inactive: 20200519230430 (Tue May 19 23:04:30 2020)
=20
--- Kgshapiro.net.+008+05640.private 18 May 2020 02:06:14 -0000
1.9 +++ Kgshapiro.net.+008+05640.private 19 May 2020 23:53:06
-0000 -Inactive: 20200518020420 +Inactive: 20200519230430
=20
--- Kgshapiro.net.+008+05640.state 18 May 2020 02:06:14 -0000
1.8 +++ Kgshapiro.net.+008+05640.state 19 May 2020 23:53:06
-0000 -Retired: 20200518020420 (Tue May 18 02:04:20 2020) +Retired: 20200519230430 (Tue May 19 23:04:30 2020)
=20
Thanks! _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
=20
ISC funds the development of this software with paid support
subscriptions. Contact us at https://www.isc.org/contact/ for more information.
=20
=20
bind-users mailing list bind-users@lists.isc.org=20 https://lists.isc.org/mailman/listinfo/bind-users
=20
--RfARtNtuWoBq0W5sC0v6PDlw0TLHkhZX2--
--d6hKXDL9GbeTzU7e8I3JhfCTG8ico5oKl
Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEEF9tUtPZjiCApvBobVHl7Vy10FR4FAl7EzUEACgkQVHl7Vy10 FR679ggA7JNxhlKWxPGRwb2YIJI7ISNk1q4k6+354krrdHWaUHUR4AI6GnersDMN PRjq8F9lNFjaGVJ6Z3QY3oJoMDV01LPwFKELEr3tFWgTnOuC1SUX3OhpbJhdR6g+ 9Y2EkDcGSsdzBt0Rib/xfJ6e/r/IT3dDKi5Y+4w3GMzikJV0qpOdm2G4WcvBfIWi plYk5ZvoRq2VKxCk/Boa5O6plKaZvYTQiQf1byNz2rvfE8m51N8O8j+Ihv+LCTSp TsoBMlwj+ak58ce/Opa7KZzHN+PhBYBO/fuGCNmjYzbqqTIetPDZMTfU7G02OlzI XFVRYD5qQ8MxlER/c8+3436RVROAXg==
=/vte
-----END PGP SIGNATURE-----
--d6hKXDL9GbeTzU7e8I3JhfCTG8ico5oKl--
--- Synchronet 3.18a-Linux NewsLink 1.113