Hello Matthijs, On Thu, Sep 8, 2022 at 11:56 AM Matthijs Mekking <matth...@isc.org> wrote: > > Hi Josef, > > First of all I would like to point out the KB article about to > dnssec-policy, especially the part about migrating. > > https://kb.isc.org/docs/dnssec-key-and-signing-policy > > Although we try to asses the current signing situation, since there are > no key state files it will be an educated guess. Switching to a policy > that doesn't match your current situation might lead to withdrawing > existing signatures and keys too soon. >
Thank you, I actually know that article pretty well - it helped me several times when I did such migrations. In this particular case, I don't know exactly why, a new key was always generated and the old key with id 14237 was always retired as soon as I enabled dnssec-policy. The algo in policy was set to match the situation, but it happened regardless. I had hit that in the past, before the fix was introduced (https://gitlab.isc.org/isc-projects/bind9/-/issues/2857), so I was prepared :) What helped me in this case was simple. I just created the KACME.cz.+013+14237.state file myself, and told bind little more about the key and how to use it: ; This is the state of key 14237, for ACME.cz. Algorithm: 13 Length: 256 Lifetime: 0 KSK: yes ZSK: yes > Once BIND is maintaining key states, it is safe to change your > dnssec-policy to whatever you want. BIND will gradually move to the new > desired > policy, possibly doing key (algorithm) rollovers. > > Key rollovers happen automatically, but since you are using an unlimited > lifetime they will never be triggered unless manually with rndc. > > There is one manual step that needs to be performed during CSK and KSK > rollovers, that is updating the DS RRset to the parent. Once that is > done you can run the related 'rndc dnssec -checkds' commands. > > Or you can set up parental-agents that would check for the DS in the > parent automatically. > > As long as you use the same dnssec-policy for the zones, you can use the > same key-directory (since 9.16.18). The key rollover would happen at the > same time for the zone. Thank you! This is exactly the information I was looking for. Cheers Josef > > You can also set a different key-directory. In that case the key is not > shared, each view of the zone would have a separate DNSSEC key. > > I think it is fine using the same key-directory. The only thing is when > you change your configuration in the future such that the dnssec-policy > is different for each view of the zone, you have to also change the > key-directory to be different. > > Best regards, > > Matthijs > > > > On 07-09-2022 15:19, Josef Vybíhal wrote: > > Hello all, > > I am consolidating our old split DNS consisting of internal and > > external dedicated servers(VMs) into one primary server with views > > (there will be secondaries, but they are not important to the > > question). The old previous configuration is using inline-signing and > > auto-dnssec. I will be switching to dnssec-policy with csk. This is > > fine. > > > > My question is what would be considered best practice when I want the > > zone to be signed by the same CSK in every view. Should I point both > > zones to the same "key-directory", or should I use a different > > directory for every view? And how would the key rollover work in such > > a case? > > > > I have tried to use the same key-directory for both zones in each > > view. It seems to technically work. But maybe someone could point out > > some disadvantages I will be facing in the future? Is there common > > consensus on how this is supposed to be approached? Maybe I am > > handling it all wrong and there is a much better way :) > > > > > > The config I tested: > > > > dnssec-policy "ACME" { > > keys { csk key-directory lifetime unlimited algorithm 13; }; > > nsec3param iterations 1 optout false salt-length 16; > > }; > > > > view internal { > > > > match-clients { internal; }; > > > > zone "ACME.cz" { > > type primary; > > file "primary/internal/ACME.cz/ACME.cz.zone"; > > inline-signing yes; > > key-directory "dnssec-keys/ACME.cz"; > > dnssec-policy "ACME"; > > }; > > > > }; > > > > view external { > > > > match-clients { external; }; > > > > zone "ACME.cz" { > > type primary; > > file "primary/external/ACME.cz/ACME.cz.zone"; > > inline-signing yes; > > key-directory "dnssec-keys/ACME.cz"; > > dnssec-policy "ACME"; > > }; > > > > }; > > > > > > --- > > > > ns1-new /var/named/dnssec-keys/ACME.cz # cat KACME.cz.+013+14237.state > > ; This is the state of key 14237, for ACME.cz. > > Algorithm: 13 > > Length: 256 > > Lifetime: 0 > > KSK: yes > > ZSK: yes > > Generated: 20190611121855 (Tue Jun 11 14:18:55 2019) > > Published: 20190611121855 (Tue Jun 11 14:18:55 2019) > > Active: 20190611121855 (Tue Jun 11 14:18:55 2019) > > PublishCDS: 20190612132355 (Wed Jun 12 15:23:55 2019) > > DNSKEYChange: 20220907123627 (Wed Sep 7 14:36:27 2022) > > ZRRSIGChange: 20220907123627 (Wed Sep 7 14:36:27 2022) > > KRRSIGChange: 20220907123627 (Wed Sep 7 14:36:27 2022) > > DSChange: 20220907123627 (Wed Sep 7 14:36:27 2022) > > DNSKEYState: omnipresent > > ZRRSIGState: omnipresent > > KRRSIGState: omnipresent > > DSState: rumoured > > GoalState: omnipresent > > > > # named -V > > BIND 9.18.6 (Stable Release) <id:8dbd488> > > running on Linux x86_64 4.18.0-372.19.1.el8_6.x86_64 #1 SMP Tue Aug 2 > > 16:19:42 UTC 2022 > > .... > > > > > > > > Thanks, > > Josef > -- > 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
