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.
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.
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
