Hi, It seems to work! Thank you!
To summarize: On the master side I have the following configuration: dnssec-policy "test" { keys { ksk lifetime P3D algorithm rsasha256 2048; zsk lifetime P2D algorithm rsasha256 1024; }; }; zone "**************" { type master; file "/*******/*****.db"; notify yes; key-directory "/******/******/"; inline-signing yes; dnssec-policy test; }; on the slaves side I have the following configuration: zone "**************" { type slave; masters { ************** ; }; file "/ **************/ ************** / ************** .db"; }; the keys are generated on the master but not on the slaves. so I don't understand how the slaves can read their zone file which ends in ".signed" because they don't have the keys ? (but it's work with dig, i see DS with the right ZSK) Regards Adrien Le ven. 9 déc. 2022 à 10:02, Matthijs Mekking <matth...@isc.org> a écrit : > Hi, > > No. > > You don't need DNSSEC maintenance on your secondary zones if you already > have set it on your primary zones. So > > zone "***" { > type secondary; > primaries { ***; }; > file "***.db"; > }; > > is enough. > > Best regards, > > Matthijs. > > On 12/9/22 09:58, adrien sipasseuth wrote: > > Hi Matthijs, > > > > thank you, so just to confirm something like this should work : > > Master : > > dnssec-policy "test" { > > keys { > > ksk lifetime P3D algorithm rsasha256 2048; > > zsk lifetime P2D algorithm rsasha256 1024; > > }; > > }; > > > > zone "**************" { > > type master; > > file "/*******/*****.db"; > > notify yes; > > key-directory "/******/******/"; > > inline-signing yes; > > dnssec-policy test; > > }; > > > > And my Slaves : > > zone "**************" { > > type slave; > > masters { ************** ; }; > > file "/ **************/ ************** / ************** .db"; > > key-directory "/ ************** / ************** / ************** > .fr"; > > auto-dnssec maintain; > > inline-signing yes; > > }; > > > > am i rigth ? > > > > Regards > > > > Adrien > > > > > > > > > > Le ven. 9 déc. 2022 à 09:33, Matthijs Mekking <matth...@isc.org > > <mailto:matth...@isc.org>> a écrit : > > > > Hi Adrien, > > > > You should **not** copy the dnssec-policy configuration to your > > secondaries. They transfer in the signed zone from the primary > server. > > > > Best regards, > > > > Matthijs > > > > > > On 12/9/22 09:24, adrien sipasseuth wrote: > > > Hello, > > > > > > > > > Lokking for some guidance, sorry if i use the wrong way to contact > > > community user support. > > > > > > > > > I would like to set up DNSSEC using KASP. > > > > > > I have an architecture with a master and several slaves. > > > > > > Here is my policy and zone configuration: > > > > > > dnssec-policy "test" { > > > > > > keys { > > > > > > ksk lifetime P3D algorithm rsasha256 2048; > > > > > > zsk lifetime P2D algorithm rsasha256 1024; > > > > > > }; > > > > > > }; > > > > > > zone "**************" { > > > > > > type master; > > > > > > file "/*******/*****.db"; > > > > > > notify yes; > > > > > > key-directory "/******/******/"; > > > > > > inline-signing yes; > > > > > > dnssec-policy test; > > > > > > }; > > > > > > > > > after restart, it seems ok, keys are generated on master, no > > errors in > > > logs etc. > > > > > > I copied this policy, the keys and the zone configuration on each > > of my > > > slaves then I restarted my slaves everything seems ok (in the > logs). > > > > > > except that now I wonder if the keys on each of my slaves will be > > > generated independently from those of my master. > > > > > > > > > In this case, I will end up with different keys for the same zone > > > depending on the slave1 / slave2 etc / master. I suppose that it > > is not > > > good because we should have for the same zone, a pair of keys and > > this > > > one should be copied on each slaves? > > > > > > There some tuto / documentation about how to setup KASP in master > / > > > slaves topology ? > > > > > > > > > Sorry if it's not enough clear... > > > > > > > > > Thank you > > > > > > *Adrien SIPASSEUTH* > > > > > > > > -- > > Visit https://lists.isc.org/mailman/listinfo/bind-users > > <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/ > > <https://www.isc.org/contact/> for more information. > > > > > > bind-users mailing list > > bind-users@lists.isc.org <mailto:bind-users@lists.isc.org> > > https://lists.isc.org/mailman/listinfo/bind-users > > <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 >
-- 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