DNSSEC signing common zone in views

[Matthijs Mekking]

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