Hello Andrej,
On 4/16/23 23:08, Andrej Podzimek via bind-users wrote:
Hi bind-users,
I have asked this question on GitLab, but hijacking a closed issue to
ask questions is bad practice (often rewarded with silence), so I’m
re-posting the question here.
https://gitlab.isc.org/isc-projects/bind9/-/issues/3769#note_356577
Sorry, I have missed the earlier comment on GitLab, but you are right,
the bind-users list is a better place for such questions.
My DNS server serves multiple views that share zones but resolve their
(mostly multi-homed) hosts to different addresses, depending on the view.
The easiest (?) way to make DNSSEC work in all views has been to keep a
dnssec-policy for zones in *one* of the views (to generate and maintain
keys) and then passively refer to the keys from the zones’ counterparts
in other views using auto-dnssec. \o/
Now a log warning message is telling me that auto-dnssec will be
removed. /o\
As outlined in the GitLab comment, I have been trying to find a
dnssec-policy equivalent of auto-dnssec. Could it be something like this?
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.
I assume your zone uses NSEC3. If the current salt length is 16, the
NSEC3 chain should be maintained.
Furthermore:
- "sig-validity-interval":
Specifies the number of days a signature is valid. The second optional
value is the refresh interval. This equivalent of this option are
the dnssec-policy options "signatures-validity" and "signatures-
refresh".
- "dnskey-sig-validity": This equivalent of this option is the
dnssec-policy option "signatures-validity-dnskey".
Other dnssec-policy options are related to key timings when doing key
rollovers.
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?
(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.
Best regards,
Matthijs
I may have overlooked something, but could not find this↑ in the
documentation. Ideas and documentation pointers (to the best auto-dnssec
equivalent) would be very helpful.
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
