Piggybacking on a zone’s dnssec-policy using auto-dnssec: How can one do this after Bind 9.19?

[Andrej Podzimek]

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

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 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)?

(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?

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 9180 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20230416/5dbd43f2/attachment.bin>