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

[Matthijs Mekking]

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
>