Hi Matthijs, Thanks for your response.
dnssec-policy "ReuseKeysFromTheMainView" { keys { ksk key-directory lifetime unlimited algorithm ecdsap384sha384; zsk key-directory lifetime unlimited algorithm ; }; nsec3param salt-length 16; publish-safety P1D; retire-safety P1D; };When looking for the dnssec-policy equivalent of auto-dnssec, you will need to look at your current zone signing settings to determine the policy. Look at your current keys and check their algorithm and key length. From your policy excerpt from above it looks like you are using a KSK/ZSK strategy with algorithm ECDSAP384SHA384 (14). Key rollovers were done outside of BIND9, either manually or scripted. So "lifetime unlimited" makes sense here.
The dnssec-policy example above was meant to serve as an auto-dnssec equivalent
that passively consumes keys, not “the real thing”. That’s why it’s called
“ReuseKeysFromTheMainView”. The policy that actually generates the key files
looks like this (and has a finite lifetime):
dnssec-policy "standard" {
keys {
ksk key-directory lifetime 361d algorithm ecdsap384sha384;
zsk key-directory lifetime 61d algorithm ecdsap384sha384;
};
nsec3param salt-length 16;
publish-safety P1D;
retire-safety P1D;
};
There are at least two concerns: (1) Will the dependent “unlimited lifetime” views automatically pick up the key updates made by the main “limited lifetime” view (instead of blindly expecting the key files to never change)?Sorry, I fail to understand what dependent "unlimited lifetime" views are, and what the main "limited lifetime" view is. Are you perhaps asking how to initiate a key rollover with dnssec-policy?
The “limited lifetime” view’s zones reference the "standard" policy directly. An “unlimited lifetime” view’s zones reference keys generated by the "standard" policy. This is currently achieved using “auto-dnssec maintain”. Later, once auto-dnssec is gone, I thought that referencing the fake "ReuseKeysFromTheMainView" policy would yield a similar behavior.
(2) Which of the additional parameters have to be repeated in dependent “auto-dnssec-like” zones that don’t generate their own keys? * The salt-length seems irrelevant (set and fixed at key generation time). * But how (if at all) will publish-safety and retire-safety work int his strange setup?What are "auto-dnssec-like" zones? Zones that don't use "dnssec-policy"? In that case, for such zones "publish-safety" and "retire-safety" have no effect.
IIUC, all my zones in all views will have to switch to dnssec-policy, eventually, once auto-dnssec ceases to exist. But I’m starting to realize that I had misunderstood and overcomplicated things; simply referencing the "standard" policy again from equivalent zones in different views should (?) magically work (as Nick Tait pointed out in another message). If that’s the case, then my concerns around forcing exactly one instance of a zone to maintain the keys and forcing all other instances to passively consume keys are null and void. (As a side note, the best zone sharing option (which already works for me in some cases) is the “in-view” pointer, which automatically copies all zone settings, including the "standard" DNSSEC policy. The reason why certain zones are (re)defined in other views rather than linked using “in-view” is a need for different zone data, different “allow-query” settings etc.) So eventually it may be as simple as replacing “auto-dnssec maintain;” with “dnssec-policy "standard";” and *not* worrying about having exactly one “key producing” instance of each zone, because Bind can handle this automatically. (?) I’ll give that a try. Cheers! Andrej
smime.p7s
Description: S/MIME Cryptographic 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
