Re: Problem upgrading to 9.18 - important feature being removed
Hi Ondřej, > On 27. Feb 2024, at 16:43, Ondřej Surý wrote: > > Carsten, could you please fill a feature request in the GitLab? Done, #4606. Greetings Carsten -- 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
Re: Problem upgrading to 9.18 - important feature being removed
Hi Jim, > On 27. Feb 2024, at 16:39, Jim P. via bind-users > wrote: > > There should also be an option to display the current configuration in > specific detail to easily create a new KASP (side question: why does DNS > need a new acronym?) The term “KASP” for “Key-and-signing-policy” has been around in the DNS community for many years. I remember first hearing that term when .SE (Sweden) started signing their TLD in 2005. In the beginning of DNSSEC deployment, the KASP was a document that defines how DNSSEC is implemented for a given DNS zone (that is still a good practice, writing down DNSSEC algorithms used, key sizes and rollover intervals etc). In the last years, improvements in the DNS server software (OpenDNSSEC, Knot DNS, but also BIND 9) made it possible to define the KASP in the software, which makes it easier to match the KASP document with the KASP configuration on the server itself. From my view, this is a good development. Greetings Carsten -- 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
Re: Problem upgrading to 9.18 - important feature being removed
Hi Matthijs, On 27 Feb 2024, at 15:54, Matthijs Mekking wrote: > - When migrating to dnssec-policy, make sure the configuration matches your > existing keys. the most problems I've seen so far have to do with this step: admins "think" they have created a configuration that matches the current keys, but they haven't (for one reason or other, it happens for me, despite working a lot with DNSSEC and BIND 9). It would be nice to have a "dry-run" mode in BIND 9, where BIND 9 would report steps it would do because of "dnssec-policy", but will not execute the changes. That way, admins can create a configuration with "dry-run" mode enabled, check the logfiles, and if the actions in the log-file match the expectations, the "dry-run" mode can be removed and the new configuration will become active. Greetings Carsten -- 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
Old ZSK refuses to retire
Hi, I have a situation where in a BIND 9 zone with dnssec-policy and inline-signing, after a ZSK rollover, the (old) ZSK is refusing to retire. Although the timing metadata shows the retire and deletion dates in the past, the ZSK is still in the zone and is signing the records (along with the new ZSK, so there are two ZSK RRSigs on each RRSet). Setting new retire/inactive + deletion times with dnssec-settime (with parameter -s to update the state file) does not help either. Removing the key files will stop the key being active (there are no new RRSigs generated from this key), but the DNSKEY record still stays in the zone. Any idea how to recover from such a situation (other than removing the signed zone and journals and re-signing the zone again)? Greetings Carsten -- 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
KASP: sharing policy and keys between views
Hi, (please do not start a discussion on the usefulness of views. I'm not in favor of views, but sometimes I have to work with them). I have a client that runs a split horizon (internal / external view of the same domain namespace) setup with BIND 9 on Linux. Both the internal and external views of the domain are DNSSEC signed. In the past, the setup was using "auto-dnssec maintain;" on a common, shared key directory with manually created keys. Both zones in both views fetched the keys and did the signing. This setup was stable and working fine. Because "auto-dnssec maintain;" is deprecated, we're evaluating to change the setup to use a shared DNSSEC KASP definition, pointing to the same key directory (using shared keys and a shared state file). The test setup runs without issues for one month now and has successfully done 3 ZSK rollovers in the time (KSK rollovers are manual). So it *seems* like a working configuration. We have not seen errors or race-conditions (but we might have been lucky). Does anyone here has experience with a similar setup, or deeper insight into the code and can tell me if this is a possible solution to operate a DNSSEC signed split horizon setup? Greetings Carsten Strotmann -- 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
