Hi Andrej,
While I am not 100% sure on your use case, let me at least respond to this:
> 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.
...
> 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.
That is correct: When you have the same zone (identical name) in
multiple different views that refer to the same dnssec-policy, there
will be only one set of keys maintained that is shared for that zone in
all views.
Best regards,
Matthijs
On 4/17/23 13:03, Andrej Podzimek wrote:
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
--
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
