AW: Problem upgrading to 9.18 - important feature being removed
> -Ursprüngliche Nachricht- > Von: bind-users Im Auftrag von Carsten ... > 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. If this Bind9 is only a hidden primary, disable all outgoing XFR for the respective zone, and make a copy of the Bind config and zone/journal files. That way you could test the new config and avoid leakage of broken/unwanted zones. Regards Klaus -- 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
Matthijs Mekking wrote: > As the main developer of dnssec-policy, I would like to confirm that > what has been said by Michael and Nick are correct. Cool. > - When migrating to dnssec-policy, make sure the configuration matches > your existing keys. Is there a way to validate the policy against what's in a specific zone/directory? Effectively, "do your key management stuff --just-kidding --verbose"? > - Most issues that were shared on this list have to do with migrating > to dnssec-policy. Agreed: and it bit me, and I am still a bit shell shocked. > - If you feel like the DS is stuck in 'rumoured' state you might need > to run 'rndc dnssec -checkds seen' on the key. okay, good to know this. . o O ( Umbrella Academy ) > - It is not recommended to switch to dnssec-policy if you are currently > in a rollover. > I acknowledge that migration takes some care and I wish the process was > easier. We have some ideas to make it less error prone, but I haven't > found the time to work on that. Are there open issues? signature.asc Description: PGP signature -- 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 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
Carsten, could you please fill a feature request in the GitLab? Thanks, -- Ondřej Surý — ISC (He/Him) My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 27. 2. 2024, at 16:06, Carsten Strotmann via bind-users > wrote: > > 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 -- 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
On Tue, 2024-02-27 at 16:06 +0100, Carsten Strotmann via bind-users wrote: > 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. **This** ^^^ 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?) I don't do DNS as a full time job, so I'm in the dark on a lot of the reasoning and needs for all these changes, BUT simple testing that I have done have shown me that dnssec-policy fails often enough that I'm planning on waiting until the last possible hour in hopes that there is better tooling and simpler documentation. Not everyone running a DNS server can afford the time to be an expert at bind9, and I doubt that ISC only wants to have bind9 used by the 42 people who are experts of bind9. -Jim P. -- 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
Re: Problem upgrading to 9.18 - important feature being removed
As the main developer of dnssec-policy, I would like to confirm that what has been said by Michael and Nick are correct. I will repeat the most important takeaways: - Setting the lifetime to unlimited on keys and BIND will never roll your keys automatically. - Most issues that were shared on this list have to do with migrating to dnssec-policy. - When migrating to dnssec-policy, make sure the configuration matches your existing keys. - Make sure the migration is complete by checking that all states are in 'omnipresent' (with 'rndc dnssec -status '). - If you feel like the DS is stuck in 'rumoured' state you might need to run 'rndc dnssec -checkds seen' on the key. - It is not recommended to switch to dnssec-policy if you are currently in a rollover. I acknowledge that migration takes some care and I wish the process was easier. We have some ideas to make it less error prone, but I haven't found the time to work on that. On the more positive side, we haven't heard Thanks to all for switching to dnssec-policy and reporting issues. Best regards, Matthijs On 2/27/24 07:01, Nick Tait via bind-users wrote: On 27/02/2024 13:22, Michael Sinatra wrote: On 2/26/24 13:41, Al Whaley wrote: Originally (under the above command) RR records for DNSSEC were maintained by bind, but the ZSK and KSK keys were maintained by me. This command is being discarded. I understand that bind "sort of" supports this feature in 9.18 by allowing the DNSSEC policy statement to declare unlimited lifetime, but after careful reading of the documentation and reading a number of complaints, it turns out that bind may under various circumstances decide that it is appropriate not to use existing keys and decide that it knows best, and then it makes new ones. This potential instability of course would be disastrous, and completely unnecessary. I have never experienced this, in either BIND 9.16 or BIND 9.18 (including the latter with KASP set to not rotate any keys). Can you elaborate as to where in the documentation and/or what complaints you have seen where correctly configured KASPs in 9.18.24+ decide to roll keys? I'd certainly like to know if that's the case, for reasons described below. The only example that I can recall (from this list) where this type of thing happened was where someone specified a different algorithm when transitioning to dnssec-policy. The advice for this type of situation is to transition to dnssec-policy with the same algorithm first, and make sure everything in your state files is "omnipresent", and only then update the dnssec-policy to use a different algorithm. My (somewhat uneducated) advice would also be to avoid implementing dnssec-policy if you were in the middle of a key roll-over. Not because I think it would necessarily create a problem, but more to reduce risk and make it easier to verify that nothing untoward has happened. In other words, if you aren't in the middle of a roll-over, and your current keys don't have any expiration set, then you can reconfigure your zone to use a dnssec-policy that specifies the same algorithm as what you previously had, and BIND should be happy to carry on using the existing keys -- indefinitely if you've specified an unlimited lifetime. The only difference you should notice is that after implementing dnssec-policy there are additional *.state files in your keys directory. The only other thing I'd add is that if (after transitioning to dnssec-policy) you do initiate a manual roll-over, keep an eye on your state files to verify that the new key becomes "omnipresent". This can take much longer than you might expect! For ZSK roll-overs don't be surprised if it takes 9-10 days. Also FYI for KSK (and CSK) roll-overs, you may need to run rndc commands to tell BIND when DS records are added/removed -- but that is possibly what you already do with auto-dnssec? Of course in life there are no absolute guarantees, so you should back up your configuration and make a plan to mitigate the impacts in the event that everything turns pear-shaped? Nick. -- 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, Here is a (possibly) helpful guide that might be of use when migrating from auto-dnssec to dnssec-policy: https://kb.isc.org/docs/dnssec-key-and-signing-policy Thank you, Darren Ankney On Tue, Feb 27, 2024 at 1:01 AM Nick Tait via bind-users wrote: > > On 27/02/2024 13:22, Michael Sinatra wrote: > > On 2/26/24 13:41, Al Whaley wrote: > > Originally (under the above command) RR records for DNSSEC were maintained by > bind, but the ZSK and KSK keys were maintained by me. This command is being > discarded. I understand that bind "sort of" supports this feature in 9.18 by > allowing the DNSSEC policy statement to declare unlimited lifetime, but after > careful reading of the documentation and reading a number of complaints, it > turns out that bind may under various circumstances decide that it is > appropriate not to use existing keys and decide that it knows best, and then > it makes new ones. This potential instability of course would be disastrous, > and completely unnecessary. > > > I have never experienced this, in either BIND 9.16 or BIND 9.18 (including > the latter with KASP set to not rotate any keys). Can you elaborate as to > where in the documentation and/or what complaints you have seen where > correctly configured KASPs in 9.18.24+ decide to roll keys? I'd certainly > like to know if that's the case, for reasons described below. > > The only example that I can recall (from this list) where this type of thing > happened was where someone specified a different algorithm when transitioning > to dnssec-policy. The advice for this type of situation is to transition to > dnssec-policy with the same algorithm first, and make sure everything in your > state files is "omnipresent", and only then update the dnssec-policy to use a > different algorithm. > > My (somewhat uneducated) advice would also be to avoid implementing > dnssec-policy if you were in the middle of a key roll-over. Not because I > think it would necessarily create a problem, but more to reduce risk and make > it easier to verify that nothing untoward has happened. > > In other words, if you aren't in the middle of a roll-over, and your current > keys don't have any expiration set, then you can reconfigure your zone to use > a dnssec-policy that specifies the same algorithm as what you previously had, > and BIND should be happy to carry on using the existing keys -- indefinitely > if you've specified an unlimited lifetime. The only difference you should > notice is that after implementing dnssec-policy there are additional *.state > files in your keys directory. > > The only other thing I'd add is that if (after transitioning to > dnssec-policy) you do initiate a manual roll-over, keep an eye on your state > files to verify that the new key becomes "omnipresent". This can take much > longer than you might expect! For ZSK roll-overs don't be surprised if it > takes 9-10 days. Also FYI for KSK (and CSK) roll-overs, you may need to run > rndc commands to tell BIND when DS records are added/removed -- but that is > possibly what you already do with auto-dnssec? > > Of course in life there are no absolute guarantees, so you should back up > your configuration and make a plan to mitigate the impacts in the event that > everything turns pear-shaped? > > Nick. > -- > 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 -- 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
