DNSSEC signing common zone in views

Thu Sep 8 10:18:40 UTC 2022

Hello Matthijs,

On Thu, Sep 8, 2022 at 11:56 AM Matthijs Mekking <matthijs at isc.org> wrote:
>
> 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.
>

Thank you, I actually know that article pretty well - it helped me
several times when I did such migrations.

In this particular case, I don't know exactly why, a new key was
always generated and the old key with id 14237 was always retired as
soon as I enabled dnssec-policy. The algo in policy was set to match
the situation, but it happened regardless. I had hit that in the past,
before the fix was introduced
(https://gitlab.isc.org/isc-projects/bind9/-/issues/2857), so I was
prepared :)

What helped me in this case was simple. I just created the
KACME.cz.+013+14237.state file myself, and told bind little more about
the key and how to use it:
; This is the state of key 14237, for ACME.cz.
Algorithm: 13
Length: 256
Lifetime: 0
KSK: yes
ZSK: yes

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

Thank you! This is exactly the information I was looking for.

Cheers

Josef

>
> 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 at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users